WebAssembly and Blazor .NET – dreaming of sharing .NET code between the client & the server

Have you ever dreamed of writing c#/java/any-language-of-choice code for the client-side development? Sharing client and server code classes? No plugins and transpilation to JavaScript?

The promise of reusability

“Write once, run everywhere” said Sun Microsystems promoting Java in order to inspire people to use it. While being a nice promise and actually pretty inspiring, somehow it doesn’t make people really believe in it as of today. The world appeared to be more complex than that, especially in the mobile world.

Reusability is a concept that people tend to use to explain some very complex design decisions. I have noticed many times that people proudly express their ideas that are mostly based on the concept of reusability, which is rather hard to achieve on the day-to-day work basis. A lot of unnecessary complexity introduced in the software development world has been justified with reusability.

Today I wanted to introduce to you an experimental project from Microsoft called Blazor. The project has been initiated by Steven Sanderson, which for me is among the smartest people in the web development world (he’s the author of knockout.js). The project has been moved to the .NET Foundation and is actively developed since the beginning.  Following the headline from blazor.net website:

Blazor is an experimental .NET web framework using C# and HTML that runs in the browser.

Wait, what? C# in the browser? First time I heard about it I had a flashback. Back in the university days when writing the master thesis on WPF and Silverlight design patterns.

Wasn’t Silverlight the Microsoft idea for C# in the browser? Didn’t it die before people even noticed this technology? No lesson learned?

Disclaimer: I was in love with Silverlight development process so much, that even having plugin would not let me think bad about it. Silverlight was a really nice job from Microsoft if it comes to development. But when it comes to business, things were not going that good.

It’s again the reusability. Reusability of a piece of code, of skills between front, and back-end development for web etc.  Silverlight was an attempt to move C# to the client, but as any other plugin-based technology, the market quickly rejected this idea. What a waste of thousands of developers’ time, companies’ money and in general what a waste of positive energy and passion.

More recent experience for me was moving JavaScript to the server side using NodeJS, but as it seems, even with typescript the experience it was just not what I would expect, and sharing code often was more of a copy-paste-and-maintain style than actually referencing common code. I am sorry if you’re a JavaScript developer and you feel touched, that’s just my experience from .NET that I cannot convert to the JavaScript world, no offense 🙂

Experience shows that open-standards are very important, if not the only way to force the very powerful companies trying to conquer the web, to stick to the common rules. I think every person developing website some years ago will be happy to forget all the features that worked only in the given browser, or when styling a website was like if-else’ying everything. Standards, my friends, are the way to go.

This being said, up until now, web developers had actually only a few real standards when it comes to web development regarding development languages, supported widely by the browser providers. HTML, CSS, JavaScript and … that’s more or less it.

As Steven Sanderson said, in the podcast of Scott Hanselman, it is kind of sad that web developers have so limited choice for implementation language (JavaScript). Well, except transpilation and different frameworks (probably, several of such appeared only while writing this blog post :)).

Could you imagine a situation, where it is totally normal to write client-side code in C#, Java, Ruby, Erlang, F#, or any other language that you love? Seems like we’re not far away from this dream coming true.

WebAssembly

One of the recent ideas for the web development is WebAssembly. An open standard already implemented in most of the modern browsers.

Following webassembly.org:

WebAssembly CG members representing four browsers, Chrome, Edge, Firefox, and WebKit, have reached consensus that the design of the initial (MVP) WebAssembly API and binary format is complete to the extent that no further design work is possible without implementation experience and significant usage.

OK, what is it, actually? If you follow the same page, it basically looks like a blessing 🙂

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

(…) encoded in a size- and load-time-efficient binary format. WebAssembly aims to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms.

(..) memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines. When embedded in the web, WebAssembly will enforce the same-origin and permissions security policies of the browser.

(…) pretty-printed in a textual format for debugging, testing, experimenting, optimizing, learning, teaching, and writing programs by hand.

(…) designed to maintain the versionless, feature-tested, and backwards-compatible nature of the web. WebAssembly modules will be able to call into and out of the JavaScript context and access browser functionality through the same Web APIs accessible from JavaScript. WebAssembly also supports non-web embeddings.

Sounds nice? Maybe… That reminds me of some funny (even though some people say it’s actually sad to be true) article regarding modern JavaScript development, I encourage you to read it here.

Question is: didn’t we just make the whole round trip with web development history to end up writing websites in assembly language?

Not really. Just like we don’t write in assembly (in most of the cases) against the desktop.  This is not about writing code in assembly, but about having any kind of low-level language, that is efficient to handle during compilation and optimization, instead of running the whole optimization process against JavaScript code. The additional, standard layer in the code compilation process.

Actually, .NET gives you a nice perspective on that. That’s at the core of .NET design – write whatever language you like, whether it’s F# or C# or even Smalltalk if you like. The development experience must be just perfect, and the whole optimization process is then handled by the framework. This is done using Intermediate Language for .NET.  Web Assembly is very similar in this concept, the format of the output is actually binary, even the languages are very similar.

The thing is if we have this additional layer, why wouldn’t we compile C# this way?

This is where Blazor comes in.

Blazor

If you ask what does the name mean, it’s quite easy for the .NET developers that used to write anything for the web in the recent years. It’s a Razor based (hence suffix ‘azor’) framework for writing websites that combines HTML and C# for Browser (B-prefix). The ‘l’ in Blazor is just because it sounds nice 🙂 – according to Steven Sanderson.

