BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Colin Eberhardt on What WebAssembly Is, and Plans for Version 2.0

Colin Eberhardt on What WebAssembly Is, and Plans for Version 2.0

Bookmarks

Wesley Reisz talks to Colin Eberhardt, the Technology Director at Scott Logic, talks about what WebAssembly (WASM) is, a bit of the history of JavaScript, and plans for WebAssembly 2.0 including the threading model and GC.

Key Takeaways

  • WebAssembly brings another kind of virtual machine to the browser that is a much more low-level language.
  • One of the goals of WebAssembly is to make a new assembly language that is a compilation target for a wide range of other languages such as C++, Java, C# and Rust. C++ is highly mature, Rust is maturing rapidly. Java and C# are a little further behind because of the lack of garbage collection support in WebAssembly. At some point in the future WebAssemblywill have it’s own garbage collection perhaps by using the Javascript garbage collector.
  • At runtime you use JavaScript to invoke functions that are exported by your WebAssembly instance. It should be noted that at the moment there is quite a lot of complexity involved in interfacing between WebAssembly and JavaScript. A lot of this complexity comes from the type system.
  • WebAssembly only supports four types - 2 integer types and 2 floating point types. To model strings you share the same piece of linear memory - memory that can read from and write to from both WebAssembly and JavaScript.
  • WebAssembly is still a very young technology. Future plans include threading support, garbage collection support, multiple value returns. 

What is Web Assembly?

  • 2:11 A deeply technical definition doesn’t really tell you much about what it really is.
  • 2:21 In simpler, less technical terms, interactive web applications in the browser depend on the JavaScript virtual machine, which runs the JavaScript language.
  • 2:31 Web assembly brings another virtual machine or runtime to the browser.
  • 2:36 The difference is that JavaScript is a very high level language - an interpreted language - whereas web assembly is a much lower level language.
  • 2:51 It’s a new low-level language which runs in the browser.

What does the text format-like mean?

  • 2:56 If you’re writing code to run directly on a microprocessor, the instruction that the processor understands is a low-level machine code; bytes and so on.
  • 3:06 Most assembly languages will have a slightly more readable version - the assembly language.
  • 3:16 You’ll have opcodes being represented as mnemonics instead of bytes.
  • 3:21 So the text format you see for web assembly is just a more human version of the binary format which is the underlying web assembly itself.
  • 3:31 It’s a very light syntactic sugar - there’s almost a 1-1 mapping between the text format and the binary format.

How is web assembly different from writing, say, Flash?

  • 3:35 Part of the reason why people think it sounds similar is because one of the motivations of creating web assembly is to create a new assembly language which is a compilation target for a range of high level languages.
  • 3:50 So C#, Java, Rust, C++ and others are now able to be compiled into web assembly and run in the browser.
  • 4:00 That immediately makes people think of how they used to be able to run those kind of languages in the browser.
  • 4:05 There are some very fundamental differences in the way this is being achieved. 
  • 4:15 Flash, Silverlight and so on used the plugin model, which is a bolt-on to the side of the browser that lets you have a different execution environment and a restrictive API to communicate between that runtime and the first-class runtime in the browser.
  • 4:30 Web assembly isn’t like that; it is very tightly integrated within the JavaScript virtual machine, and there’s a very close synergy between the two.
  • 4:45 The other difference is in the way it was created.
  • 4:50 Silverlight was an invention pushed by Microsoft; Flash was an Adobe creation [ed: FutureWave created Flash, who were then acquired by Macromedia and then subsequently Adobe].
  • 5:00 They were created in an era of competition, and they were different plugin vendors and browsers.
  • 5:10 Web assembly was created through collaboration, with significant representation from browser vendors.
  • 5:20 That has a significant impact on its adoption; it’s been adopted and moved into production browsers in a very short space of time.

