You mean Microsoft's latest attempt at Web Forms/Silverlight, a product that yet again tries to muddy the separation between client and server execution contexts using magic.
Seems like every generation re-invents this idea, and every time it fails for the same fatal flaw: Illusions are just that, and you'll wind up hacking around the illusion if you want to do something not envisioned (or run into a bug in the secret sauce).
And before someone replies "it is nothing like Web Forms!!!" here's a direct quote from Blazor's homepage:
> Blazor can run your client logic on the server. Client UI events are sent back to the server using SignalR - a real-time messaging framework. Once execution completes, the required UI changes are sent to the client and merged into the DOM.
I'm also not sure why you are conflating Silverlight with Web Forms - it was never competing with Web Forms, it was client-side only, a replacement to Flash - a better UI and API (at the time) than HTML/CSS/JS.
Blazor is OSS, and doesn't work like Web Forms.
As in your own quote, Blazor uses SignalR - which uses push-based comms, such as Web Sockets; Web Forms was standard HTTP.
I was a Web Forms developers, I've earned at least that. Blazor absolutely does work like Web Forms, in terms of client<->server integration, just because it uses WebAssembly & SignalR instead of JavaScript & Ajax doesn't really change that but rather obfuscates it. Essentially it is just another set of abstractions attempting to paper over a real boundary.
> As in your own quote, Blazor uses SignalR - which uses push-based comms, such as Web Sockets; Web Forms was standard HTTP.
Which makes it even worse, if the client/server boundary wasn't muddied enough with with the unidirectional magic Web Forms used, now we have omnidirectional instead. As if that will make it less complicated and buggy.
Definitely put me in the "nay" category with Blazor. I've danced this exact tango with Microsoft twice before, and their obsession with making browsers desktop-like applications. WebAssembly is cool tech for one day, they're just abusing it for something that is an inherently bad idea.
Uh, have you used SignalR over web sockets? From a performance point of view its going to be much better than Http based polling. Which should make a different when we are talking about updating the UI.
Blazor may not work like Web Forms, but the philosophy is similar. Abstract away the fundamentals of HTML/JS, making back-end devs feel like front-end devs.
I started my dev career a long time ago in Web Forms. I went so long without understanding HTTP POST/GET/etc that it harmed me.
Anyone remember UpdatePanel? AjaxControlToolkit? Blazor gives me the same feelings.
There's nothing magic about it. Web Forms was a great innovation and brought the WinForms model to the web. It was more productive than anything else at the time and directly influenced MVC patterns (which asp.net itself went towards) and component-based UI.
Blazor is the next evolution in client-side and offers an alternative to building component UI with C# running through WebAssembly instead of Javascript. Again it's much more productive and lets backend teams reuse much of the same code, similar to JS/node projects today.
Blazor's server-side runtime is a optional model where all the component logic can run on the server and be delivered over a SignalR connection to further increase productivity and efficiency where it makes sense (highly constrained devices, local intranet apps, etc. There's even experimental projects to bring Blazor for mobile apps.
Seems like every generation re-invents this idea, and every time it fails for the same fatal flaw: Illusions are just that, and you'll wind up hacking around the illusion if you want to do something not envisioned (or run into a bug in the secret sauce).
And before someone replies "it is nothing like Web Forms!!!" here's a direct quote from Blazor's homepage:
> Blazor can run your client logic on the server. Client UI events are sent back to the server using SignalR - a real-time messaging framework. Once execution completes, the required UI changes are sent to the client and merged into the DOM.
That's literally how Web Forms worked.