BlazorDiffusionVue VS SharpKit

I take the opposite view as a recent Blazor convert since .NET 8 that was just released.

I was short on Blazor before .NET 8 and could only seriously recommend it for Internal Apps since the compromises for using either Server or WASM Interactivity had pretty poor UX for initial load of Intranet Apps.

However that's changed in .NET 8 with Blazor Static Rendering which is now the default where you're effectively able to develop traditional Server Rendered Apps like Razor Pages/MVC but with Blazor's superior component model, advanced features like Streaming Rendering and its built-in Enhanced Navigation which gives simple Server Rendered App's SPA-like responsiveness without any of npm's build tool complexity, need to manage separate client routing or heavy client state, etc.

Even better is that you no longer need to use Blazor Interactivity for any features, e.g. which we avoid in our "Blazor Vue" Tailwind template that progressively enhances statically rendered Blazor content with Vue.js. I cover this approach in detail in our ".NET 8's Best Blazor" [1] blog post.

As it embraces the simplicity of "NoBuild" JavaScript Modules (i.e. instead of npm deps) it's now become my preferred approach for most Web Apps. Blazor Diffusion is an example App built using this template, which was originally developed in Blazor Server, deployed as WASM but now converted to "Blazor SSR + Vue", source code available from [2],

https://blazordiffusion.com

[1] https://servicestack.net/posts/net8-best-blazor

[2] https://github.com/NetCoreApps/BlazorDiffusionVue

At the very end of the blogpost the author asks why not compile C# to JavaScript, like F# (Fable) does? The author thinks that would be the best solution overall, and is surprised it has not happened yet.

In fact that has happened, see JSIL (http://jsil.org/, which compiles .NET bytecode to JS) and also SharpKit (https://github.com/SharpKit/SharpKit which is built on Roslyn).

But this will not necessarily be any better than compiling to wasm. It avoids the .NET interpreter, which decreases the download, but it will still need to bundle a lot of library support code. And getting the language semantics exactly right - including features like C# finalizers which do not have direct support in JS - is tricky, unlike with wasm. And it won't benefit from the speed of the wasm implementation in AOT mode (which Blazor supports), which can be much faster than JS.

Compiling to JS definitely still makes sense in some cases, but it isn't an idea that Microsoft or the .NET community has somehow overlooked. It has been done and it has its own tradeoffs.