Ashley Williams on Web Assembly, Wasi, & the Application Edge

Show Notes

What is WASM?

• 03:00 It’s a bit of misnomer to call it web assembly, because it’s neither.
• 03:05 It’s a set of instructions, a low-level bytecode target, which means you can write web assembly from scratch but you probably don’t want to.
• 03:15 It has been added to the browser because it fills a missing need that we’ve had for a while.
• 03:25 JavaScript is awesome, but it was invented to create little interactions for a website - but now we’re using JavaScript to write full fledged applications.
• 03:40 JavaScript was never designed to do that, or write highly performant applications.
• 03:50 Because the web is open, so this new lower-level area of computation in the browser allows us to open this to types of applications that were previously excluded, like games.
• 04:05 Google has a great demo where they have compiled AutoCad to web assembly and then run it in a browser.

What’s the secret sauce?

• 04:30 There aren’t that many people using web assembly right now - I’m looking to the future and trying to find out what the use cases might be.
• 04:40 Just because you mentioned threading: web assembly doesn’t currently have threads, but it’s something that we’re working on.
• 04:45 Web assembly was born in 2017, which isn’t that long ago - so it’s still fairly new.
• 04:55 What’s in the browser at the moment is just a start.
• 05:00 It’s growing, like all web technologies do.
• 05:10 The growth is going to come from two lines.
• 05:15 The first is the idea of performance - a lower level bytecode, so it’s smaller (and therefore faster) to download.
• 05:30 Talking about whether it is more performant is a little complicated.
• 05:35 For tasks that it is well suited to, it’s incredibly performant - but it’s not suited for every task.
• 05:40 A lot of that comes with how much you have to go back and forth with JavaScript.

What does web assembly perform really well?

• 05:50 Web assembly is very suitable for number crunching tasks.
• 05:55 For example, rotating an image, perform tensorflow calculations - high processing tasks, where you can pass a set of data into web assembly, process it, then hand it back.
• 06:15 If you have an application where you’re constantly sending stuff back and forwards to web assembly - we call this a trampoline - can be really non performant.
• 06:25 In all types of programming, crossing boundaries has some kind of cost, so you want to avoid doing that frequently.
• 06:45 All of these performance aspects are going to improve and get better.
• 06:50 One thing I do want to mention: if you have wanted to get performant JavaScript, you may share this sentiment that the garbage collector is your worst enemy.
• 07:10 This isn’t to denigrate JavaScript in any way, or garbage collection - there are aways trade offs in any language.
• 07:20 Web assembly doesn’t have that, and as a result, the performance improvements will be consistent and predictable.
• 07:30 It is significantly easier to predict web assembly performance than JavaScript because of those differences.

What other great web assembly demos are there, as well as the AutoCAD example?

• 08:05 It’s great you brought it up, because as I was saying there are these two types of examples: speeding up the hot parts of JavaScript, or to not use JavaScript.
• 08:20 You can write something else, because web assembly is a compilation target, if you can get your language compiling to target web assembly then you can write the program in your preferred language.
• 08:40 There’s a group of web assembly users who are hoping that this will kill JavaScript, but I’m not part of that group.
• 08:50 There are package ecosystems in C/C++, Rust that have awesome utilities - you may be familiar with how npm works and has native dependencies.
• 09:10 Those native dependencies haven’t been available to those who want to run in the browser - until web assembly came along.
• 09:20 If you have some C/C++ (like Unity) and want to run it in the browser, you can do so with compiling into web assembly.
• 09:45 Instead of needing to get rid of JavaScript, it’s a widening of the available languages.

What does bootstrapping a web assembly program look like, maybe with Rust?

• 10:00 We have built out a number of tools to help with this.
• 10:10 You can download a template, build a program and then export a specific function with an attribute to indicate it can be executed from JavaScript.
• 10:30 You then run a tool called wasm-pack, which will compile the Rust into web assembly, then run wasm-bindgen which generates bindings.
• 11:05 The reason you have to do this is because web assembly understands very few types.
• 11:40 You want to be able to talk to your web assembly in the way that JavaScript wants to talk, with objects, classes and arrays.
• 11:50 The wasm-bindgen will generate JavaScript boilerplate that is going to wrap that for you.
• 11:55 We generate the web assembly, the JavaScript boilerplate, and stub functions to instantiate the web assembly.
• 12:10 How web assembly is loaded into the browser at the moment can be a tripping point for some folks.
• 12:20 Then it’s almost as if you’re using an npm package, you can talk to as if it were written in JavaScript.
• 12:30 At the end of the day, it’s a low level technology and it will be successful when everyone is using it and no-one knows.

I remember downloading the toolchain and giving it a go after the Google demo. —