What is the core problem that web assembly is trying to solve?

  • 5:45 Personally, when I look at the way we run applications in the web at the moment, I think they are incredibly inefficient and convoluted.
  • 6:00 JavaScript used Babel or TypeScript, to create a modern typed language around JavaScript.
  • 6:10 We have complicated and advanced build tools that do things like tree shaping, minification, transpiling and so on - it can be quite obscure.
  • 6:25 To pass that code to the browser, it’s only option is to transpile it down to one of the more basic JavaScript versions and send it as text.
  • 6:35 It’s pretty inefficient.
  • 6:40 The browser then has to parse the text into an Abstract Syntax Tree, then run it in an interpreter, then move it through various different optimisation levels so that your code gets faster.
  • 6:50 On the development side, we’ve got some advanced tooling.
  • 6:55 On the browser, we’ve got an advanced runtime with multiple levels of optimisation.
  • 7:00 In the middle, we’ve got a horrible mechanism by where we’re delivering it in a basic and very inefficient text format, because that’s the way the web was designed.
  • 7:15 The impact of the bottleneck is twofold; one is the time it takes to deliver that to the browser, and the other is the overall performance and the time it takes to warm up the JavaScript code to run quickly within the browser.
  • 7:30 Ignoring the fact that web assembly brings different languages to the web, JavaScript itself is pretty inefficiently executed.
  • 7:40 Web assembly in simple terms solves that problem.

Doesn’t the advent of web assembly mean that we will see larger binaries being delivered to clients?

  • 8:10 I can understand the concern, but within the web we’ve optimised for performance and size - but on the desktop there hasn’t been that much pressure.
  • 8:25 If a desktop executable is 50Mb or 100Mb it generally doesn’t matter - but if you add an extra 20% payload to a website, people care about that.
  • 8:40 Technically speaking, if you take a single algorithm - like one that renders a Mandlebrot set - if you compile that to minified JavaScript and separately compile it to web assembly, the web assembly will be smaller because it’s a binary format.
  • 9:30 On the web, we have the notion of bloat - it doesn’t matter whether we’re talking about JavaScript or CSS.
  • 9:35 You’ll find people putting JQuery in the page to use a single function, or all of Bootstrap when they’re only using one or two classes.
  • 9:50 With all of these technologies, you’ll find there are ways to optimise them: with Bootstrap, you can customise your own build, for JavaScript you can use tree shaping, which means you only deliver the required code to the browser.
  • 10:00 You can create bloat in any technology - but people care about this, and our tooling is quite advanced these days, so you can do some clever things.

How does wasm inject itself into a web page?

  • 10:55 Our web assembly hello world is something that returns the sum of two numbers.
  • 11:00 There are various reasons why that’s simpler.
  • 11:05 If you’re creating a web assembly module that just adds a couple of numbers together, you’ll start with a high level language.
  • 11:20 You might choose Rust or C++ - either way, you’ll write a simple function that takes two numbers, adds them together, and then returns the result.
  • 11:30 You’ll take a toolchain for that language to compile it into a wasm binary.
  • 11:35 The wasm binary itself has sections within it that export and import functions - similar to JavaScript modules, which export and import functions.
  • 11:50 At runtime, what happens is that the JavaScript code will load up the wasm code, and you’ll be able to see it and invoke it from JavaScript.
  • 12:05 Under the hood, rather than that function being interpreted as JavaScript code, that function will be the web assembly virtual machine.
  • 12:15 That’s how you currently load wasm modules through JavaScript to invoke compiled code.
  • 12:30 One of the things that web assembly at the moment is there’s quite a lot of complexity involved in interfacing between JavaScript and web assembly.
  • 12:45 Calling functions is really easy - you can send stuff backwards and forwards, but it’s the types that you’re sending back and forth that is the challenge.

How is it used today?

  • 13:45 The trickiness is that wasm only has four types at the moment; they’re all numeric (two integer types and two floating point types).
  • 13:55 What that means is that implementing a wasm function that adds two numbers is fairly trivial; but Strings are more difficult.
  • 14:15 One way to handle string data at the moment is to use linear memory; it has memory that you can read and write to from web assembly and JavaScript.
  • 14:25 The interesting thing here is to model strings, you share the same piece of memory with null-terminated data.
  • 14:40 Real hello world application would look a bit complicated and slightly strange, which is why people who use it use a high-level toolchain.

Is wasm ready for production use?

  • 15:10 It’s called assembly - if you look at the way that PIC micro-controllers and 6502 processors, it’s very similar - none of them understand strings.
  • 15:25 It doesn’t mean that you can’t write applications just because the processor doesn’t have an innate understanding of what a String is.
  • 15:35 It just means that most people won’t write the assembly language directly; they’ll rely on a compiler where someone else has done all the magic.

