Dajbych.net

The most pow­er­ful, per­for­mant and easy-to-use UI frame­work is HTML with CSS and JavaScript. Di­rectX has ex­tremely high de­vel­op­ment price and UWP is miss­ing many fea­tures which are stan­dard in CSS. Achilles heel of pure web de­vel­op­ment is JavaScript. When you use higher lan­guage com­piled to JavaScript, one ques­tion arises – is JavaScript an ef­fi­cient in­ter­me­di­ate lan­guage? The an­swer is no, and the re­sult is a web byte­code called We­bAssem­bly.

JavaScript is in­ef­fi­cient and slow. New fea­tures in ECMA Script 6 were so com­plex that com­pi­la­tor op­ti­miza­tions for ECMA Script 5 were not ap­pli­ca­ble. Com­plex lan­guage also needs a com­plex com­pi­la­tor which con­sumes more com­pu­ta­tion power. It does not mat­ter on PCs, but it mat­ters on bat­tery-pow­ered de­vices. JavaScript is one of the most en­ergy con­sum­ing com­po­nents in a web page. For ex­am­ple, down­loading and in­ter­pret­ing of JavaScript in the Wikipe­dia page takes about 30% of to­tal en­ergy needed to down­load and ren­der whole page (source: Who Killed My Bat­tery: An­a­lyz­ing Mo­bile Browser En­ergy Con­sump­tion).

asm.js

One at­tempt how to re­turn JavaScript com­piler op­ti­miza­tions back was asm.js. It was re­search project at Mozilla that aimed to de­fine op­ti­miz­able, low-level sub­set of JavaScript. It was able to com­pile C++ code to JavaScript which could run with near to na­tive per­for­mance. Browser de­tected op­ti­mized JavaScript code and used a spe­cific com­piler. JavaScript code was back­ward com­pat­i­ble with tra­di­tional com­pil­ers so sup­port of other browser ven­dors was not nec­es­sary.

WebAssembly

We­bAssem­bly is an en­hance­ment of asm.js. It ba­si­cally drops back­ward com­pat­i­bil­ity for higher per­for­mance. The browser ex­e­cutes a bi­nary code which is de­signed for fast pars­ing and startup. The lan­guage is not dy­namic, so it un­locks many fast CPU in­struc­tions. We­bAssem­bly has been de­signed jointly by all ma­jor browser ven­dors, so it has wide agree­ment upon how to op­ti­mize it. On 5th De­cem­ber 2019 it be­came a W3C rec­om­men­da­tion.

Blazor

Bla­zor is a .NET run­time able to run as a We­bAssem­bly. Un­like Sil­verlight, it is based on HTML5 and DOM in­stead of XAML with a cus­tom ren­der­ing en­gine. So which essen­tials it con­tains?

Blazor Compiler

Bla­zor Com­piler trans­forms .razor files to C# code which could be com­piled by vanilla C# com­piler. The main dif­fer­ence be­tween pro­cess­ing .cshtml and .ra­zor files is that Bla­zor com­piler is build­ing a syn­tax tree which re­flects DOM. It parses HTML and thus it re­quires well-for­mat­ted HTML.

Mono.net Runtime

One of .NET run­times is Mono, which was ported to We­bAssem­bly. It in­ter­prets .NET as­sem­blies. In the fu­ture an ahead-of-time com­pi­la­tion might be sup­ported be­cause it is used by Xa­marin.iOS and UWP. Vanilla C# com­piler will sup­port it with .NET 5.

Drive

Bla­zor has a po­ten­tial to su­per­sede Win­dows Forms, WPF, UWP and Xa­marin Forms. It could be a ma­jor UI frame­work for all .NET ap­pli­ca­tions. Well, al­most – Con­sole apps are im­mor­tal. Ini­tial re­lease of Bla­zor is sched­uled on May 2020.