WebAssembly and the Death of JavaScript

Key Takeaways

I'm talking to you today about WebAssembly and asking the question, uh, is this going to be the death of JavaScript? And, yeah, might not be the best meet up to ask a question like that. If you feel like throwing something at me, that's fine. Just wait till the end. That's all cool. So, I'm going to start off in typical fashion with a brief history of the web. And I'm I know the web is a complex, uh, complex set of technologies. I'm mostly going to be looking at JavaScript. And as I think most people have worked with JavaScript for a while know, the language itself was invented in a very short space of time by a chap called Brendan Eich. Uh, he invented it in just 10 days. And back in 1995, the web was a very, very different place. Uh, it wasn't the kind of dynamic single-page app, React type, um, environment that we know right now. It was mostly static pages, uh, the occasional form, and JavaScript was there to just add a little bit of interactivity on top of an otherwise pretty static web. Since then, other languages have come along, um, Java applets, ActiveX, Flash. You might have used some of these. Silverlight, my apologies if you've used that. Dart and so on. And that's it. That's the history of the web done because 2018, it's still JavaScript. It's still only JavaScript. JavaScript is the only language which is, uh, officially supported by the web. But the interesting thing is the way that we're using JavaScript has changed a lot in the 20-odd years since it was, uh, originally invented. I guess without going into too much detail, one of the things that's that that I've observed is that we collectively we write a lot of JavaScript. And when I say a lot, I mean a lot of JavaScript. Um, just the other day I I started up a new React app, so I used the create React app package. So, this is me creating a new application, uh, and then finding all the the JavaScript files within the project and doing a line count. 79,000 lines of JavaScript. That's a lot of JavaScript. And the thing is, we we're we're using JavaScript uh, for far more than just adding interactivity on web pages, which is the world that Brendan Eich was was creating JavaScript for. We're using it as build tools. We're using it on the server. We're using it on mobile devices. We're using it all over the place. But the weird thing is, the way that we're using the language itself has changed quite a bit. Um many years ago, I guess when I first started using JavaScript, it was quite simple. You'd open up a text editor, you'd write some JavaScript, it would be served over HTTP, and exactly the code that you you had written would be executed within the browser. That doesn't happen very often these days. Typically, the code that you write will be transpiled, it will be minified, it will be bundled, it will go through all kinds of really quite advanced transformations. And by the time it lands in your browser, it will look a bit like a garbled mess. And that's led a few people to consider JavaScript to be the assembly language of the web. It's it's a compilation target, as well as the language we use to to write our applications. But this is where Sorry, I'll move my cursor. This is where the problems start to to surface, because JavaScript actually isn't a very good assembly language. And it's no surprise. Again, reflecting on the context within which it was invented in the first place, it was never designed to be an assembly language. It was never designed to be a compilation target. And to understand why it's a bad compilation target, why it's not a good assembly language, you have to understand a little bit more about how JavaScript is executed within the browser. So, this is a a diagram that I took from a a Mozilla blog post, where they were giving a a a rough overview of how JavaScript is executed within the browser. So, the first bit on the left-hand side is a bunch of characters come along over HTTP, and they're parsed into a thing called an abstract syntax tree. It's a it's a tree-like representation of your code. After that, um it it generates some byte byte code, which is then run within an interpreter. And then this is where the really clever stuff starts happening. And many years ago, that was it. That was the way that JavaScript was executed. These days, a lot of work has gone into optimizing JavaScript. So, what will happen is the runtime will start to look at your code, look at the execution, and make certain assumptions. If you've got a function that is always called with a pair of integers, for example, it will generate an optimized version of that, and the execution of that function will become faster. And I think it was the um Safari browser has something like four different tiers of optimization, and that your code sort of moves up and down these tiers. So, as it as it can spot optimizations, it moves up a tier. But if the assumptions it makes about your code is false, it has to push it back down again. It's really, really complicated. And as you can imagine, this isn't an efficient uh compilation target. And how how does this actually manifest itself? One one of the things that as a JavaScript developer, most of us are or pretty much all of us are concerned about is the execution speed of our our code within the browser. And there's the One of the most important things that what something that people have been focusing on a lot recently is is the time to interactive, the time it takes to load all your code and actually start doing something. And this is a a timeline that I shamelessly borrowed from this fantastic blog post by Lin Clark. It's it's well worth a read. She does an excellent job of describing uh why WebAssembly is needed. But I'm just grabbing this diagram here. This is a timeline that approximates the execution of JavaScript within your browser. So, the first thing it does is it has to parse your parse your JavaScript. The next is it has to compile and optimize it. And then potentially, it will have to reoptimize it. And then afterwards, you've got a certain amount of execution and garbage collection. The timeline you see here, that the parse time, the compile time, the optimize time has a significant impact on how long it takes for your application to actually execute and be interactive. So, this is again why I'm saying that JavaScript isn't a good assembly language. This isn't If you were designing it from scratch, you wouldn't design it like this. And I guess this this little quote here, I think summarizes it quite nicely. This is a quote from the team that created WebAssembly. And they mentioned that the web has become the most ubiquitous application platform ever, and yet by historical accident, the only natively supported programming language for that platform is JavaScript. And this is coming from a bunch of guys who are web developers, and they love JavaScript. So, it's not They're not against the JavaScript language as it itself, but the the situation we find found ourselves is is a weird quirk of of history. So, that brings me on to WebAssembly. If you look at the WebAssembly specification and the WebAssembly website, they describe it as a new portable size and load time efficient format suitable for compilation to the web. So, it was designed specifically to solve some of the problems I've been talking about. Now, hand hands up if you've heard of asm.js before. Okay, that's that's good. So, an interesting part of the history of WebAssembly is quite tightly related to asm.js. Don't worry if you've not heard of it before, it it doesn't matter. I'll give you a quick illustration of what it is, and hopefully that will help you understand some of the design goals of of WebAssembly. So, asm.js was a a bit of an experiment. It was actually a bit of a wacky idea that was created by Mozilla, I think around about 5 years ago. And at that point in time, there were various other plugin-like technologies being considered. In the the standard plugin model is you take some other runtime, and you kind of bolt it onto the side of the browser. That's how that's how plugins worked. And at that time, there were other people considering other plugin-style models. Whereas, the Mozilla team came up with this slightly crazy idea of why don't we create this sort of virtual runtime that sits within the JavaScript virtual machine. So, they said, "Okay, we we need memory, so we'll just have a an array. That can be our memory. We need instructions, so we'll create effectively patterns within our JavaScript that represent those instructions." So, I'll quickly illustrate what it is and then show you why that is a great demonstration of a slightly better way of doing things. So, here's a here's a bit of code. This is some ASM.js code. Don't Don't worry too much about the detail. Top, this is a a a function written in C that does your standard Fibonacci calculation. I'm compiling it using a tool called Emscripten into ASM.js. And that's what you see at the bottom there. So, ASM.js is JavaScript, but it's a particularly peculiar-looking kind of JavaScript. I'll highlight a few things. I won't go into all the details, but the first thing you'll see here is the reassignment of the arguments to this function. So, A equals plus A. So, typically you'd use that to kind of coerce something to be a number. B equals B or zero, which means that it's exactly the same as it was previously. These are type hints. These are telling the runtime that um one of these is a float and one of them is an integer. You can see at the bottom it's returning plus C. Again, you can see the pattern here that res in my C code is a float. You can see that we've got in the JavaScript code a for loop. ASM.js doesn't support for loops. Here you've got a a do-while instead. So, that all looks a bit crazy and you might be asking, "Why on earth would you do that?" Getting back to the way that JavaScript executes within the browser, you can see what they were trying to achieve with ASM.js. So, what happens with within a browser that understands it? Well, firstly, if the browser doesn't understand ASM.js, it doesn't matter. It's just plain old JavaScript and it executes as normal. However, if the JavaScript recognizes ASM.js, and it does that by looking at this use ASM literal string at the top. What it does is it starts doing the the usual thing. It it it parses it into an abstract syntax tree, but then immediately it spots the patterns. It effectively reads the ASM.js assembly language and immediately is able to push it right up the right up to quite a highly optimized version of the code, skipping some of the quite time-consuming interpreter steps and optimization steps. So, as you can imagine, this is quite a neat idea, but I think ASM.js was only ever put together as a a technical proof of concept because one of the things they could never get around is the very first bit the bit at the beginning, the parsing the JavaScript language. And as you can see, it's ASM.js is itself pretty verbose. So, as you can imagine, parsing it to the abstract syntax tree has got quite a lot of overhead. But ASM.js was a great proof of concept that there might be a better way of doing things. And their early demos were really quite impressive. The Emscripten tool that they used also had logic in it to convert OpenGL code into WebGL code, and they were able to take some game engines and do some pretty impressive things. So, ASM.js pointed pointed people towards a a different and interesting approach to solving this problem, which was quite different to the standard sort of plugin model. As a result, the WebAssembly working group was formed. And it was formed 2015 with with representation from all the main browser vendors and a bunch of others. And quite impressively, within the space of 2 years, they managed to design their MVP scope for WebAssembly and and get it released in the wild. So, in November last year, it was turned on in all browse all major browsers without the need for flags. So, it's officially out there in the wild. It's also in Node version 8 and and beyond. And just earlier this month W3C published their first public draft as well. So they managed to get this done in a very short space of time and I think it was mostly because ASM.js effectively created a blueprint to demonstrate some of the concepts here. So I've talked a lot about WebAssembly but I haven't actually shown you any WebAssembly. So I thought the best way to do that was to actually show some code and talk around the code just so you get a better idea of what it actually looks like in in real life. So switching to code this is obviously where all goes horribly wrong. Um okay. So I'm going to start with a very very simple example. This is a function that adds two numbers together and it even though this is visual VS code that's actually C which is horrible and dirty and makes me want to wash my hands. But there you go. There's an add function and what happens is with my build my tool chain I'm not going to go into too much detail about that. My tool chain is compiling that into WebAssembly and there are two distinct formats that you can use to view your WebAssembly. The the obvious one is oh tiny tiny is in hex. So the output of WebAssembly is a binary format. So again recalling how JavaScript is is processed by your browser it no longer has to parse the characters into an abstract syntax tree. It's a compact binary format. But the more useful way of looking at it is the actually they've changed the final extension for this. It's the WAT format WebAssembly text format. It's a shame they didn't go for WebAssembly text format WTF as an extension that would have been awesome. But anyway this is my C code so I'm adding two two numbers together and this is what it looks like as WebAssembly. So a few little bits and pieces here. We've got the concept of memory. So memory within WebAssembly is very similar to the memory concept they invented with ASM.js. Memory is a contiguous array of bytes, and that memory is actually shared between the WebAssembly runtime and the JavaScript runtime. So, you can you can make uh writes to the WebAssembly uh memory from your JavaScript code. It defines functions. It's got um a a a whole lot of instructions. There are about 60-odd instructions, and it works as a stack machine. If you've done any If you've done any programming with some kind of assembly language or of some sort, uh the full instruction set will look quite familiar to you. WebAssembly can also export and import uh functions. So, you can export a JavaScript function from your WebAssembly module. Uh So, you can export a WebAssembly function from your module and invoke it from JavaScript. And vice versa, you can import a JavaScript module so that it can be executed by your JavaScript. So, that's that's my WebAssembly, and we've got the binary format. And I'll show you how it's actually loaded, instantiated, instantiated, and executed. Now, cuz I can't be bothered by with creating an HTML page to house this, I'm just doing it within Node, but it's pretty similar within the browser. So, we're we're loading the WebAssembly um binary format, and we're constructing a module from it, and then from the module, we're creating an instance. From the instance, we can invoke the exported functions. So, here if I execute add, it tells me that 2 add 3 = 5. So, here I've gone from JavaScript ex ex executed a WebAssembly function within the WebAssembly virtual machine and returned the result. That's all all pretty straightforward. I'll show you now some of the areas where it gets a little bit tricky. And now, I feel like I'm showing you a bit of a tip of the iceberg in that it's not a simple case of just writing a whole lot of code in WebAssembly, um creating an API layer, and invoking it from JavaScript. At the moment, it's relatively challenging to do that. One of the reasons for doing that is that WebAssembly has a very small number of built-in types. It only has four types and they're all numeric. So, it's got two floating points and two integer types. What that means is if you want to do something with something a little bit more advanced like strings, it gets quite complicated. So, my next little demo is just something which returns a simple string from my WebAssembly function and renders it from JavaScript. So, I'll just um put that there. Okay, so this is my C code. So, what I've done is I've created a a hello wasm string which is referenced as a character pointer. And I've got a function which is get message ref. So, what that's doing is is um returning the reference to the message. If we look at the compiled output, it's a little bit more complicated this time. We've got these things called data sections within our WebAssembly module and these are basically ways of instantiating your WebAssembly module memory to a known state. And here you can see it's actually writing hello wasm. It's writing something else which I think is the offset to Uh actually, I'm not sure. I'll have to check that one. It's writing something else. And here is how it's actually executed within JavaScript. And here you can see that simply by um changing it from an example based on integer types to strings, things get a little bit more complicated. So, we've seen this bit of code before. This loads our WebAssembly binary and instantiates a module. But now, to return the string, the the get message ref function isn't returning a string, it's returning an integer which is an index to the location of that string within linear memory. So, I'm having to get hold of a reference to my linear memory, create a create a buffer and iterate over that buffer, populating it with going byte by byte across my linear memory, reading the data out. And if I execute it, um it does indeed say hello wasm. And that's by all means not an exhaustive exhaustive demonstration of WebAssembly, but hopefully it gives you a a bit of a feel for how web how you use a WebAssembly module from within JavaScript and some of the current limitations that that there are. So, a little bit more on the WebAssembly architecture. So, WebAssembly itself is a stack machine. As I mentioned, it has four built-in types, um 67 instructions. Importantly, it's designed to support streaming compilation. So, there are some features that are specific to WebAssembly which reflect the context it's used within. Uh for the vast majority of use cases, your code is being streamed over HTTP. So, it makes sense that WebAssembly can be compiled in in a streaming fashion. And what that means is your your your browser is able to chop up the WebAssembly module and compile it in parallel on multiple threads. So, again, it's been designed to be very very fast. It will have also has some very simple validation rules. Um JavaScript and any other web-based language has a lot of a validation rules that ensure security. WebAssembly is just the same, but again, they've been designed in such a way that they can be processed um in serial as it's streamed in. And as I mentioned before, exports, imports functions, and has a concept of shared linear memory with JavaScript. Now, one of the first questions that people ask when they look at WebAssembly is, "Oh, great. This is going to be super duper performance. It's going to be really really fast." And I must admit, I've read a lot of blog posts which make some quite um quite impressive and to be honest, quite incorrect claims about the performance of WebAssembly. I've seen blog posts claiming that it's 100 times faster than JavaScript. Unfortunately, most of those blog posts suffer from the classic problem of doing micro benchmarking and either bench benchmarking the wrong thing as well. So, what I did was created a slightly more representative test case. I created a a Mandelbrot um and rendered that using C, JavaScript, and a bunch of different mechanisms for for um generating web assembly modules and I I compared the performance of them. And as you can see, the black line here is the native performance. So, that's my C code compiled directly on my Mac and executed natively. And the interesting observation immediately is, "Wow, JavaScript is really really fast. It's only about 20% slower rendering a Mandelbrot." And that's because of the many many years that's gone into compiler the runtime optimization for JavaScript. Disappointingly, when I ran it within web assembly, it was actually a little bit slower. And using WASM assembly scripts and a few other different approaches, I eventually through a number of optimizations managed to make it just a little bit faster than JavaScript. So, I must admit, I was a little bit disappointed by that result. I've had a look at other benchmarks and other results and most importantly, the paper that was published by the web assembly team, the uh the accepted sort of general feeling is that web assembly should be around about 20 to 30% faster runtime execution than JavaScript. But, because JavaScript is is really quite fast, there there aren't there isn't that much of a performance gain to be made. Where they expect web assembly to beat JavaScript significantly is the parse time and the initial compilation time. So, the time to interactive with web assembly should theoretically be a lot less than with JavaScript. So, in the future, one of the things I mentioned was that web assembly was developed over a really quite short space of time. And and partly, that was because they had ASM.js as a kind of reference implementation. Another reason is the current web assembly release is very much an MVP. They were quite aggressive about ensuring that they had a very small set of features so that they could release quickly. And the idea is that they're going to be releasing new features over the over the coming years. So, some of the things that it doesn't have at the moment is a garbage collector, and I'll explain why that's a bit bit of a pain later on. In the future, it will also have threading support, a thing called host bindings, which is a way as I showed you that the interface between JavaScript and WebAssembly is a little complicated at the moment, and if you want to start doing DOM manipulation from WebAssembly, that's hard. With host bindings in the future, that will become a lot easier. So, one of the final things I want to look at is um WebAssembly language support and what some people are actually doing with the language. So, I showed you a little bit of writing a bit of C code as a way to show you what WebAssembly actually looks like, the text format and so on, but most people aren't going to write WebAssembly in in its its machine code well, in its binary format or in the text format. Most people are going to want to use a language, maybe C, maybe not, Rust, Go. People are going to be using other languages and and treating WebAssembly as a compilation target. So, I'm going to quickly look at the different languages and their current level of support. So, the first one is C or C++, and this is the the very first language that that gained WebAssembly support, and again, that's due to its heritage from ASM.js. There's a tool called Emscripten that you can use to compile C to to WebAssembly, and Emscripten does a lot more than just a straightforward compilation. It has, as I've mentioned, it's got the OpenGL to to WebGL bindings, and it's got a whole lot of other things that make it quite easy to take an existing C code base and compile it to WebAssembly and put all the glue that's required around it to actually make it work. As I mentioned, it was originally used to to create the ASM.js concept. Some of the practical things I've seen people do with it, there's a there's a company that have a thing called PSPDFKit. It's basically a PDF renderer, And um just last year they started exploring the use of WebAssembly. So they've got a C++ code base, and they explored the use of WebAssembly as a way of of using exactly the same code base to do PDF rendering on the web. And they they found it quite a good experience. They they managed to create something which I think they're going to actually ship as a as a product um with very good performance. This one's the fun one. Uh JSC. So the um JavaScript Core, which is the uh JavaScript machine that runs within within WebKit, is itself written in C++. Now using Emscripten, you can compile C++ to WebAssembly. So what that means is you can take JavaScript Core, compile it to WebAssembly, and then run it on top of your JavaScript virtual machine. So what this is is um the the uh Safari JavaScript uh virtual machine compiled to WebAssembly running on Chrome, which is great. It's exactly what you need. Uh finally, um uh one thing you'll probably notice here is at the moment a lot of people are essentially experimenting with this technology. There aren't You won't find a huge number of really practical use cases yet. I think that's still to come. Although uh um where I work at Scott Logic, uh we've done a bit of work with a company called Active Financial, and they provide um uh they provide market data for people who need high-frequency data. So people that are doing um algorithmic trading, for example. And all of their distribution logic, all their serialization logic is written in C and C++. And they've been getting a lot of requests from from their their clients who want to start using it uh consuming this data from within JavaScript, either um perhaps AWS in a Lambda function, or perhaps within the browser. So we helped them take their C++ code, compile it to WebAssembly, and use exactly the same code to to to parse their packets of data and deliver their high frequency data to the web. So, that's something that we were able to achieve with Web Assembly. Uh Oh, that should say C C sharp. That's a mistake. Anyway, so C C++ that's the story. Um Java and C sharp, these ones are a little bit more challenging because as as you're I'm sure you're aware Java and C sharp are languages that both rely on garbage collection whereas C C++ you manually manage the life cycle of your objects. And because Web Assembly doesn't have garbage collection yet, that means it's a it's quite a a problem. It's quite a challenge to take Java and C sharp code and compile it to Web Assembly. There's an experimental project called Blazer um that's becoming an official I think ASP.NET uh experiment um which uses Mono. It Some of you may be aware of Mono as a way to run Java and C sharp within Web Assembly. And what they're doing is they're experimenting with a couple of different ways of doing it. One of one of them is interpreted mode. So, they're basically taken the runtime and compiled it to Web Assembly and they're executing they're executing C sharp DLLs directly within the browser. The other one is ahead-of-time compilation. So, they're actually compiling the DLL directly to Web Assembly and they're they're experimenting with these two side by side. Blazer is a project that wraps around Mono's Web Assembly support and it's a fully featured uh single page application framework. So, there's a lot of um C sharp developers getting quite excited about the potential of Blazer. I don't have anything practical to show on on C sharp and Blazer because it's very very new and I don't think anyone's done anything practical with it quite yet. So, I guess one of the final ones to talk about is is JavaScript. So, why why shouldn't you compile JavaScript to to Web Assembly? And then there's a lot of people writing React applications and all kinds of other JavaScript based applications. And and you look at the features you get with WebAssembly and you think, "Yeah, I'd like some of that. I'd like my JavaScript to to parse more quickly, to be optimized immediately." So, there are a lot of people trying to find creative ways to compile JavaScript to to WebAssembly. And obviously, there are even more challenges there. So, firstly, you need a garbage collector. Secondly, it's not statically typed. So, you've got typing as a bit of an issue. There are a couple of projects I've been keeping an eye on that um are trying to tackle this. First is called Walt, which is a JavaScript-like syntax for WebAssembly. So, what they've done is they've taken that text-based format which I've shown you and tried to map it as closely as possible to JavaScript. So, it's it's a thin veneer on top of the WebAssembly text format. The other one that I've actually had a bit of a go with is AssemblyScript. So, in order to solve the typing issue, that's pretty straightforward with JavaScript these days. You've got things like Flow and TypeScript that introduce typing. So, with TypeScript, you can um enforce typing of your code and use a very similar uh compilation path that you do for C and C++. Um at the moment, that project is is in its early stages and they're currently awaiting news of when garbage collection will appear within WebAssembly to make some fairly critical design decisions about how they how they tackle that. I've actually got a bit of a demo. Uh hopefully, I've typed in the Wi-Fi password. So, has anyone used D3 before? Yeah? Cool. Yeah, everyone loves D3. So, this is a D3 force layout. But what I've done is I've taken D3 force layout and taken all the algorithmic code and rewritten it using TypeScript and compiled it to WebAssembly. So, basically, the um the standard sort of N-body algorithm and the kind of Hooke's law spring concepts are all being computed here within WebAssembly using TypeScript. And it was quite an interesting experiment for me to see how easy it is to take a a JavaScript application that wasn't written in TypeScript, add type information to it, and then compile it to WebAssembly, and work out how to manage the interface between the two. So, actually, if you scroll down, uh if you scroll if I scroll down, you can see it's got it it it supports exactly the same API as D3 itself, but all the computation's being done in WebAssembly. That That was good fun. I enjoyed that. Actually, I'm going One thing I'm going to do is I'm going to get rid of that demo because it's got a memory leak. Yeah, I know. Um the final one I want to briefly touch on is is Rust. Um has anyone used Rust here before? No? Definitely the wrong room for that. Oh, a few? Yeah? So, Rust is is gaining popularity quite quickly. If you ever have a look at the sort of uh metrics uh Stack Overflow does a survey every year, and they do quite a lot of data analysis, and Rust seems to be a programming language that makes people really really really happy. So, it's it's a modern language. It's a very very popular language. Significantly here, it doesn't require a garbage collector. It's got quite an interesting memory model that has the concept of ownership. So, every every object that's allocated on the heap is only ever owned by one reference at one point in time, which makes it very very easy to reason about memory and clean up memory. It's hard getting your head around it initially, but it's a good concept. So, within Rust, what they did was they used the Emscripten tool chain, and they're actually investing time in creating some better tool chains. And I I found this quote actually from someone within the Rust community that who says, "We're poised to be the language of choice for for WebAssembly." And the reason for that is it's a much-loved language, and because it doesn't need a garbage collector, it's actually in a great position for for being compiled to WebAssembly right now. So, um I had a bit of a play with it myself. I created a a Chip-8 emulator. So, Chip-8 is a a pretty old engine for for playing arcade games. I say engine, it was it was one of the very first virtual machines, actually. It was developed by someone who at the time came up with a concept for a virtual machine for playing games that could then be incorporated into a number of the the current computers at the time. It was a great idea. Wasn't terribly successful, but it's great for people who who want to experiment with creating emulators because it's actually quite a simple machine to emulate. So, for me, this was great fun having a go at Rust. I'd not I'd not used Rust before. So, trying to do Rust, write an emulator, which I'd not do before, and then compile that to WebAssembly, that that kept me up a lot of nights, but that was good fun. But, having said that, um people are doing some really practical and useful stuff with Rust and WebAssembly. And again, a lot of this is coming out coming from Mozilla. So, in in a very recent blog post, um they've talked about some of the work they've done on source maps. So, source maps, uh is if you if you're not aware of what source maps is, source maps is a technology that allows you to map that highly mangled version of the code that runs in your browser to the source code that you created in the first place. So, source maps are a way of mapping from one representation of code to another. And source maps are, as you can imagine, quite computationally intensive, but the most popular source maps uh library that supports um parsing and and understanding source maps is all written in JavaScript. And the team behind it decided to take some of the most um performance-critical logic, rewrite it in Rust, compile it to WebAssembly, and then evaluate the performance. And you can see here one of the performance metrics they were looking at was the time it takes from uh setting a breakpoint to being able to actually inspect your code. So, basically, to be able to to uh parse I don't know if parse is the right word, but understand the source maps and map the breakpoint back to your original code. And as you can see here, the WebAssembly performance, I know the text is a bit small there at the bottom, but the WebAssembly performance is these little blue clusters. So a couple of observations, the first one is clearly WebAssembly is is quite a bit faster, in the order of two to three times faster. But another interesting aspect here is the JavaScript performance, you'll see quite a spread in performance. And that's is because again of the nature of the way that JavaScript is executed. It goes through multiple tiers of of optimization where it might be optimized and then deoptimized. And what that means is your runtime performance isn't terribly predictable. Whereas within WebAssembly, the runtime performance is highly predictable in comparison. So that was that was a a fantastic blog post and a really interesting read. And the interesting thing is even though this was done as an experiment, if they're happy with it, if all the unit tests run, they can put that in production now. And everyone who uses source maps, directly or indirectly, is then going to receive the performance boost. So finally, I want to do a bit of crystal ball gazing. So as I as I've shown you, that the current state of WebAssembly is is is variable depending on language. And in terms of what people are doing with it, again, there's lots and lots of experimentation. But now I think we're starting to see the signs of where it's actually going to be used in the future and how it's practically going to be used. So my prediction for 2018 is, as you can imagine, lots more creativity. Mostly coming out of of languages like Rust, but we're also seeing a lot of creativity with C#. I have a feeling the Swift community are going to be very very keen on this, because Swift has a lot of common attributes with Rust. It's a modern language, it's quite a pleasant language to use, and also using ARC, automatic yeah, automatic reference counting, it's got a memory model that's quite compatible with WebAssembly. Also, within 2018, I don't know if you noticed, 2 days ago there was a new webpack release, version 4, and that included web assembly support. So, web assembly as as a tool chain now allows you to import Rust directly within your code, and web assembly sorry, webpack, because it's magic, will do its magic, and the right thing will pop out the other end. Hopefully, if you get your configuration right. So, yeah. If you get your configuration right, it's great. If it's not right, then it's hell. But, um I also think that within 2018, you'll start to see web assembly sneaking into your daily workflow without actually knowing it. So, as I I showed you right back at the beginning, when I create a React application, it it adds 79,000 lines of JavaScript to my machine, and most of that code is is being used at build time. Very little of it is actually being used at run time. I think that 79,000 is going to start going down as people start to use web assembly to hit performance-critical parts of your of your tooling. Another thing I think you're going to start seeing is native node modules using web assembly. I don't know about you, but I find it quite frustrating that the workflow involved in using node modules that have native code. There's a lot of friction there. Now, there there isn't a terribly good reason to do that anymore. You can actually ship web assembly instead. So, 2019, um within web assembly itself, I'm pretty sure we'll start to see garbage collection, host binding, threading. We'll start to see web assembly itself become a lot more powerful. As a result, C# and Java, some of the languages that require a garbage collector, will become first-class citizens of of the sort of web assembly ecosystem. I think we're also going to start seeing um Wasm UI frameworks. So, we're going to start seeing UI frameworks that are targeted that are entirely written as web assembly in and and geared towards um perhaps C# or Java developers. And we're already starting to see that. I saw a project which was called ASMDOM, which was a virtual DOM, so modeling the React concept, a virtual DOM written in C++ compiling to WebAssembly. Whereas next year, I think that'll actually start to become a practical option. Also, I think we'll see more of our our general plumbing move to WebAssembly. For example, again using React as an example, it does some computationally intensive tasks to do the DOM diffing. Why not put that in WebAssembly? Uh others other frameworks, for example, there's a I think called the Glimmer VM, which is a templating engine which is in one of the UI frameworks which whose name I can't remember, but I'm pretty sure that will move to WebAssembly as well. Interestingly though, I think we're going to start seeing Rust, Go, Swift, and other languages start to gain some web market share. You might think that's a good thing, you might think that's a bad thing, but I honestly think it's going to start happening. 2020 and beyond, again I'm going to go back to that quote. The the web has become the most ubiquitous platform ever, yet historically by accident, the only language that is supported by the browser is JavaScript. I think in 2020, we're going to see that that being challenged. Um JavaScript will no longer be the only language of the browser and the web. I also think people are going to start making significant progress towards compiling JavaScript directly to WebAssembly. Again, for the very reason that JavaScript is a perfectly good language for writing web applications. There's absolutely nothing wrong with it, but at the same time, as as JavaScript developers start seeing Rust developers and uh Swift developers benefit from WebAssembly, they're going to be wanting to get some of that as well. My gut feeling is that the JavaScript language itself will start to um move towards some of the TypeScript concepts to allow WebAssembly compilation. Uh if you've been following the way that TypeScript has evolved over time, TypeScript has deliberately stayed on a relatively convergent path with the JavaScript language itself. I have a feeling that some of these features, typing for example, might become a first-class feature of JavaScript in order to allow us to compile to WebAssembly. Finally, I guess it regretfully, I do honestly think JavaScript's popularity will decrease a little bit. Is anyone going to throw anything at me quite yet? No, maybe leave leave it a little bit. I'm I'm a big JavaScript fan myself, honest. No, but I do honestly think JavaScript has got a monopoly at the moment and and the web platform is ubiquitous. It I don't I think it's a safe bet that JavaScript will start to have a bit of a fight with some of these other languages. But, at the same time, I think the reach of the web will increase even more so. I think through progressive web apps. So, progressive web apps are currently talked about mostly within the context of mobile, but progressive web apps make a lot of sense on the desktop as well. So, I think a combination of progressive web apps and the ability of WebAssembly to allow you to do computationally intensive, complex operations will mean things like Photoshop, for example, will become a progressive web app. I think things like AutoCAD the AutoCAD team already are looking at WebAssembly. I think the ubiquity of the web will increase or the ubiquity of JavaScript will will and WebAssembly will increase move more onto the desktop. So, yeah, that that pretty much brings me to the end. WebAssembly and the death of JavaScript I'm going to say no, it's it's not going to die, but I think it's got a real fight on its hands. And if you disagree, you can start throwing things at me right now.