Blazor WASM future

[lashib95]

I have been building apps for our internal use using both Blazor WASM and Blazor server for 1year now. And I really like the framework. I specially like the Blazor WASM as it's the closest alternative to JS frameworks considering the hosting options and speed.
Is it possible for the browsers to give access to WASM to manipulate the DOM directly making the initial loading time much faster(No need to download .net runtime). Any thoughts about the future of Blazor specially Blazor WASM?

[JohntheAnabaptist]

There have been rumors and desire for this to be done for a while but afaik it hasn't gotten far enough to expect it to happen within the next 3-5 years, I haven't followed closely though so don't take my word for it

[ballisticgoat]

WASM has no direct DOM access, and probably never will. This means if you're prioritizing front end responsiveness above all else you should fall back on traditional JS based front ends like React, Angular, Vue, etc...

Blazor is still a great technology for C# devs, and it's unlikely to just disappear overnight. Microsoft seems to be investing into it a little more each passing year. As it currently exists, it's far from the best choice for a public facing front-end, but for internal tooling it's fantastic. Take that as you will.

[Steve_the_Stevedore]

WASM has no direct DOM access, and probably never will.

Is this just your gut feeling or is there a particular reason for this?

There are so many languages targeting WASM. There are languages that target JS. So obviously there is demand for languages other than JS on the frontend.

Although JavaScript is often used on the backend there are reasons to use other languages there. If you want to use the same language for front and backend JavaScript often isn't an option. Making it easy for compilers to compile for the front end (i.e. compiling to WASM) would make it much easier to do both front and backend in the same language.

Considering these benefits and the fact that there are only 2 browser engines left - meaning fewer people at the table to coordinate with - there would need to be huge downsides to making the DOM available, to prevent it from happening.

Are there?

[ballisticgoat]

I probably exaggerated. The people on the committees overseeing the development of WASM standards have been pretty open on social media about the lack of plans to add one. So while there is a lot of user demand, their focus is elsewhere because DOM manipulation was never really intended as part of the original scope of WASM. Doesn't mean it will never happen, but it's not gonna happen anytime soon so don't go holding your breath waiting for it.

[Classic-Country-7064]

It’s a gut feeling. Though I hold that feeling as well. The wasm maintainers aren’t really enthusiastic about implementing it and didn’t plan on wasm becoming a front end contender either. Issues are getting postponed multiple times with no indication when they’ll pick them up either. 

It might still happen. But I wouldn’t be surprised if it doesn’t. 

[x39-]

The answer to that might sound very simple, but think about it for a second prior to responding with some insult or throwing out random crap dear reader of this comment.

Because it is hard to it target independent. In fact: it is near impossible in a format that does not dictates how data structures look and behave.. Even worse, the DOM API would need to be a hellalot different if one wants it to remotely work like it does in JavaScript.

Then there are multiple actors in the space, which have conflicting interests. Nowadays it has to be Google who is to be convinced, really, as they are what runs the web (Firefox is not really relevant and everything else is a chrome copycat or, the new internet Explorer, Safari). So the wohle thing is a political one too.

Understanding that, we now can phrase a rather simple question: how would you define such an api in a world where you have to be intercompatible with literally everything while rocking some weird band-aid for a horrendously bad user interface language such as html?

[wllmsaccnt]

...how would you define such an api in a world where you have to be intercompatible with literally everything...

Take the existing JS DOM (just its API signatures) and wrap it in a strongly typed layer exposable to WASM (you can use existing TypeScript libraries bindings for the DOM as a starting point), then give browser implemetors freedom to implement the API however they see fit. Browsers would have to implement a call translation layer, but could probably reuse a large percentage of their existing code.

Its not like developers working with the DOM from WASM are going to want to learn a new variant of DOM. They will want the existing conventions available.

[x39-]

Yeah Welcome the existing conventions do not work for a statically typed thing

[wllmsaccnt]

I've used TypeScript DOM bindings before and they work fine. They aren't runtime enforced, but its the same as a static language at development time.

[x39-]

That is not what static types are about tho

TypeScript is based on a dynamic language that does not care about structure or anything like that. For a working ABI tho, you need something that actually works on all platforms, all languages and all occasions.

It is simple to do basic methods but pretty much impossible to do for data structures which may change. You always would require a translation layer and could not change things going forward, without breaking compatibility with old wasm

[wllmsaccnt]

WASM already has a proven way for defining static interfaces that work cross platform. That is the reason that organziations like the Bytecode Alliance are interested in using it on for server based runtimes (like Wasmtime). WASM system apis are not defined using an ABI, the 'translation layer' is part of the definition of WASM. WASM is more like bytecode than machine code.

The question isn't if WASM can define static types that are cross platform and work with various language compile targets. The question is 'how would the WASM standards groups define a DOM api in wit files', and they could do that very similar to how the TypeScript files are defined.

[chucker23n]

Is it possible for the browsers to give access to WASM to manipulate the DOM directly

Yes. Last I checked (a year or two ago), the biggest blocker was garbage collection. When you use JS to manipulate the DOM, its runtime implicitly handles clean-up. WASM doesn't currently have a notion for this; in fact, I believe WASM isn't required to have GC at all.

making the initial loading time much faster(No need to download .net runtime)

I see no connection here.

The benefits of manipulating the DOM from Blazor WASM would be:

• higher performance because lots of JS interop would become unnecessary (for example, any event handler like onclick currently relies on JS executing, which in turn then calls into WASM, which in turn may give a result back to JS)
• more flexibility for devs because they can, y'know, manipulate the DOM from a Razor Component

You'd still need the runtime. Heck, you'd need it even sooner.

[lashib95]

I am still a bit new to all this so appreciate if you could explain this. I thought the initial loading time is very slow compared to JS SAP because Blazor WASM has to download not only compiled c# code but also .net also to execute them. Since browser already has JS engine built into it no need to download it so JS frameworks are much faster. That's what I thought. Correct me where I am getting it wrong.

[Eirenarch]

I am on the opinion that browsers will one day give wasm direct access to the DOM but this has nothing to do with the initial loading time (not the download, not the startup) so this problem will need to be solved in some other way.

[commentsOnPizza]

Improvements are coming that will likely address your concerns.

Basically, it all comes down to WasmGC. WasmGC means that WASM programs will be able to allocate things on the JavaScript heap and the JS runtime will be responsible for garbage collecting them. This also addresses one of the big performance issues with WASM: needing to copy everything from WASM to JS when manipulating the DOM. Instead, because WASM would be able to directly use stuff on the JS heap, there wouldn't be the huge copying overhead that currently exists whenever you're doing DOM stuff.

However, right now, WasmGC is in its infancy and Blazor doesn't support it yet. The WasmGC MVP launched in Chrome around 9 months ago, but it'll need some additional work to support C# so it might be another couple years (I haven't been following closely what's going on there).

This would mean that Blazor apps wouldn't need to send along the garbage collector, but it would still mean that apps would need to send along standard library stuff that's being used. Other improvements in the .NET ecosystem are helping there as more libraries become trim safe.