Using WebAssembly from .NET with Wasmtime

https://gunnarpeipman.com/blazor-partial-page-class/

If your files in the solution explorer end in .razor, you are using the correct item type. If your files end in .cshtml, you are going to have a bad time and everything will seem very wrong. At first, I was using the "Add->Razor Page" context menu option assuming this was what I wanted, but it will give you the wrong type of item.

However, if MS does something that could remotely look like Embrace, Extend, Extinguish then a lot more hate is thrown around. This is occurring a bit more as MS pushes outside of it's Windows world.

It seems to me their general plan has changed to Embrace and Host

If those two things never bothered you, then you might not understand the benefit, and you can continue to use what you like.

In practice, sending the .NET libraries over the network is the major burden of the approach Blazor takes, since the first load will be slow and bandwidth-intensive, even though everything will likely be cached for subsequent visits.

However, as the WASM tooling and standards improve, the library sizes will shrink, and less libraries in general will be necessary to accomplish stuff that has been solved at the level of web standards.

Additionally, it requires that your front-end team feels comfortable working in .NET technologies. Ours certainly doesn't, and it would be very hard to sell my director on anything that doesn't maintain the traditional backend/frontend split.

You bind your backend to your frontend and SignalR communicates all changes.

But there are some things you should be aware of. Because the frondend and backend are integrated it's very easy to 'leak' your data layer to the frontend. Always use viewmodels.

1. You can have all the benefits of a static-strongly typed language such as C#. Which implies: better tooling, less prompt to type errors, and more suitable for enterprise software.

2. You get the full power of .NET in the browser

And, if you are already using ASP.NET for your backend:

3. You can reuse a lot of code. This means almost no class duplication (like when you work with TypeScript).

Extra:

4. Blazor is pretty similar to Angular +2, so the learning curve is smooth if you either have experience with Angular or C#.

Client-side currently suffers from large download size and startup time (since the wasm .net runtime still interprets all the DLL files) on every run. It's still in preview so expect this to get better eventually. Client-side also still requires HTTP calls to the backend (since that's the only thing available in the browser) but you can use the `HttpClient` with all the shared classes and included JSON facilities instead of maintaining a separate version in JS.

Server-side means all the components run on the server, with updates and interactions run over SignalR websocket connection. This is best suited for internal apps, enterprise SaaS or other highly-interactive apps that would need a real-time connection anyway. The fact that all the UI logic runs on the server means you save a tremendous amount of effort by skipping all the view models, serialization, http calls, and everything else that's necessary. You can have database calls right in your component. This makes complex interactions incredibly easy. If you fit this scenario, Blazor is an fantastic tool compared to what we had before.

Also it's important to note that you don't need the whole app to be in Blazor. You can easily use MVC or Razor pages and just include an interactive component somewhere on the page. We use this for a normal server-rendered site that has some pages that require complex logic and just have that part powered by Blazor server-side as well. It's seamless and even supports server-prerendering so the first-load of the page is fully composed before the real-time connection starts up and takes over the state.

So big deal and yawn. MS has a new management, it was "infiltrated" by the right folks in the early to mid 2000's who educated MS from inside and began to set MS on the right track. It takes time, like steering an oil tanker.

But MS are a capitalist corporation, just like all the others, they will all do some evil at some point in time on behalf of their bottom line and shareholder dividends, if they think they can get away with it.

In my experience, it is not possible to completely eliminate JS from the equation with Blazor. I've had to write a single .js file which I currently use for 3 things: Reading a cookie, writing a cookie and focusing an arbitrary DOM element. The focus concern I could probably alternatively handle with an autofocus attr which is dynamically inserted into the razor component, but somehow this seemed easier. Cookie or local storage interop requires JS. This is a very simple bit of code to write, and I would strongly recommend implementing it yourself to become familiar with Blazor component lifecycle events (i.e. how you make sure this JS shim is loaded into DOM before invoking its methods).

I've been wanting to create a public GitHub repo with a more practical Blazor boilerplate app that might help others get started with this kind of concern a lot faster. Perhaps something like an LDAP-authenticated business operations dashboard. Seeing an actual cookie session token read/written and how all of the code flows for session management purposes can save days of frustration. I already see some options out there for Nugets that claim to handle Blazor session management for you, but in my experience these almost always get in the way and force techniques upon you that you really didn't want to work with. If you find yourself reading the documentation for a CookiePolicyOptions or ClaimsPrincipal type, you probably went too far down the rabbit hole.

Last time I looked, blazor compiles c# to MSIL just like normal, but also provides a wasm runtime for MSIL.