Scott Hanselman

.NET and WebAssembly - Is this the future of the front-end?

August 12, 2017 Comment on this post [42] Posted in DotNetCore | Javascript | Open Source
Sponsored By

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 classic JavaScript TODO app, written with C# and .NET and Blazor

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.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
August 12, 2017 10:01
I think this is a good step forward, I'd personally however would like to see JavaScript replaced comoletely with something better. Honestly, every JavaScript or electron app is so slow these days it requires a dedicated VM
August 12, 2017 10:08
What continues to be overlooked here is the business problem of cost. It's amazing how MSFT is in business but continues to offer expensive solutions in this regard. When you couple JavaScript to a .NET project, you effectively double the amount of code that developers must write and maintain. Truly remarkable that this has been the prevailing guidance for so many years, rather than provide transpiled support in some fashion for .NET (as demonstrated in some unofficial and understaffed capacity by JSIL).

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.
August 12, 2017 11:16
I can't wait for this to become reality. I wrote a ton of Silverlight apps and could produce business systems that could be easily deployed in no time at all. It takes me 2-3 times to write the same app in .net/js and I'm never proud of the js code that I produce. I sometimes see the cool things that js can do but the downsides outweigh the benefits. Maybe one day we will replace the html/css mess with something more sensible for web apps but for now this will be a massive step forwards.
August 12, 2017 11:44
I believe, Microsoft should have embraced mono instead of trying to reinvent .net with .net core.
Mono is the turtle which already crossed the finish line, whereas .net is the lazy rabbit just started its sprint.
August 12, 2017 12:04
Onur - Respectfully, it seems you aren’t familiar with the relationship between Mono and .NET Core and .NET Standard.
August 12, 2017 12:09
One danger with this approach is that we have to wait for prerequisites to be downloaded before a web page can be displayed. Are we returning to plugins? Nobody likes the cookie wall or the busy indicator while preparing the page.

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.


August 12, 2017 12:49
It would be a great idea to have the VB6 programming language compiling to Web Assembly

NS Basic (a VB6-like language) already transpiles to JavaScript for web and mobile apps.

August 12, 2017 13:24
Scott, thanks for sharing this very valuable piece.
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.
August 12, 2017 13:57
Can we get Typescript for the back-end?
August 12, 2017 14:21
@Theo: Right now, you have to wait for .js files to download, including large parts of AngularJS or React on websites that use them.

Sooo... what's the difference?
August 12, 2017 14:33
Interesting stuff. Would be neat to see if there's a way to facilitate interoperability with existing JS. TypeScript really nailed this. If I could write C# for react applications, I'd be beyond interested.

All the power of nuget AND npm? Well that would just be too cool...

"What do you want?"
August 12, 2017 14:46
I am with @Theo. We just get rid of Flash, Java Applets and Silverlight and now we are going back there?

August 12, 2017 15:25
Theo & Slawek: the difference between this and Flash/etc. is that this is a web standard built right into the browsers' JS runtime. It will be interesting to see how things like Blazor progress, and how big the frameworks are compared to things like Angular. We now live in a world where, using tech like Xamarin Forms and .NETStandard, we can use the same C# code and .NET packages to build for almost every platform (Windows, Mac, Linux, iOS, Android, Tizen, IoT, Xbox, PS4, Switch). If that can be extended to include Browser, we've got all the bases covered. How is that not awesome?
August 12, 2017 16:37
Hello Scott, I think I am familiar with mono, .net core and .net standard.
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.
August 12, 2017 17:36
WASM is great and so's getting C# logic to run on other backends than the CLR, but I hope Microsoft stays away from trying to do ActiveX or Silverlight again, meaning trying to run your own UI stack on top of this and "abstracting away" HTML and DOM and CSS. While Silverlight was doomed from the start because of where the industry was heading, that didn't stop it from being a huge tar pit of developer effort in the meantime and those unlucky enough to bet on it had to invest twice - once to relitigate all the UI problems and once more to move off of it.

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.
August 12, 2017 17:52
Looks to me that Microsoft wants to skip the rising WebComponents age, and ffw onto a green field where to stick their flag and brand their cows.
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')
August 12, 2017 21:08
If someone has really good reasons why the plugins were so bad, I have yet to here anything convincing. What if the plugins had been open sourced instead? Change anything?

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
August 12, 2017 21:32
@Onur Gumus

Oh boy, you really are dumb.
August 12, 2017 22:40
@Niclas: No, open sourcing Flash or Silverlight or ActiveX or Shockwave or Unity Player or whatever it is would not really have changed anything. Java was open sourced, and went reasonably quietly compared to what we're seeing with Flash now.

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.
August 12, 2017 22:56
@John, Yeah just use insults when your wits can't keep it up.
August 12, 2017 23:25
This is awesome! I'm really excited about this!

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...
August 13, 2017 0:25
Scott, I would LOVE to see dotnet go all in on WASM/AOT/CoreRT, it's going to be the platform of the path 20 years.

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!
August 13, 2017 3:13
That's right.. seems everyone is enjoying themselves... how does one enjoy himself? hmmm...
How do you enjoy yourself Scott?
with WASM i mean... got interesting open source project?
August 13, 2017 5:38
6 years ago, when the Silverlight & RIA Services mania was going on, was really the time for program once! Apps were able to be built so cost-effectively and efficiently.
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!
August 13, 2017 5:42
@Scott: I've just watched your podcast and I'm really proud of you.
@Jesper: sure.
August 13, 2017 8:43
How many more times to we have to create the same models, viewmodels and validate the same thing... Simplify that first.
August 14, 2017 11:16
I'm surprised nobody has mentioned the Wisej.com framework. They've put together a really good product and it's removed so many complex layers when designing web apps. My background is mainly winforms business app development with SQL and there was practically no learning curve using their Wisej product.

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.
August 14, 2017 17:17
We junk that for Angular 4 and TypeScript. We can also create local NPM to share common Angular Component for multiple different websites, so we don't have to re-invent the wheel here.
August 14, 2017 19:22
I don't think RIA has any future in the browser. It's being replaced by native apps in app stores on various platforms.
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.



August 14, 2017 20:44
The inherent impedance mismatch between .NET/C# and all the frameworks available on the web is one of the major reasons TypeScript was developed (and has become so popular).

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.
Sam
August 15, 2017 8:30
The links are just golden nuggets! Thank you so much for sharing it.
August 15, 2017 12:46
Super awesome!I believe It is definitely the future.

MS should invest more on wasm, and bring C#/VB.NET to the front-end ASAP!
August 16, 2017 10:54
I am with @Theo and @Slawek. We don't need Plugins,
We are in age of speed, So we need the high performance?
August 16, 2017 12:08
Like everyone here I find the idea really exciting. This will truly achieve universal, cross-current AND future platforms (ie forward compatible), easy to deploy, no apple/google/microsoft toll/control applications. I can see that being massively used in the enterprise world, it solves so many problems, particularly in an intranet/wifi environment where loading a few megabytes of binaries isn't such a big deal, and which are .net shops way more than js shops (plus backward compatibility to current C#/VB code base). This could also help Windows Mobile's lack of apps problem since wasm apps will be compatible out of the box (should Microsoft ever wish to resurect it).

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?
August 19, 2017 21:22
I'm confused by 2 things:

'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.
August 19, 2017 21:57
*I mean dlls compiled from C#
August 22, 2017 21:50
I have been watching this closely, having many of the same thoughts/hopes on where this might be heading. Cross-platform development has been a promise made by many approaches over the years, with mixed results at best. There is still no less need for a great tech to be able to write native applications across OS's along with a simple deployment model.

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.
August 22, 2017 21:55
Totally agree with Bill re: XAML and HTML et al - enter Anders H?
August 23, 2017 5:49
@rod mac, if I understand where you're going with your reference to Anders, for larger and larger applications, developers need language features not currently offered in JS. TypeScript, among others, is one proven evolutionary step. I see WebAssembly giving us a new "vm" to build on, supporting many languages (C, TypeScript, JS, C#, etc.) with native performance. All web deployable.

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.
August 23, 2017 21:18
I'm not sure why there is all this hate against MSFT on this. WebAssembly is a collaboration between all the major browser vendors, not just MSFT. Also, WebAssembly has the potential to be one of the biggest technologies in the coming years (game changer, paradigm shift ... other marketing slang and buzz words). It will eventually allow for scenarios like writing a LINQ query against the DOM, allow for highly optimized compression and decompression of audio and video files, faster speeds for online gaming. It will allow ~80%-90% native speed execution according to the specs. You will be able to write front end code in the language you are most comfortable with. I love writing JavaScript, however, it would be nice to use C# for both the front end and the back end. I'm excited about the possibilities that this affords and look forward to its future.
August 24, 2017 3:22
@Bill my reference to Anders H has perhaps confused i.e. I don't mean extending TypeScript, rather I mean getting a calibre team to make that which CSS + HTML can achieve (the lowest denominator) interchangeable / creatable / portable with a subset of the XAML standard to effect the same (core XAML and framework XAML perhaps?). Of course it should be possible to achieve the same with C# or whatever language.

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.
August 26, 2017 3:59
Hi Scott, I saw Steve do this talk recently at NDC 2017 in Sydney AUS and was blown away. I briefly spoke with him and got even more excited. How do we, the community, help to make this go from experiment to something we can use in production? I think .net devs all over would love to work with their favourite language on the client and the server. Business would love it too as we'd be much more productive. Please make this happen 😀

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.