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.
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.
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.
One of the recent ideas for the web development is WebAssembly. An open standard already implemented in most of the modern browsers.
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.
(…) pretty-printed in a textual format for debugging, testing, experimenting, optimizing, learning, teaching, and writing programs by hand.
Question is: didn’t we just make the whole round trip with web development history to end up writing websites in assembly language?
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.
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
- Forms and validation
- Dependency injection
- 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
All this makes a very nice set of features and possibilities to apply Blazor in future projects.
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.