Comment by WorldMaker
4 days ago
I still haven't found a use-case for the websocket Blazor Hybrid and it still smells so much like the worst mistakes of the original ASP (before .NET) and the `runat="client"` versus `runat="server"` confusions.
Blazor WASM makes some sense if Silverlight ever made sense for a project: it's a way to ship C# directly to the browser for maximal code sharing with other C# projects in a C# ecosystem. It's basically "what if Angular/React was just Razor Pages running on the browser?"
It's absolutely the opposite of KISS, it's lifting and shifting the entire .NET runtime in WASM to the client. Outside of corporate networks and packaged apps like Electron or Tauri, I'm not sure it makes any sense. But if you like writing Razor Pages and wished they ran closer to the client metal, and you can afford the bandwidth of an entire .NET application soup-to-nuts as your SPA framework, there is a sense to it.
If all you think you need is Razor Pages with HTMX that's probably all you need.
>I still haven't found a use-case for the websocket Blazor Hybrid and it still smells so much like the worst mistakes of the original ASP (before .NET) and the `runat="client"` versus `runat="server"` confusions.
That is exactly my read of it, especially given Microsoft track record on delivering with stuff like this.
Not sure about the Silverlight comparison - in the days of Flash, browsers did not even have a way to stream video reliably, nowadays it just cramming a square peg in to a round hole - heavyweight runtime built on multithreading crammed to a single threaded event loop. I have not tried it - but after using .net in much more powerful/native envs like Android - I know for a fact that the iteration/build/debugging story sucks compared to native JS/TS. Also as bad JS is, TS makes it saner, tooling has matured and DOM APIs are built for JS.
> nowadays it just cramming a square peg in to a round hole - heavyweight runtime built on multithreading crammed to a single threaded event loop
Sometimes the "event loop" part is forgotten because JS' single threaded thing is very "cooperatively threaded". This is a large part of why async/await works so well in JS and is growing so quickly in adoptions. .NET's multithreading is built in a way to excel in "cooperatively threaded" environments (its task pools are cooperative by default, for instance, and also arguably heavy use of async/await was C#'s idea first).
It would be great to see more WASM multithreading powers, but writing C# for today's WASM environment doesn't feel that different from "regular" multi-threaded C#.
> I know for a fact that the iteration/build/debugging story sucks compared to native JS/TS
WASM debugging is nearly great, including growing Sourcemap support. The ability for Visual Studio to be the Debugger interface to Chromium-based browsers is more powerful that ever. Certainly in its debugging story Blazor WASM is much advanced from Silverlight which was only really debuggable in IE and then was still often flaky.
> DOM APIs are built for JS
There's still talk of making more direct DOM APIs for WASM. Might be interesting to see eventually.
This is why it is so easy to relate Blazor WASM to React. Blazor is essentially using Razor templates to define a Virtual DOM which it then sends render updates across the WASM/JS boundary to a very tiny virtual DOM renderer.
It's not what I'd use for smarter direct DOM work, but in comparison to React it gets the job done and works surprisingly well, even with the language barrier and data marshalling across sandbox layers.
I've used Blazor WASM on Enterprise projects. I'd probably use it again on Enterprise projects. It can be real nice to have backend and frontend all entirely in C#. (In different projects. So that you can scale them independently if nothing else.)