razor is almost blazor already anyway, I doubt it’ll end up like silverlilght as the framework is in place and it doesn’t rely on any inbuilt windows libraries like silverlight did (it uses the Os’s inbuilt browser for local stuff, and web it renders to html), so nothing for MS to have to keep up to date. Also silverlight was a POS to begin with, blazor actually works, a couple wierd quirks, but nothing compared to windows forms issues or xaml issues.
WASM has been fully supported in browsers since 2016, but you only use wasm for the blazor client-side stuff, you can also have hybrid and server components (like htmx) which will operate only on the server side, then send the complete html to the client.
For websites it uses SignalR for server-side component comms, for client side it is wasm, so no comms library is necessary. I note SignalR is already in Umbraco 15 for event handling.
What is Lit
A framework, for creating JS web components (web components do not actually need to use JS at all, but the Umbraco ones require it for service/library access)
Lit component example
import {LitElement, css, html} from ‘lit’;
import {customElement, property} from ‘lit/decorators.js’;
@customElement(‘simple-greeting’)
export class SimpleGreeting extends LitElement {
// Define scoped styles right with your component, in plain CSS
static styles = css :host { color: blue; } ;
// Declare reactive properties
@property()name?: string = ‘World’;
// Render the UI as a function of component
staterender() { return html<p>Hello, ${this.name}!</p>; }
}
Same example in Blazor, (although you can include the css as a separate file if you need to be able to change it per instance of the component in use and it will keep it localised to that individual instance of it)
// Define scoped styles right with your component, in plain CSS
<style>
:Host { color:blue; }
</style>
<p>Hello, @name!</p>
@code
{
public string name {get; set;} = "World";
}
**
Re: Umbraco and others keeping an eye on alternates**
I was already doing this as soon as I found out about the forced scripting for anything backoffice related because I dislike scripting, and I do not like the extra crap TS adds to the end-result JS file.
One of the others actually told me about the issue with blocks.
The main reason I was given for having other things on the side (although they are not switching yet AFAIK) is because of the additional dev time to setup, and additional time for maintenance/tech debt to have another build process and another package manager (NPM) operating alongside NUGET. If a bug occurs determining what the issue is now requires diving into JS and .NET.
This costs money and makes us less competitive compared to php/js CMS’s which can already be hosted far cheaper than Umbraco due to their more flexible nature in regards to databases and hosting environments.
If they are security conscious it also means having the NPM stuff inside a secured vm (NPM has several major issues with security, including using system authority when installing packages into a project which is a huge problem).
So essentially you are looking at increased overheads and tech debt going forward, thankfully lit seems pretty lightweight, but the fact that for server-only stuff like adding a dashboard we now have to use JS is basically meaning a lot of these guys are seeing extra work for the same output.
To give an example - I made a plugin ages ago that allowed Umbraco forms to integrate with clients SAP, Salesforce, and other ERP/ERM systems, the single plugin did a bunch of them.
The best part was that the clients could update the parameters and multiple endpoints for those systems themselves easily form a config dashboard and the form.
On submission of the form, the relevant data would be: validated, pulled out of the form, converted, and submitted to the appropriate external system’s URL depending on what they had set inside the form and the plugin settings. Then responses logged locally (sometimes we would also be pulling in data regularly too).
None of the above system required any JS, everything ran in backend functionality using .NET libraries, HTML5 + CSS3 for the user-side interfaces. JS was used for some html validation (prior to .net validation) for the dashboard and minor dynamic FE changes.
So I had:
- NUGET package manager + standard build
- .Net library service for submission & config of settings
- .NET Forms extension
- Composer/component setup for custom local tables
- .NET MVC controllers for any views (allows for additional or external security checks)
- .NET IDashboard implementation - registers the dashboard on first start of program provides security settings
- HTML & CSS for any views, minor JS for any purely dynamic elements.
- Language file
- .Net - Tests
Now to do the same in Umbraco 15 when I looked into it, it looks like:
- NUGET package manager + standard build
- .Net - library service for submission & config of settings
- .Net - Forms extension
- .Net - custom Security (unsure how this will go with the backoffice TS/Lit stuff)
- .Net - Composer/component setup for custom local tables
- .Net - Tests
- NPM Packages + NPM build
- TS/LIT Dashboard Registration
- TS/LIT Dashboard Views
- TS/LIT logic (was part of the controller/razor view previously)
- HTML + css for views
- TS - Tests
- Manifest File
- language file
So now there is a little bit of extra work there and every time I make any change it may mean 2 builds instead of 1, doubling the amount of time spent in build, but that also means 2 build processes that can break.
There are several big (to me) problems:
- I had one test project which could test all the other libraries and services logic. Now I have to have 2.
- If I need to modify this in 6 months, or worse, have to onboard someone. I have to be able to remember 3 different language frameworks, C# .NET, TypeScript (which is very similar as it was MS too), and LIT, in the first instance I only had to know C# .NET.
- Additionally the main logic of how my package works is split in half, one half in .NET the other in TS/Lit.
- I have to read a manifest file to see what is happening for some of the code
- Debugging typescript is not very straight forward. It parses down to JS, but is much harder to read, meaning now you need debugging tools for that.
- NPM is very environment sensitive, particular settings and other programs changes to environment settings can cause it to fall over, so if you do multiple different types of projects on the one system, best to use a containerised development system or vm.
Now if you want to use TS/Lit, NPM or even angularjs (nothing like having a fe mvc stack on top of a be mvc stack) that is fine, you should be able to as long as it doesn’t compromise the underlying security and stability (unless you mean to do that).
My issue is that we are forced to use the JS based web components setup, and that the interfaces we used to be able to use have been removed, and now they have to hit other js functions which in turn will then access the .NET services to do what we could have done in one step.
There is a plugin that allows you to create a dashboard setup in C# (I think it may generate the JS for you), ZauberCMS allows for blazor, and there is another plugin that reinstates the controller/view pattern to allow razor for Umbraco.
(