What success stories are there of people using wasm?

  • 15:50 Not too many at the moment - because it’s quite a new technology.
  • 16:00 Some of the interesting examples are coming from Mozilla, because they’re a big backer of wasm.
  • 16:05 The interesting examples are where the complexities of JavaScript and wasm interfacing is minimised, because they’re doing very simple things.
  • 16:15 You won’t find people using wasm to work in React, or DOM manipulating applications.
  • 16:25 A really interesting one that Mozilla published is part of our common toolchain was to assist with sourcemaps.
  • 16:30 Sourcemaps are a JavaScript technology to map minified or transpiled code back to the original source.
  • 16:40 It’s very widely used and very important for a lot of people.
  • 16:45 Mozilla took the JavaScript used to generate sourcemaps, and ported it to web assembly and runs approximately three times faster.
  • 16:55 From reading the blog post [https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/], it sounds like it will be released to production soon.
  • 17:00 At the moment it’s being used for fairly specialised algorithmic tasks.
  • 17:05 Web assembly is at the minimum viable product (MVP) stage and a young technology.
  • 17:10 The feature set is deliberately minimal - as the feature set expands along with the toolchain and the ecosystem - we’ll start seeing it used for all sorts of things.

When are we expecting to see wasm 2.0?

  • 17:30 There are a few things on the roadmap - big, exciting things like threading support and garbage collection support, which will make it easier to target from Java and C#.
  • 17:45 We’ve also got a few low level things, like multi-value returns.
  • 17:55 Host bindings will make it easier to expose JavaScript objects to web assembly.
  • 18:00 Integrating web assembly modules with JavaScript modules.
  • 18:10 I don’t know when these things will appear - there are a lot of proposals in the works.
  • 18:20 Much like the way JavaScript evolves and iterates, they aren’t going for a big bang - when something’s ready, they will ship it.

What languages are targeted by wasm today?

  • 18:45 Almost any language that you think of can target web assembly at the moment - they have just got different levels of maturity.
  • 18:55 C++ is highly mature, because it was used throughout the development of web assembly and asm.js.
  • 19:05 Rust is gaining maturity quite quickly, because the nature of Rust makes it easy to target web assembly.
  • 19:10 Rust’s ownership model is quite compatible with web assembly.
  • 19:15 Languages like Java and C# (and JavaScript as well) need a garbage collector.
  • 19:20 Web assembly doesn’t use a garbage collector, so a common approach is to take a garbage collector and compile it to wasm.
  • 19:30 You can find C++ garbage collector implementations, and you can compile and ship that as part of your application.
  • 19:35 Clearly that’s going to add extra size, bloat and is pretty inefficient.
  • 19:40 At some point in the future, web assembly will likely support garbage collection.
  • 19:45 I have a feeling rather than having its own garbage collector, it will interact with the host’s garbage collector.

What about threading?

  • 20:15 At the moment the threading model is the same as JavaScript, with a single thread of execution.
  • 20:20 When you invoke a web assembly function, your JavaScript virtual machine yields to web assembly.
  • 20:25 So you won’t have JavaScript and web assembly running in parallel.
  • 20:30 You can have web workers, just like you can in JavaScript, so you can parallelise like that.
  • 20:40 What will happen in the future? I don’t know.

Where did JavaScript come from leading to today?

  • 21:25 Prior to JavaScript, the web was a very static place.
  • 21:30 If you wanted to create interactivity in the browser, it involved a round-trip to the server.
  • 21:35 I remember mapping applications where you’d click to pan the map, and the whole page refreshed because that was realistically the only way to have interactivity.
  • 21:45 JavaScript was designed to support a modest amount of interactivity client-side.
  • 21:50 I don’t imagine that Brendan expected it to become as fundamental as it has become.
  • 22:00 I think it was being used as a way to perform interactive form validation where a round-trip to the server didn’t make sense.
  • 22:10 That was the reason why JavaScript was developed in a short space of time, and everyone knows it’s a bit of a quirky language.
  • 22:15 Unfortunately a lot of the quirks cannot be changed - you can’t change history, and you don’t like breaking the web.
  • 22:25 Browser makers spend a lot of time testing to make sure changes don’t break existing websites.
  • 22:30 That’s where JavaScript came from - it battled with a few plugins along the way.
  • 22:35 As we know, plugins died for a variety of reasons.
  • 22:40 JavaScript is now very mature - it’s evolving at a rapid space.
  • 22:50 When new language features come along, transpilers can be used to backport those features into older versions of JavaScript.
  • 23:00 For various reasons, JavaScript has become a runaway success - not just within the browser, but extensively on the mobile or smart watches.
  • 23:15 You can run JavaScript programs anywhere.

