.NET and WebAssembly - Is this the future of the front-end?
6 years ago Erik Meijer and I were talking about how JavaScript is/was an assembly language. It turned into an interesting discussion/argument (some people really didn't buy it) but it still kept happening. Currently WebAssembly world is marching forward and is supported in Chrome, Firefox, and in Development in Edge, Opera, and Safari.
"The avalanche has begun, it's too late for the pebbles to vote." - Ambassador Kosh
Today in 2017, WebAssembly is absolutely a thing and you can learn about it at http://webassembly.org. I even did a podcast on WebAssembly with Mozilla Fellow David Bryant (you really should check out my podcast, I'm very proud of it. It's good.)
The image above is from Steve Sanderson's NDC presentation. He's writing the classic client-side JavaScript ToDo application...except he's writing the code in C#.
What is WebAssembly?
"WebAssembly or wasm is a low-level bytecode format for in-browser client-side scripting, evolved from JavaScript." You can easily compile to WebAssembly from C and C++ today...and more languages are jumping in to include WebAssembly as a target every day.
Since I work in open source .NET and since .NET Core 2.0 is cross-platform with an imminent release, it's worth exploring where WebAssembly fits into a .NET world.
Here's some projects I have identified that help bridge the .NET world and the WebAssembly world. I think that this is going to be THE hot space in the next 18 months.
WebAssembly for .NET
Despite its overarching name, this OSS project is meant to consume WASM binary files and execute them from within .NET assemblies. To be clear, this isn't compiling .NET languages' (C#, VB.NET, F#) into WebAssembly, this is for using WebAssembly as if it's any other piece of resuable compiled code. Got an existing WASM file you REALLY want to call from .NET? This is for that.
Interestingly, this project doesn't spin up a V8 or Chakra JavaScript engine to run WASM, instead it reads in the bytecode and converts them to .NET via System.Reflection.Emit. Interesting stuff!
Mono and WebAssembly
One of the great things happening in the larger .NET Ecosystem is that there is more than one ".NET" today. In the past, .NET was a thing that you installed on Windows and generally feared. Today, there's .NET 4.x+ on basically every Windows machine out there, there's .NET Core that runs in Docker, on Mac, Windows, and a dozen Linuxes...even Raspberry Pi, and Mono is another instance of .NET that allows you to run code in dozens of other platforms. There's multiple "instances of .NET" out there in active development.
The Mono Project has two prototypes using Mono and WebAssembly.
The first one uses the traditional full static compilation mode of Mono, this compiled both the Mono C runtime and the Mono class libraries along with the user code into WebAssembly code. It produces one large statically compiled application. You can try this fully statically compiled Hello World here. The full static compilation currently lives here.
So that's a totally statically compiled Hello World...it's all of Mono and your app into Web Assembly. They have another prototype with a difference perspective:
The second prototype compiles the Mono C runtime into web assembly, and then uses Mono’s IL interpreter to run managed code. This one is a smaller download, but comes at the expense of performance. The mixed mode execution prototype currently lives here.
Here they've got much of Mono running in Web Assembly, but your IL code is interpreted. One of the wonderful things about Computer Science - There is more than one way to do something, and they are often each awesome in their own way!
"Blazor" - Experimental UI Framework running .NET in the browser
With a similar idea as the Mono Project's second prototype, Steve Sanderson took yet another "instance of .NET," the six year old open source DotNetAnywhere (DNA) project and compiled it into Web Assembly. DNA was an interpreted .NET runtime written in portable C. It takes standard IL or CIL (Common Intermediate Language) and runs it "on resource-constrained devices where it is not possible to run a full .NET runtime (e.g. Mono)." Clever, huh? What "resource-constrained device do we have here six years later?" Why, it's the little virtual machine that could - the JavaScript VM that your browser already has, now powered by a standard bytecode format called WebAssembly.
To prove the concept, Steve compiles DotNetAnywhere to WASM but then takes it further. He's combined standard programming models that we see on the web with things like Angular, Knockoutjs, or Ember, except rather than writing your web applications' UI in JavaScript, you write in C# - a .NET language.
Here in the middle of some Razor (basically HTML with C# inline) pages, he does what looks like a call to a backend. This is C# code, but it'll run as WASM on the client side within a Blazor app.
@functions {
WeatherForecast[] forecasts;
override protected async Task InitAsync()
{
using (var client = new HttpClient())
{
var json = await client.GetStringAsync(AbsoluteUrl("/api/SampleData/WeatherForecasts"));
forecasts = JsonUtil.Deserialize<WeatherForecast[]>(json);
}
}
}
This would allow a .NET programmer to use the same data models on the client and the server - much like well-factored JavaScript should today - as well as using other .NET libraries they might be familiar or comfortable with.
Why do this insane thing? "To see how well such a framework might work, and how much anyone would care." How far could/should this go? David Fowler already has debugging working (again this is ALL prototypes) in Visual Studio Code. Don't take my word for it, watch the video as Steve presents the concept at the NDC Conference.
Blazor as a prototype has a number of people excited, and there was a Blazor Hackthon recently that produced some interesting samples including a full-blown app.
Other possibilities?
There's lots of other projects that are compiling or transpiling things to JavaScript. Could they be modified to support WebAssembly? You can take F# and compile it to JavaScript with F#'s Fable project, and some folks have asked about WebAssembly.
At this point it's clear that everyone is prototyping and hacking and enjoying themselves.
What do YOU think about WebAssembly?
Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test and debug ASP.NET, .NET Framework, .NET Core, Xamarin or Unity applications. Learn more and download a 30-day trial!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
IVAN
Once code is encapsulated, its value proposition is leveraged knowledge, which can be seen in no greater example than the .NET Standard 2.0. JavaScript-based applications simply do not participate in this dynamic and therefore burden additional cost in time and resources when paired with .NET.
This is what makes the Mono proposition so exciting, as it will participate in .NET Standard 2.0 and provide the cost savings afforded by such a pairing. It will be like going back in time 6 years and working in Silverlight once again, which was predicated on such a paradigm. Only this time, we will have six years worth of experience in the modern UX era to improve upon its original vision and build something even bolder and better, all in the name of .NET and MSFT.
Mono is the turtle which already crossed the finish line, whereas .net is the lazy rabbit just started its sprint.
Webbrowsers support a clean separation of concerns (style, structure, content and behavior) which offers great flexibility. However we struggle to manage this flexibility effectively in non trivial websites. That's why I think the web model is broken.
NS Basic (a VB6-like language) already transpiles to JavaScript for web and mobile apps.
I think WebAssembly should have happened 5 years ago to the web.
But it's never too late.
Now let me get another Turkish Coffee and play around with this.
Sooo... what's the difference?
All the power of nuget AND npm? Well that would just be too cool...
"What do you want?"
I just fail to see what problem .net core and .net standard solves
that mono couldn't. Yes .net standard is an effort for standardization of different
.net implementations but do we need any other implementations other than mono?
Mono is already a cross platform decent runtime that
works everywhere even with some extra features that .net framework doesn't have.
I think we wouldn't be wrong if we say mono is more widely adopted and used
than .net famework and .net core combined if we consider the success of
xamarin and unity.
Those of us doing real work still need to treat the rest of the web as the platform it is - being on the web and adapting to the avalanche of new standards, techniques and devices increasingly means you need to be of the web. Whatever you make in terms of Blazor-like solutions should dovetail into the rest of the browser environment and the surrounding technologies or this thing is dead in the water.
Sounds reasonable, not complaining at all (you HAVE to R&D and experiment), but granting the good developer a solid mainstream platform first, that would be much appreciated.
I'm talking about the (still) missing features and the (still) awkward bugs in Edge.
(I'll give it a try tho')
I wish MS would have transpiled SL to JavaScript and HTML canvas, I really thought they would, it would have been a pretty quick way out and still keep all the LoBs out there happy. Sure some OOB would not work as the browsers don't allow it, but 95% would. They would have kept the develop/designer work flow (XAML is very powerful and well separated, usually better than a typical HTML/CSS/Javascript) as the world came to a full cycle.
If they believed so much that SL would die by itself they should have dared themselves and just open sourced it, just like they should with flash and not have some people decide the fate of others
The main issue is that there are already building blocks inside the browser. The DOM, Canvas, WebGL, CSS and JavaScript (and now WebAssembly) are "webby" ways of doing things inside a browser.
I'm not going to ignore that there is one compelling "story", which is: just put something together and as long as you don't care how that happens, as long as we keep all these abstractions up to date, for certain things we can get you most of the way there. That was the way with Web Forms and with Flash and Silverlight to a certain degree. And if you had to scratch an itch or solve a problem right now, it might even have been a good way.
The problem is that technology doesn't stand still. Modern smart phones uprooted a lot of things that people take for granted (including the core interaction model), and the further you had gotten from using the technologies that are native to the web, the harder it was to adjust. Not every single thing ever built in Silverlight would have to be adjusted to run on a phone screen, but clearly the web went from being surfed almost exclusively on desktop or laptop PCs to being about equal parts computers and mobile devices, which changes the calculus for which technology looks attractive. Choosing Silverlight went from "well, customers have to download a plugin" to "scratch that, it won't even work on tablets or phones". There's no way that doesn't have an effect on Silverlight.
Now, they could have redone it and based it all on Canvas and maybe WebGL and cross compiled things to JavaScript. I am not intimately familiar with all the tradeoffs, but I'm guessing this would have been a very research intensive, very labor intensive way of producing the world's most complex JavaScript library. And ironically, it would have made it harder to maintain the separation between it and the rest of the page, which Silverlight users may well have depended on.
It's not a question of whether it solves the one-off things where it works on a fixed set of computers and maybe for a fixed length of time. There will always be problems like that. But by and large, that kind of problem is dying out compared to how prevalent it was a decade or two ago. Nowadays, most pieces of software aren't built for one version and then maybe updated later. It's a continuous process. Most companies have departments to continually update their in-house software. You have to be cautious to not bet on things that won't be there. And as we've seen recently, even Flash, which had probably the best market penetration of any plugin ever, was capable of fading away over a long time because it punched a hole in the page and said "I'm going to do my own thing in here", and over the long haul it was replaced by things that could do it better, or without needing to pull in all of Flash with everything that that meant in terms of power consumption and security issues.
Which is not to say that picking a single JavaScript library that will stand the test of time is easy. There's a lot of churn here because the platform is still evolving. It took 20 years to work out a good CSS replacement to tables (CSS3 Grid and Flexbox). It took until now to have something like WebAssembly. The pieces are coming together for a competent base that works the same everywhere, and where people can write the business logic in the language they choose. The time is ripe for someone to exploit this. But I'm looking at this and I'm thinking that if Microsoft just chooses to do "UWP apps for the web" or "Xamarin Forms for the web", I will walk circles around these things, because they just aren't good user experiences, they don't fit the target platforms, and they will have learned absolutely nothing from Silverlight. The web already *is* an abstraction and a set of instruments. Put something together that will help us play them more effectively, not something to try to get us to ignore the underpinnings. History is littered by the graves of those who have tried and failed.
I've been playing around for a couple minutes and I've seen that it is super easy to do stuff.
I already have some questions, maybe what I want is not yet possible, but I have high hopes in this project and I wish I could contribute with questions, suggestions, ideas...
I've been a dotnet developer since dotnet was released back in 2001 and it's been an amazing platform, but the world of heavy VM's like JVM and CLR and JIT's simply don't make much sense in a world where apps need to start fast, stop often, and be efficient with memory and power(serverless/mobile/iot).
I still think back to your presentation a couple years ago at connect 2015 where you showed the native compilation on ubuntu with core, but the audience didn't quite grasp what that meant.
It's the future, and dotnet can lead the way. Very exciting to see this post!
How do you enjoy yourself Scott?
with WASM i mean... got interesting open source project?
As a LoB apps dev, I don't remember finally being so excited reading this news. I also hear Miguel de Icaza is also pushing this forward, and with XAML standard RTM, that means we'll finally have Silverlight back but in extreme native speeds!
MSFT should stop licking JS and HTML asses and give away some love to its native languages and technologies, such as C#, XAML, F# etc., and prove the world that Java or any other lang is a misconception!
@Jesper: sure.
I found the product when I was asked to design a web app and looked at all the web layers that needed to be known like asp.net, html, java, jquery, typescript, angular, bootstrap etc and thought there must be an easier way and turns out, there is! Development can be in C# or VB.net and you build your app just like you would build a winforms app, no need to wire up callbacks to retrieve data from the DB, it all just works seamlessly using standard classes in VS with full intellisense. The published app then runs in a browser. I've now got a complete databound business product that works on mobile and desktops and will be ready to roll next month. It's taken about 3 months part time and didn't require any further training on my part. It's not a free product but the price is well under US$1K.
Definitely worth a look if you're stuck or about to start a new project.
If you think about it, the web is best suited for finding information not rich applications.
How will the search engines cope with searching through RIA services written in web assembly? It will always be a hack.
Why are we going to boot an operating system just to directly launch a browser VM? What's the point? Platform independence? Yeah but it's not, the browsers differ. Stop using the browser as a solution to platform independence.
Any similar project will need to be able to either:
- Be able to easily use existing JavaScript libraries
- Or provide a full web capable UI stack
Without either of those these kinds of efforts are sadly doomed to failure.
Personally, I'm hopeful that MS will provide a truly cross platform UI and .NET stack that extends to the web (it seems like Xamarin Forms may go this way). Though I love TypeScript, the cost of developing a modern web app is still many times that of a desktop (or Silverlight) application.
MS should invest more on wasm, and bring C#/VB.NET to the front-end ASAP!
We are in age of speed, So we need the high performance?
I guess one challenge will be to make it completely js free, ie to provide .net primitives to interact with the DOM.
Hacking things is a great first step. Do you have the feeling this is likely to become one of the prime, Microsoft supported runtime in Visual Studio?
'an existing WASM file you REALLY want to call from .NET? This is for that.', yet Steve Sanderson's video clearly demonstrates C# code potentially running in WASM compatible browsers?
In a similar vein, why can't there be a C# to javascript compiler? There's an HTML5 project that does this.
I would expect that to make it most widely adopted, a set of tools would need to support UI's written using a .NET UI framework (XAML Standard?) as well as HTML/CSS/JS.
The UI frameworks can be somewhat of a separate discussion. If we were charged with developing the roadmap for such a cross-platform set of dev tools, would we require/expect everyone to switch to a single declarative UI language and control set (e.g. XAML)? Or would we also add support for an already widely adopted declarative language and control set (e.g. HTML and DOM) to appeal to more developers? The logic language could be C#, JS, TypeScript, C, or any other language that could be made to compile to WASM.
After seeing WebAssembly adopted by the major platforms, it was exciting to see Steve Sanderson's presentation as concrete hope that this vision could become a reality. Very promising!
@Scott Henselman, I am cheering you on to help make this a reality. This could not only be the future of the front-end, but the future of apps.
I have gone a bit off topic with my treatment of the UI (stemming from a naive dream about a degradative experience Windows to web from the good old WinForms and WebForms days, but instead things have got frustratingly more complex, Android and iOS aside, instead of moving forwards). So, your comments about devs being able to drop in from the HTML, JS, C# et al route are spot on.
Comments are closed.