</p>
Back in the olden days, you could use whatever programming language you wanted to write your client-side code: ASM</span>, C, C++, BASIC</span>, Java, C#, etc. Hell, every language had a client-side UI</span> framework attached (often more</a> than</a> one</a>). Then the web hit and we used those same languages to generate HTML</span> on the server-side. It was a polyglot world for client-side development right up until mobile made itself the #1 targeted format in the world (cue record scratching noise</a>).</p>
In a mobile/cloud world, the server is alive with programming languages, including Java, C#, Swift, JavaScript, Erlang, Clojure, Go and 100 others. But on the client-side, we’re relegated to just a handful:</p>
That’s pretty much it. As a C# guy personally interested in building a web app (specifically a Progressive Web App</a> that works great on both desktop and mobile devices), I was pretty frustrated. I could write any language I wanted so long as it was JavaScript.</p>
If you want, you could point out the large number of languages that</span> “</span>transpile” to JavaScript, including some C# variants, but every one of those that I’ve tried has been a very leaky abstraction — you have to know that they are just JavaScript translators and write your code accordingly. It’s a very different experience than the multi-language support on the Java VM</span> or .NET</span>, where the VM</span> provides a common environment for every language without any one language being</span> “</span>special” (although you could argue that Java shines through into languages like Clojure and C# into F#, but not nearly to the same degree). Really, in the browser, JavaScript is the only first-class language, along with HTML</span> being the only UI</span> framework.</p>
So, with PWAs on my mind, HTML</span> in my heart and JavaScript at my fingers, I started looking into JavaScript frameworks</a>. Unfortunately, they all of them left me wanting something much more like those old Microsoft UI</span> frameworks, but for the web.</p>
And then came Steve.</p>
In June of 2017, Steve Sanderson gave a talk entitled Web Apps can’t really do that</em>, can they?</a> in which he demonstrated the following:</p>
This talk blew my mind. This was the browser-based full stack for .NET</span> that I hadn’t even realized that I’d wanted. Steve’s demo made me realize that not only could Microsoft create an amazing end-to-end experience for .NET</span> developers that wanted their code to fit into the modern web, but they could do it in a way that worked across all form factors and all platforms.</p>
This demo wasn’t the end. Steve recently posted</a> an update talking about all of the contributors he’s had since his demo, but also the move to the more full-featured Mono .NET</span> implementation provided by Xamarin.</p>
Anyone experienced with Microsoft sees a clear path sketched out by the TOC</span> to any Windows-based UI</span> framework book:</p>
And as huge as this will be for the .NET</span> community (can you say</span> “</span>Silverlight without the mess”?), that’s not all.</p>
Right now, Steve’s proof of concept .NET</span> Runtime is a 4MB</span> download for any .NET</span> app. That’s clearly not going to work. As Steve mentions, there are lots of optimizations to do that’ll bring down the size, but the real optimization win is going to be when the next version of WebAssembly comes out, including two big features: plugging into the browser’s VM</span> and access to the DOM</span>. The WebAssembly working group are already discussing both of these (e.g. here’re the notes from a recent meeting discussing garbage collection</a>).</p>
With access to the browser’s VM</span>, a .NET</span> app won’t need to ship it’s own runtime for every app — it’ll just plug .NET</span> objects into the one provided by the browser. Now the .NET</span> runtime for the browser can be trimmed to a bridge to what the browser provides as well as the .NET</span> Framework base libraries. Combine that with</span> “</span>tree shaking” (removing the IL</span> your code never uses), code splitting and on-demand loading and you’ve got a .NET</span> WebAssembly app that even anyone on just their phone can love.</p>
But it’s really the 2nd thing that the WebAssembly working group is enabling — access to the DOM</span> — that enables a Cambrian explosion of client-side programming languages. WebAssembly already provides a language-independent calling layer enabling various languages to call not only between itself and JavaScript but also between every other language that compiles down to WebAssembly. Combine that with a standardized UI</span> layer — the HTML</span> DOM</span> — and WebAssembly enables a universal client-side runtime for any language</strong>. What this means is that I no longer have to have the Angular, React and Vue bindings to Bootstrap: if someone provides the UI</span> components for Bootstrap in any language that compiles down to WebAssembly, I can use it from any other language.</p>
And as amazing as WebAssembly is about to get for the client-side, I doubt this thing will stop there. NodeJS was invented to bring JavaScript and it’s underlying runtime to the server. Imagine doing the same thing for WebAssembly but for any language, server-side or client-side. Done right, WebAssembly has the potential to be what Java and .NET</span> have both tried and failed to be — the universal runtime for all languages across all platforms.</p>
But even if it doesn’t get that far, Steve has shown us that WebAssembly enables an amazing client-side experience. I can’t wait to get my hands on it.</p>
The mother of all web demos</h1>
</p>
What’s coming</h1>
WebAssembly is the key</h1>
Just one more thing</h1>
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.