What about asm.js?

  • 23:30 The concerns I raised earlier, about the inefficiencies of delivery; a team at Mozilla started looking at a different approach.
  • 23:45 They came up with a proof of concept of a low-level virtual machine out of JavaScript.
  • 24:00 They took a very strict subset of the language, and like web assembly they have the concept of memory being an array.
  • 24:05 They defined their own language, on top of JavaScript.
  • 24:10 They built into their own browser something that understood the language they’d created, and optimised for it.
  • 24:15 The whole thing was a very clever and slightly crazy experiment, but it worked.

How is asm.js different from wasm?

  • 24:25 They are similar - they define an assembly-like set of instructions.
  • 24:35 Unlike wasm, asm.js is coded in JavaScript so is quite verbose and difficult to understand syntax.
  • 24:40 In addition, it is only optimised for Firefox (as far as I know).
  • 24:45 In hind-sight, it looks like a very early proof of concept for web assembly.

Where do you see web assembly heading in the future?

  • 25:00 I think web assembly is going to be very important for a lot of people for many different reasons.
  • 25:05 There’s significant interest in the Rust community because Rust is a popular programming language, yet it doesn’t have significant adoption.
  • 25:25 The tooling for compiling Rust to web assembly is very good - probably some of the best.
  • 25:30 So a lot of Rust developers are excited about writing Rust applications for the web, but also whether web assembly will increase the popularity of Rust as a language.
  • 25:50 There’s the Blazor project started by Steve Sanderson, now adopted by Microsoft, which is a framework that has a C# to web assembly compiler.
  • 25:10 You’ve got a lot of die-hard C# developers who are excited about the opportunity of using it on the web.
  • 25:15 There’s a lot of people, with existing skills, that are getting very excited about using web assembly.
  • 26:20 Existing web developers, who are comfortable with JavaScript or TypeScript, will start looking at the performance benefits of web assembly, and they’ll want to be part of it too.
  • 27:10 I know JavaScript is not terribly popular with some developers.
  • 27:15 I don’t see web assembly as being something that moves server-side developers to the web; I think of it as removing the monopoly JavaScript has.
  • 27:25 The web is the most ubiquitous platform that we have at the moment, and it’s quite bad that we only have one language that has first class support.
  • 27:30 I want to focus on breaking down the monopoly instead of comparing languages.

What will web look like five years from now?

  • 28:00 I think we’ll still be using the browser, because it’s a fantastic distribution mechanism.
  • 28:10 Ten years ago, people had desktop applications for their e-mail, but few use anything other than a browser now.
  • 28:20 The web and browsers aren’t going away.
  • 28:25 I do see JavaScript losing its monopoly, and I do see people writing significant applications using a wide variety of languages on the web.
  • 28:34 I think there’s a chance that web assembly will have an impact far beyond the web itself.
  • 28:45 If you look at web assembly, it’s a secure, safe, fast runtime that you can target with a wide range of languages.
  • 28:50 That’s a pretty useful in its own right.
  • 28:55 If we had a mobile device that supported web assembly, you’d have a vast number of developers who would be able to write applications and target them.
  • 29:00 We also know that on the desktop, the number of applications that are being written specifically for the desktop are diminishing over time.
  • 29:10 The Windows store is going to start listing progressive web apps, and the Windows store itself is moving towards a web distribution model.
  • 29:20 Add web assembly to the mix, and you can start distributing applications that do heavy lifting, like CAD applications or PhotoShop.
  • 29:30 It means that a certain class of application that we still struggle to distribute as a web application today will be possible.
  • 29:40 I see it not only having an impact on the web, but also on desktop and mobile as well.

What will happen to application frameworks?

  • 30:05 I don’t think web assembly will remove the need for JavaScript itself.
  • 30:10 Although web assembly is an efficient runtime, it doesn’t have things like direct access to the DOM API and I don’t think it ever will.
  • 30:20 Web assembly, although it’s got the name web in it, they have been quite careful to ensure that it will work well in other execution environments.
  • 30:30 There’s very little web about it.
  • 30:40 The future of a web application might be 70-80% web assembly, and the rest being JavaScript - the glue that marshals access to the DOM and CSS across its host bindings.
  • 31:00 For a native mobile application, you might have the same 70-80% web assembly, but a different host binding system for the mobile device.

To learn more about web assembly, Colin’s talk from QCon London is scheduled to be published on InfoQ at the start of June.

References

Photo by Chris Davis @specularworld / specular.viewbook.com/

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT