Thanks for visiting my blog!
In case you haven’t been following the news about WebAssembly (e.g. WASM), it’s a new way to build something akin to bytecode for the browser. The latest versions of most browsers now support it including Chrome, Firefox and Edge.
Microsoft has built an experimental release of something called Blazor that builds web projects in WebAssembly so you can write all your code in C#. But after playing with one of the builds, I’m starting to think about who this really is for. Let’s delve into what WebAssembly is and then how Blazor works to explain what I think.
What is WebAssembly?
There are a plethora of good descriptions of WebAssembly on the web, but I’ll try and summarize it in practical terms. Essentially, it’s a binary format for code in the browser. The expectation is that this code should run much faster than traditional JavaScript. This gives the browser several key benefits:
- Performance: Runs at near native performance
- Safe: Runs in a memory-safe, sandbox
- Polyglot: Compiles from a range of languages (.NET, C, C++, Java, Rust, etc.)
The big win I believe is that there are memory-rich jobs and multi-threading that JavaScript doesn’t handle well (e.g. image processing, computationally rich algorthms, etc.) that WebAssembly will do really well.
What is Blazor?
The ASP.NET Team has created a new set of tooling called Blazor. The idea about Blazor is to be able to combine Razor and C# into a client-side web project that runs completely in the browser. It does this by building on ASP.NET Core’s promise to run anywhere. You could think of it as an ASP.NET Core-based replacement for something like Vue and Angular. It feels very much like that.
Blazor is experimental. No idea if will become a real tool, but it’s an interesting take on what WebAssembly can do.
If you’re interested in Blazor, go get it here:
Who is Blazor For?
This comes down to the central idea of this short blog post, who is something like Blazor actually for? I ask this question because there is a rich set of tooling and skillsets for the current JavaScript world that the web sits on top of. Will WebAssembly simply replace JavaScript?
I, for one, doubt it. I think WebAssembly is much more likely to become an adjuct for JavaScript when performance is critical. I don’t see something like Blazor being that important. It reminds of of dropping down into C code when you need something really fast. It handles memory blocks and threads really well, but I think most of the web doesn’t need that.
But I do think Blazor is interesting for certain set of people: WebForms developers. Yeah, really. There is a large set of ASP.NET developers that are still doing everything server-side and are committed to C# as their one and only language. For them, Blazor fills a hole of being able to stay in their comfort zone. It also allows them to move to client-side development and leave the post-back era behind them.
My only fear here, is that Blazor might seem like the second coming of Silverlight and might kill it on the vine.
UPDATE
I agree with many of you about what WASM is for and what will happen. But I think that Blazor isn’t really for that. I think that pushing Razor/C# into the browser is heavy handed but has an audience. But what happens to WASM is going to be very interesting. I don’t think we can guess what it’ll look like in the future.
What do you think?