First time I have seen Blazor around the middle of 2017, I was amazed that this is real. This is like the MVC Razor, but when you run the project, this is sending the .NET output to the client (a real .net DLL on the client). Please note the mono part:

As you could imagine, compiling a method that adds two integers seems quite straightforward, but what about Garbage Collection? How do you do this on the browser side?

The first answer, according to the picture above, is mono. Mono, since its acquisition by Microsoft, has been the main choice for mobile development as it is widely supporting many platforms, compared to other multi-platform approaches from Microsoft (like CoreRT). So you could notice that we have just downloaded mono compiled to web assembly (wasm is the extension for Web Assembly).

This means we are actually running a .NET runtime in the browser, and this is an efficient way to run it in the browser due to the web assembly usage here. How cool is that? Cool, but it has “a little” drawback:

That’s *not* nice. For clients that don’t have access to a high-speed internet connection, this wouldn’t be an interesting option.

That’s also touching a very important topic of performance (for a whole new post, or more a series of posts :)), let’s just name a few related concepts here.

The first thing to say is that there’s probably a lot of optimization to be done upon compilation (like JS tree-shaking/.NET IL Linker) that, of course, are not yet implemented as the project is really fresh. But that is still to come, for sure.

Also mono as a whole doesn’t necessarily have to be the full framework that we put on the browser (no need for desktop stuff there). The optimization is also an important factor when it comes to running the code, there’s an AOT (Ahead Of Time) compilation usage that Mono team is working on (vs. interpreted mode).

Since 0.5.0 version, there is also a Server-Side blazor, that allows you to run blazor on top of the CoreCLR on the server and the client-side topics like UI updates, events etc. are executed via SignalR (so you don’t even need to download mono on the client).

As you can see, there are a lot of questions on the topic, but one thing is sure – the project is run with community support, the Microsoft team responsible for the project have huge experience and they know what are the options for modern web frameworks, so we may assume things will get much better over time.

So, what is this blazor actually doing except enabling .NET in the browser? That is actually the best part. Blazor is designed to become a fully featured UI framework for SPA applications. Like, for instance, Angular, or React, but in .NET. So, on the roadmap we could already see features like:

  • A component model for building composable UI
  • Routing – must have in the web UI framework
  • Layouts
  • Forms and validation
  • Dependency injection
  • JavaScript interop
  • Live reloading in the browser during development
  • Server-side rendering
  • Full .NET debugging both in browsers and in the IDE
  • Rich IntelliSense and tooling
  • Ability to run on older (non-WebAssembly) browsers via asm.js
  • Publishing and app size trimming

Some of these are just standard of web frameworks today. When it comes to coding in .NET, an interesting feature is JavaScript interop – which means calling a javascript method from .NET and calling .NET methods from JavaScript! So normally, we could use RxJS in our blazor pages. Web Assembly is designed to work like that – to call wasm from JavaScript and to call JavaScript form wasm. This is really cool.

Intellisense and debugging is not anything new for people from the .NET world, but if your experience is mostly JavaScript, this will likely be a much better experience. Even much better than TypeScript in VSCode. The goal is that you will be able to see the real  C# code in your browser’s developer tools when debugging. There’s also the second part, with debugging experience of Visual Studio, which is almost perfect for me.

What about the obvious question about browsers that don’t support WebAssembly? Will your application work fine? The short answer is: YES. This is simply possible because WebAssembly is designed to be able to fall back to asm.js, which is a JavaScript standard that handles the same kind of thing, but via a JavaScript library implementation. This was actually prior to WebAssembly and for older browsers, that will be the compilation target. This is actually nothing spectacular, giving the polyfills used today everywhere to cover the missing standards.

All this makes a very nice set of features and possibilities to apply Blazor in future projects.

Summary

The dream of reusability makes us feel again like we can soon reach a level where you learn C# and are able to implement websites on the same conditions as JavaScript developers. Is this going to be true this time?

There are a lot of theoretical questions raised by developers around the globe regarding WebAssembly, like: will it kill JavaScript? I would be cautious with such a thesis. JavaScript survived the rise and fall of many technologies and I believe it will stay for long 🙂 although it’s nice to think that there might actually be a cool alternative for the developers from other technologies.

I hope that at this moment, after the short introduction of what Blazor is, you are at least a bit inspired to go deeper into this topic.

Blazor is still in an experimental phase, meaning that it has not been decided it will convert into a real, production shipped product from Microsoft. I hope it will.

What do you think about Blazor and WebAssembly? Do you think it is going to succeed? What are the features you would love to see the most in such a framework?

I would love to hear from you.

Cheers, Kuba.

3 thoughts on “WebAssembly and Blazor .NET – dreaming of sharing .NET code between the client & the server

  1. Pingback: dotnetomaniak.pl

  2. You really struck a nerve. Back in the day I thought all my Xmases had come at once with WPF hosted in (some, as it turned out) browsers – XBAPs. I produced a web application that made most others look primitive. But as a couple of our most important customers were on old Windows/browsers with no intention of upgrading – a wasted effort as you say.
    Blazor sounds promising and I will definitely be following with interest, but will be less of an early adopter this time round – if it comes to fruition – I hope it does.

    • Hey Hallam, thanks for your comment and sorry for your experience with XBAP 🙂 There are not many people I know that used it before Silverlight took its place. Indeed even MS shouts in every possible way that blazor is an experiment as for now, but even after official release, it might be wise to wait for few releases more till it stabilizes and settles properly in the market. Let’s wait and see.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.