• 12:55 I believe that the toolchain was emscripten, which was the proof-of-concept that confirmed web assembly had arrived.
• 13:10 It used to produce asm.js, which has some interesting performance hacks in it.

What was asm.js?

• 13:35 It was a subset of JavaScript that could be super-optimised.
• 13:50 It wasn’t a bytecode, it was just JavaScript that could be optimised in the browser in a particular way.

The next step was to get to web assembly?

• 14:15 We see people doing this in JavaScript - there was discussions on when you need web assembly or not.
• 14:30 For example, the sourcemap implementation for FireFox was re-written in Rust and compiled with web assembly, and saw a 10x speedup [https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/]
• 15:15 V8 has a lot of optimisations that kick in for JavaScript already, and there’s a lot of good work done there.
• 15:25 However, the JavaScript that you have to write in order to get best performance is pretty hard to decipher, which is a concern from a maintenance perspective.
• 15:35 Nick Fitzgerald wrote “Speed without Wizardy” [http://fitzgeraldnick.com/2018/02/26/speed-without-wizardry.html] which showed you could just write idiomatic Rust and it compiles to performant web assembly.

What does CloudFlare do (apart from a CDN) and what are edge workers?

• 17:00 I’m new, but I do know that CloudFlare aren’t just a CDN company, although they do have one.
• 17:20 Fundamentally, CloudFlare is a hardware company, that has servers all over the world.
• 17:30 For the CDN aspect, they can cache content and serve it locally to you by shrinking latency.
• 17:35 It turns out that the Internet is a physical thing, and sending information from New York City to Australia does actually take time.
• 17:45 You can make latency improvements by sending information from Australia to Australia instead.
• 18:00 CloudFlare also offers everything you would have found in a hardware box, but given to you as a service.
• 18:05 We’ve got DDoS protection at the edge, instead of letting it go through to the origins.
• 18:35 Because we’ve got such a good network - about 10% of the internet go through CloudFlare - we can be smart about what kind of traffic ends up hitting you.
• 18:50 We’re well positioned to take care of that.

What are CloudFlare workers?

• 19:00 Naming is a hard problem: workers are an overloaded term.
• 19:20 Fundamentally we’ve been writing code on the server or on the browser.
• 19:40 Workers move that to allow code run somewhere else; not on the server or browser.
• 19:50 You write JavaScript, like you would do for a browser, except that you can run it on a server - except that can be distributed to 180 places globally.
• 20:10 The workers product is a serverless architecture; the difference being that your application is distributed across the world.
• 20:40 The architecture for workers is a “V8 isolate” — what’s in Chrome and Node - and we’re able to run multiple programs.
• 20:55 This allows you to write JavaScript and web assembly for free.

How are programs isolated?

• 21:20 Everything is living in its own process.
• 21:30 Spectre is a fun issue here.
• 21:40 You have been using this security model on the internet for an incredibly long time.
• 21:45 In the same way that you might visit a website on the internet, it’s similar to what you’re doing here.
• 22:00 Your browser is loading all sorts of JavaScript (unless you have JavaScript turned off, which most people don’t).
• 22:05 It’s keeping those things sandboxed so things aren’t leaking.
• 22:15 On top of that we have turned off several parts of V8: there’s no concurrency, there’s no timers - which helps to mitigate Spectre.
• 22:30 In picking a runtime, V8 feels like a good choice, because it’s not going anywhere, and there’s a great security programme for V8 which has great bug bounties.
• 22:50 We also have our own security teams doing fuzzing and pen-testing on top of that.
• 22:55 It’s a technology that’s being used and we anticipate it being maintained into the future.
• 23:05 Researchers are actively interested in working on this because of the number of people using it.

What are you seeing people implement use cases with CloudFlare workers?

• 23:25 One of the most positive use cases of CloudFlare workers was to configure their CDN.
• 23:35 With JavaScript being the most popular programming language in the world, hiring a JavaScript programmer is fairly easy.
• 24:00 We’ve seen a set of companies that are doing A/B testing, and they want to redirect users to different places based on some property.
• 24:20 The problem is that JavaScript completely blocks rendering until it knows what site to render.
• 24:30 If you’re doing user experience testing, and the user stares at a blank page for a long time, you might be biasing the results.
• 24:40 Workers can be a cache for computation, but keeping the result close to where the users are going to ask for it.
• 24:50 That means you can make the decision of where to go really quickly and eliminating the latency reduces the blocking time on the browser.

So are we able to run wasm workloads at the edge?

• 25:35 You can run web assembly on CloudFlare workers today already.
• 25:45 The developer experience is not there yet; web assembly is still really new.
• 25:50 I just released a tool for building out web assembly workers called wrangler.

What does that look like?

• 26:35 Right now, a worker looks like a JavaScript function, but workers can have resources and us npm packages.
• 26:50 In your worker, you can instantiate that web assembly, and then for all the request handlers you can leverage that web assembly.
• 27:05 I made a demo for wrangler where you can post a markdown formatted string, and it is converted to HTML on the server.
• 27:20 This can be handed off to the web assembly function, and the work processed there.
• 27:30 Right now, like many serverless platforms, we’re focussed on that single request handler which is mapped to a route.
• 27:45 In the future, we could write a full application on the edge, but you have to deploy it as multiple functions at the moment.
• 27:55 You shouldn’t have to do that - you should be able to take something that you can put it on to Heroku and be able to hand that to the edge instead.
• 28:20 When we get to that future, there’s a spot for running pure web assembly on the edge without needing that JavaScript route handler.

What is wasi?

• 28:50 Wasi is the Web Assembly System Interface, is a standard interface for running web assembly outside of the browser.
• 29:10 I’ve been working in web assembly saying I’m looking forward to web assembly OS - and this is a step in that direction.
• 29:30 This will allow web assembly to talk to what is below it.
• 29:35 Most people writing web assembly assuming it’s going to be run in a browser.
• 29:45 If you’re running web assembly outside of a browser, you can’t make assumptions of what it could be.
• 29:55 Wasi establishes the interface so that if you wanted to reach below, to access the file system for example, then you can go about doing it.

What do you see as a use case for wasi?

• 30:20 One of the biggest things that happened after wasi was announced was Fastly launched a new runtime for their edge called Lucet [https://github.com/fastly/lucet/]/
• 30:30 That’s a pure web assembly runtime, built on top of wasi, which means that it has some of the system level implementations that you’d want.
• 30:50 I don’t know if Lucet has implemented filesystems, sockets, udp - the lower level protocols that you might want to do that rather than via a web API.
• 31:25 In a universe where there is a web assembly runtime, web assembly is just a binary - you run it like you run any other executable.
• 31:40 I’m excited about wasi is being able to deal with traffic that isn’t HTTP traffic.
• 31:55 With V8 we get JavaScript and web assembly out of the box, and we like that JavaScript part.
• 32:00 I’ll sell you on Rust and web assembly, but JavaScript’s a really useful language.
• 32:05 It’s maintainable and open to developers, and using it can take advantage of web assembly.
• 32:20 There is a future where web assembly will be the most performant choice for nearly every application - but that future isn’t here yet.
• 32:30 Whether or not there is a performance benefit just writing it in web assembly is yet to be seen - there’s a lot of tasks that need to be completed.
• 32:45 On the other hand, if you just want to change configuration on your CDN, then updating a simple JavaScript file is really easy and doesn’t need a multi-step compilation process.
• 33:00 There’s also a lot of really great developer tools for JavaScript, and I’m trying to replicate those tools for web assembly.
• 33:20 Web assembly is for the early adopters right now.
• 33:50 Zoom has a web client that is written in web assembly, with an emscripten toolchain.

What are some of the gotchas of web assembly?

• 34:30 Web assembly only understands four types of numbers: 32-bit and 64-bit integers, as well as 32-bit float and 64-bit float.
• 34:45 There are some arguments for growing the type system of web assembly, but do you want to solve it in the product or the tools?
• 35:05 I think maybe we don’t change the web assembly knowledge of types, but we build good tooling around it.
• 35:30 We’re already using compilers; we’re using two of them, in fact.
• 35:35 The first one says “Here’s my code, turn it into web assembly” and the second one says “now I’m going to generate JavaScript wrappers for you”.
• 36:00 If you want to learn a bit more about Rust, web assembly and JavaScript, take a look at those bindings.

Where are we today with wasm and wasi?

• 36:40 They’re all tied to the question of what kind of ideas we want to solve with web assembly, and where we want to solve them.
• 36:50 Wasi is about taking web assembly out of the web and start interacting with other services.
• 37:00 Meanwhile, web assembly in the web needs some further build-out to solve the problems we want to be able to.
• 37:15 I would be remiss if I didn’t recommend a post by Lin Clark [https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/] for what wasm needs to learn over the next couple of years.
• 37:55 When we talk about what wasm needs to know about where it is running, people familiar with what’s going on will know there is a web assembly host bindings proposal.
• 38:20 The host bindings proposal relies on support from JavaScript and web APIs to be useful on the web; DOM access, for example.
• 38:50 The goal is to allow web assembly functions to create and manipulate JavaScript and DOM objects, and all of those host calls should be well optimised.
• 39:10 One of the ways we did it in the rust-wasm toolchain was to use web IDL - I believe that the host bindings proposal has changed to use something like web IDL.
• 39:40 Think of it as wasi, but for the browser.

Do you have a big announcement at JSConf.eu?

• 40:00 Early June I’ll be travelling out to Berlin, and I’ll have some exciting things to share then about the edge and how it’s going to change the internet.