Web Assembly at the Edge
(static upbeat music) - Hello, welcome.
Welcome to WebAssembly at the Edge.
So before we get started, let's do our introductions. Who am I? Who? Aaron.
That's funny.
(laughing) My name is Aaron Turner.
I go by Torch2424 on the internet.
Feel free to DM me later and ask me why that is. And here are a few things about me.
We're gonna be getting into all of them later, but you know, just some introduction, what do I do. So I'm a member of the AssemblyScript team, which is a TypeScript like language that compiles to WebAssembly.
I'm the creator of WasmBoy, which is a Game Boy emulation library, written in AssemblyScript for WebAssembly.
and I'm the creator of "Wasm by Example", which has a bunch of byte sized, like very introduction, copy, pastable ,snippets for how you can do things and build applications using WebAssembly.
I also made, Made with WebAssembly, which is a showcase of project using WebAssembly. So if you have like kind of questions about where's WebAssembly that get fit and things? you can look on there.
And I also work at Fastly on their WebAssembly efforts. So what are we talking about today? One of the tools we'll be talking about is WebAssembly, also known as Wasm.
Wasm is relatively new.
It's a portable binary format that runs on the web, in both the browser and the server.
And we'll also talk about its relation to JavaScript a little bit.
We'll also be taking a quick look at WASI, which is a system interface for WebAssembly. Then we'll be talking about the Edge, specifically in terms of Edge computing, and how it differs from traditional distributed computing. Then we'll be combining the two.
Why and how WebAssembly and the Edge work together. And then we'll close things out with how WebAssembly is being brought to The Edge, through combined community efforts like Standards, to make a better WebAssembly for everyone.
So first, what is WebAssembly? This is a picture from Wasm Summit, which just happened a couple months ago.
And it was the first WebAssembly conference ever. Well, a couple of months as in, in February. So before things got wild.
Just so no one thinks, yeah, but cool.
WebAssembly is a universal low-level by code on the web. Because of this, WebAssembly is great for running logic heavy tasks compared to JavaScript, such as image manipulation, physics for games and heavy math computations.
But why is it great for this? WebAssembly offers predictable performance. JavaScript needs to be parsed, evaluated and then compiled many times, and this can get extremely fast or fall off this fast path, when you're running in a jet compiler on something like the browser.
Bi-code offers a more consistently predictable performance that won't fall off this fast path.
Because it gets just run straight through and it doesn't need to be recompiled over and over. One more thing is WebAssembly is extremely portable, and supported by all major browsers today.
I looked on, Can I Use, and it got 92.18% of users, which is awesome.
It runs a node.
So that way you can run the same image transformation on both the client and the server, if it compiles WebAssembly.
WebAssembly also have standalone runtime, such as Wasm time and Lucid.
and there's WASI, which can be implemented by these standalone run times, which is the WebAssembly system interface.
And it's also very bundle able, meaning that it's easy to package WebAssembly into like something like your NPM packages, and then share them around.
And there's a lot of languages outputting WebAssembly already.
The most mature three tool chains are AssemblyScript, which has that TypeScript like language to WebAssembly, I'm on the team for.
And what this means is that you can't just take your TS react app or your TF node app, and just compile it to WebAssembly.
This was due to WebAssembly being very young and it doesn't have direct access of DOM or anything like that quite yet.
But, if you can read TypeScript, you can pretty much read AssemblyScript.
They're like almost one-to-one.
And there's some really nice tooling.
So since it's essentially just a super/subset of TypeScript, a lot of your TypeScript tooling probably already works with AssemblyScript. And for maybe the small gaps that are there, we have tools like Aspect, which is a really popular testing library in the AssemblyScript community.
Then there's Rust which probably has, maybe some of the best tooling right now.
It's very mature and it has amazing like JS interrupted going.
And then there's also EnScript, which is a tool chain for C# and it's super mature. It kind of took its as in JS output, which was like super hyper optimised JavaScript. And now compiles that C# into WebAssembly, instead of as in JS.
So another thing about WebAssembly, no detail about it, is that it uses this thing called linear memory. Meaning that you kind of get a single heap. The way I like to think about it is just one big array, that you can just share between JavaScript and WebAssembly. And this makes it really easy to sandbox, from a security perspective.
And if you have multiple Wasm modules, they all get their own array or heat that they can write to. And they won't write over one another.
And yeah, again, this is really good for security. WebAssembly also relies on a capability based security system.
So what will happen is that your host, such as VA, JavaScript, will provide important function to WebAssembly.
So WebAssembly can call out to its host to do things on its behalf.
So for example, you mentioned earlier, WebAssembly doesn't have the DOM access, But if you wanted to write a JavaScript function that maybe draws to a Canvas, you can import that function to WebAssembly, to say, hey, call this function.
And then on your behalf, JavaScript will go and do what it needs to, and then return back to WebAssembly.
And this is really great because then WebAssembly only really has as much power as you give it. And you have to be really explicit about what you say can or can't do.
So now that we understand some of the WebAssembly fundamentals, what does the system interface for WASI? WebAssembly system interface or WASI is a standardised set of system calls for other operations. This allows for interacting with system resources, such as file systems randomness and time.
And why is this still really new? But things are on proposal for things like networking and accessing devices.
WASI can be implemented by standalone run times. Browser run times, like VA currently don't implement WASI, but there are these standalone run times I'd mentioned that do, such as Wasmtime on Lucid. So due to these, for example, you can go ahead and like start modifying files and things from your WASI module, if you run them inside Wasmtime and Lucid.
And again, because of these host calls,, you have to give explicit access to the run times. To say, "Hey, look, allow this WASI module to modify my file system.
And then I think you'd have to give it the exact directory it can modify.
And from that, you can get this capability model security, which is really great.
And the hope the runtime does these on WASI modules behalf. So yeah, you can see the picture coming together. And this is really amazing, because you can have really performed modules that are sandbox by linear memory and only have access to the resources that you give it. On top of a standardised set of system calls. So you kind of get all the benefits of WebAssembly, with controlled access to host or system calls, which is awesome.
So next let's talk about the Edge in particular Edge computing, the Edge represents putting your servers closer to your users.
Traditionally, you would have like a handful of servers or data centres, but light can only travel so fast.
So what are there across the country or on a different continent? The Edge is the idea of putting smaller servers closer to your users.
The smaller servers do smaller tasks, things like caching and where your largest servers can do your more heavy tasks.
such as like database quarries.
That way your users get a really fast experience all across the world.
There you go.
Fastly specialises in the idea of the Edge. They have Edge service called pops all across the globe. Fastly currently has 72 pops that are very strategically placed.
And these locations that are particularly chosen for the best possible speed, for wherever your location may be in the world. Fastly is probably most well known for its CDN or its content delivery network.
Primarily used for delivering static assets like images and videos.
The CDN also allows for being like special rules to be written in VCL, which is a DSL that Fastly uses.
So you can hyper optimise how things are cached at the Edge. So you often see distribute computing networks, offering storage at scale through these things like CDN, but it's also possible to do this with compute, often known as server less.
For example, like those one off functions, that can get run on the Edge, or maybe traditionally services has been done on someone else's origin servers.
But the space like I just mentioned has been recently moving towards the Edge.
So fast we started asking, how can we bring compute to the Edge? And we really wanted something really solid, that took full advantage of the existing faster network. So we started thinking about what are the things Fastly and it's customers want from Edge compute? So the first would probably be language portability. We have a lot of customers using different languages. We knew writing and implementation will be hard, but also we didn't want to exclude customers who didn't use like X, Y, or Z language. Security, definitely a really big one.
We're running essentially Untrusted code from our customers. And so a solution needs to go keep one customer safe from another.
Runtime performance, as the nature of the Edge. You wanna make sure things are really fast, and the solution needs to be able to run very quickly. And Memory usage.
We wanna conserve our resources, less resources usage puts less costs on us and our customers, and we don't want to use resources for things we're not necessarily using.
And lastly is cold starts.
Probably the largest complaint in the serverless space are cold starts.
You may be wondering what is a cold start, whenever a function or resource has to be fetched or re instantiated on an Edge server.
That's a cold start, because it's not already on that exact pop or note or whatever you wanna call it.
So it needs to be fetched and re instantiated and then run.
So this takes a bit of time, and can make that request so much slower.
And there's a lot of public work done by existing solutions. Like for example, I recently read a really nice paper from the Azure team on how to minimise cold starts. But we also really want to minimise them as well. And we don't want our customers to pay for pinging the server.
That way it keeps that function in memory as long as it can and having to be charged because they're wanting to keep it warm instead of cold. So now that we've defined what we really care about. Let's look at some of the options.
The first would probably be containers.
We could ask customers to containerize their code and that way we can easily place restrictions on things like memory, and CPU, and security, and things. And we would get great language portability and security from this because the container doesn't really care what language is running inside of it if you configure it correctly.
But this isn't too great.
Cold starts would be extremely slow trying to reboot an entire container over and over. And memory usage would be quite large as well because we'd be running both the customer application as well as a bunch of OS related stuff we may not be necessarily using.
Next one would probably be JavaScript.
This is another popular option we definitely considered, it's only a single language, but JavaScript probably has the widest net in terms of just a single language.
They can technically run WebAssembly too, but it requires JavaScript to use.
So then it's kind of like, if you want to do WebAssembly on this, you would have to run JavaScript first, and then run WebAssembly.
That being said, security would be pretty good with V8 isolate.
And memory usage would be pretty acceptable as well, because instead of running an entire operating system, essentially we're just running one runtime. but it's still quite not there.
Cold starts should be unfavourable.
So we'd have to re instantiate V8 every time, and V is really fast, but JavaScript's interpreted it, so the runtime could suffer.
And again, only JSB will be supported.
So not every developer would want to touch JS, if they aren't already familiar with it.
So here comes the punchline.
Let's dive into why WebAssembly is great for the Edge. So, we want that language portability, many languages compile of WASI like we mentioned, meaning almost any language that compiles of Wasm could be supported.
And all we need to really do is provide a very slim SDK for convenience, that our customers could use.
Next security.
WebAssembly like we mentioned has that linear memory, it's all sandbox and it's continuous heap.
So it can't access outside of it's sandbox which is perfect, and what we want.
WebAssembly has a capability based security model. So WebAssembly without capabilities can only really do basic logic, like addition and just moving memory around and stuff, and access linear memory.
We have explicit control on what that module can do, and things of that sort.
So it's great security in our use case of running entrusted code.
Cause we can explicitly grant what the WebAssembly module is allowed to do. And then runtime performance would be great for Wasm. So we gonna begin to benchmarks here.
Every use case and benchmark is very different, but in general, with a big grain of salt.
Wasm is about 30% slower than native.
And again, very much depending on the benchmark, but even then that's very minimum performance loss, and from just being able to take any code, and just compile it, and have it be portable and delivers benefits. And this is much better compared to other alternatives of trying to do something similar.
Memory usage is excellent.
Wasm modules can be extremely small.
For example, the AssemblyScript "hello world", I've been able to compile one that was only 55 bytes. So, loading that into memory 55 bytes not too bad, I'm also using one of those standalone Wasm run times, doesn't need like a large OS, primitive like a container would and doesn't ship an entire extra runtime.
Like if we took the VA approach, it doesn't ship also an entire JavaScript runtime. It's just focused on running only WebAssembly, so it really small.
And in those cold start times.
Cold start times can be drastically improved with WebAssembly.
There's much less bootstrapping than a container, or with a JS runtime.
We only have to make an instance of the stand alone Wasm run time, and immediately start executing WebAssembly, which is really exciting.
So these are all excellent technical reasons why WebAssembly is good for the Edge.
But I wanna take a quick step back and let's imagine a quick example where this all could come into play.
So what if we have like a large group of users? They have a lot of slow and old devices, but okay. Pretty decent internet speed, Like for example, low income users in bigger cities. Their phone is too slow to run an expensive operation for good user experience.
And this operation isn't really written in JS, So it can't run on the client and in the browser, And constantly having to pull the server for this operation is kind of unfavourable.
Again, their network speed is okay, but just having it in like a server, maybe across the continent, that's we're our data centre is.
It's just still not a good UX, if we try to throw it on the server to go back and forth across wherever they may be. So what we can do is, try something like WebAssembly. For your powerful devices, compile this code to WebAssembly and run it on the client. That way you don't have to make any network calls at all. It's all running right there.
You don't have to worry about it, doing anything across the networker being slow because we know the device is powerful enough to run it.
And now it can run in the browser because of WebAssembly. But for those less powerful devices, like we originally mentioned, those slow phone and stuff, compile this exact same code of WebAssembly, almost the exact same Wasm module, just a few WASI things here and there, and then you can run it on the Edge.
So there's no more hogging the CPU on these slower devices. And there's a lot less latency on the network costs, because now it's on the Edge.
One example I'd like to highlight here is, there's a mapping company called Esri, and they did a great example of this in which they took the client side version of their code, compiled to WebAssembly and they run it on desktop devices. But if they detect it's running kind of slow, they switch over and start using a server to do that processing for you.
They currently aren't using the Edge, because you know, we're still building the Edge solution to this, but I think it's a great use case and a great example of like it running in the world today. Now we took a bunch of look at technical reasons, and have real world example on top of that, and how we can probably use in a tech stack that you're probably already thinking.
Oh, yeah, I probably could do the same thing. Wasm seemed like a really good solution for this problem. So let's build WebAssembly and bring it to the Edge. Let's get started on it.
So WebAssembly is very new, and has a really long to do list.
Meaning there's still a lot of work that needs to be done. And a lot of things that are maybe second nature, are still missing.
But just simply because it hasn't been built yet. But I wanna say thankfully there is an amazing community of people just driving this, and really putting in a lot of work, just to see where it can go.
There's many organisations and individuals that see the value of WebAssembly, including Fastly. And are investing resources to make it awesome. And when I say amazing, I mean like amazingly smart, but also amazingly nice and welcoming people to be around, and to be a part of this community.
I personally experienced that every day and I'm so glad about it.
So first thing I'd like to highlight is the WebAssembly system interface specification. The WASI spec is led by Dan Goleman.
It's a repo containing all the information on the spec like I'm showing here.
And this is where pull requests are made to make new proposals and changes to the specifications going forward.
And Wasm has been growing steadily, accomplishing all kinds of cool things, witx is championed by a colleague of mine, Pat Hickey, it's a language for defining these interfaces. WebAssembly system interface, it's nice to have an interface language that says, this is what it's gonna look like when you pass this or when you call this function, and here's where the planners need to be, and things like that.
And WASI has a snapshot process for versioning, which is really nice that way you can kind of pick and choose which version of WASI you wanna use. You usually wanna use the latest, it's nice it's there.
And there's lots of cool proposals in the pipeline. For example, I recently was in Wasm meeting, in which someone proposed a machine learning Wasm interface. Which I thought was like, Oh wow, that's really cool.
I never would've thought of that, but I could definitely see the usefulness in it. And another proposal I want to highlight currently for Wasm is the crypto proposal.
Frank Dennis is a colleague of mine and they are championing this and it will be super useful. I have a lot of friends in the WebAssembly community that are also in the blockchain space.
And one of the first things they asked me about or come across is a need for a crypto.
So having a standardised way to do this will be really cool and excellent for everyone.
Next we can cover some of those standalone run times I'd mentioned.
Wasm time is a popular choice for a general Wasm runtime. It was started by Mozilla and it's really focused on being lightweight and fast. It uses crane lift to generate machine code at runtime while it's running the WebAssembly module.
And it also falls the Wasm on WASI spec extremely closely, which is really nice.
Lucid is another standalone run time.
Lucid is built by Fastly, and we're gonna use for Edge computing.
Lucid is most notable for having an ahead of time compiler, rather than doing it at runtime.
And lucid, I will admit it is more, if you need a special use case of needing an ahead of time compiler.
Wasm time is generally what we recommend for general Wasm standalone, runtime usage. Something I'd like to highlight here as a performance of lucid.
Adam Foster, is a colleague of mine, and they ran some benchmarks on Lucid, and its performance...
They wrote a blog about it.
The most impressive thing from this benchmark was, the benchmark showed that Lucid could instantiate at Wasm just as an example and about 52 microseconds.
And yes, I said, microseconds, not milliseconds. So cold starts like we were mentioning earlier, could be very, very minimal if they're set up right, exactly what we were shooting for, so that's really exciting to see.
Next I wanna highlight some of the languages that can compile a WebAssembly.
Rust has been a really strong tool chain in the Wasm space like we mentioned before. And Rust is continuing to see investment from multiple companies out putting WebAssembly. For example, Rust has really good wise support and Rust is continuing to see create some projects that support WebAssembly out of the box, which is really exciting.
Putting on my AssemblyScript team member hat. AssemblyScript is a language I am on the team of, and we've been seeing a lot of really interesting and thankfully new investments from Fastly and Shopify. The language is still very young, but we've continued to improve our UX.
We now have a really good JavaScript WebAssembly interrupt story now. Closures are getting really close things to efforts by people like Duncan and the Islamic script community. And they, and I have been working on together really closely on it.
And Rejects is probably our last big hurdle, But we've been having bi-weekly meetings as a community and they've been going really great.
And I highly recommend you all check it out. And if this sounds interesting to you or your organisation, maybe check out the working group that AssemblyScript rebuild.
Next putting on back on my Fastly hat, I've been working on helping languages and our ecosystems in general.
So like I mentioned the AssemblyScript is something Fastly has been evaluating and experimenting with. My status as a team member there definitely helps join a tonne now that I'm working at Fastly, as well as exploring languages like Go.
It's still very young in it's Wasm days, but something we're exploring.
And also we've been playing with languages, that don't even compile with WebAssembly.
I kinda mentioned earlier, kind of needs to come out of WebAssembly if it's gonna run on that runtime and stuff. But if the language itself doesn't compile WebAssembly, maybe its runtime could.
So one example we did is we compiled quick JS, which is a JavaScript runtime and we compile it up to WebAssembly and then we're doing experiments there, running JavaScript and a WebAssembly compiled JavaScript runtime. And then most importantly, I'd like to highlight the communities that are really driving WebAssembly.
There's a lot more to code, when building software for the web.
And I think community is probably the most important part of it.
So first I'd like to highlight the Bytecode Alliance. It's a group of companies that are invested in Wasm and WASI.
For example, some of these companies are Mozilla, Fastly, Intel, Red Hat and others. They're all working together, to help bring the shared vision, of a secure by default Wasm and WASI, which will greatly help in running, things like Untrusted code.
Next I'd like to highlight WebAssembly San Francisco. It's run by a close friend of mine, Jonathan Berry, and it's a monthly meetup in San Francisco. It's currently on hold due to current events, but it's a great place to stay on top of cool things happening with WebAssembly.
And I've made a tonne of personal friends, that I talk to once a month like, Hey, how are you doing? And great projects are always highlighted there. And per the current events.
One thing that I think that's nice to highlight too, is that all the talks are recorded.
So there's a YouTube channel, which I think is a huge wealth of knowledge. If you're trying to learn more about WebAssembly or you find this talk interesting, you wanna learn more, I definitely need to talk to your format that you enjoy it. I highly recommend going to their YouTube channel and checking out some of the videos.
Next is the Wasm summit.
Like I mentioned, it was the world's first, WebAssembly conference.
And it happened in February of 2019.
It was organised by more notable friends of mine. Myself and more notable friends, such as Surma, Ashley Williams, and the list of organisers is pretty large. And I don't want to list everyone, every single one, but just know, that's an awesome team of people, that I really enjoyed working with.
Wasm Summit was a blast.
And again, all the talks here were recorded. There are some really amazing talks by a lot of the most notable people in WebAssembly right now, in teams driving, WebAssembly to be the best that it can be. And again, if you're interested in getting started with WebAssembly, this is another great resource.
And side note, I just wanna say, this is the first time the whole WebAssembly community got to meet.
It was super memorable for me.
And again, I had a blast at the event they're looking forward to future ones.
And there are so many other cool projects and spaces for WebAssembly to exist.
I wanna highlight a few of them.
Wasm3 is probably the most notable runtime for IOT, so internet of things.
It's an interpreter, but it's meant to be super small and it does a really fast interpretation of WebAssembly. Jonathan from Wasm SF, has a great talk at Wasm summit, that I just mentioned about IOT and WebAssembly and how the two mesh together.
And the future going on there.
WebAssembly in the browser is also getting a lot better, such as the threads proposal or landing.
So now you can have separate threads of WebAssembly running at the same time, and I also see new projects popping up every day across the web that are using WebAssembly now. And I think there's also huge, like lot of traction going for game development for WebAssembly.
I see a lot of game engines that are adopting WebAssembly back ends like And being on the AssemblyScript team.
I see a lot of smaller, just specifically web game engines, starting to implement WebAssembly here and there' for a certain physics call or things like that. And it's really exciting to see, cause then you kind of get the benefits WebAssembly without even knowing that it's using WebAssembly, which is awesome.
And together, I think really one point I wanna get across is that, the tech behind WebAssembly is why I got into it. But the reason why I keep working on it every day and I love working in it is because the community is just an awesome group of people to work with.
So if your organisation has ideas around WebAssembly, you can be a part of the community to.
For example, as an AssemblyScript member, it's really a grassroots effort.
I didn't meet with Shopify and learned their use case, until we met at Wasm Summit for the first time. And since then they've been an amazing help to the project. They quickly got some PRs in, to fix some of the bugs they had for their SDK implementation they're working on. But like I mentioned before, Dunkin, that's currently the person that's working closely with AssemblyScript right now from Shopify. And I have been working very closely on getting closures in. Which is a huge feature for the project.
And it's just been awesome to see how we've all been able to work together and everything's going great honestly, which I think is great, cause now we're building a better WebAssembly for everyone really.
And with that let's just start wrapping things up. So here are my main points.
Normally this is where I would say, take a picture of the slides, but current events. So take a screenshot if you're into that.
Wasm is super exciting, it's super cool tech.
locked doors open for the web I think.
Both in the browser and just in general building things that use the internet.
I think it's really exciting, but I also think the Edge is an exciting space for compute. It can solve many different problems and Drastically improve UX, which I'm really passionate about.
And WebAssembly can be a key part of that implementation. And also I wanna say, the WebAssembly community is amazing. I'm so glad I get to be a part of it.
There's lot of amazing people, making WebAssembly awesome, for all types of different applications and use cases. And with that, I wanna give you my thank you. So I just wanna give some special thanks to my team at Fastly, Katie, Adam, Pat, Tanya, Andy, Tyler. Aaron, not me Aaron, we have another Aaron. So you can imagine how confusing that gets during meetings, but I'm really happy I get to work with these people every day.
And they reviewed my slides and really helped me out here, so I appreciate that.
But also wanna give a huge thank you, to the conference organisers, and thank you very much for your time and attention. Please feel free to reach out to me over Twitter. My handle is on the screen.
I love to continue these discussions and thank you very much.
Enjoy the conference.
(upbeat music)
In short order, Web Assembly has gone from an experimental project, to a fully fledged, high performance compilation target and runtime in today’s browsers, allowing many of the most widely used programminglnguages to natively target the Web platform.
In this presentation Aaron Turner brings us up to speed with what’s now, and next, for Web Assembly.
Web Assembly at the Edge
Aaron Turner, Software Engineer Fastly
Aaron has made or is involved in lots of cool projects around WASM (WebAssembly) and WASI (Web Assembly System Interface). He’ll be talking about WASM, WASI and the Edge.
So what is WASM? It’s a universal, low-level bytecode for the web. It’s great for computationally-heavy stuff that doesn’t fare well in JavaScript. It runs in major browsers, nodejs and in standalone runtimes.
There are lots of languages outputting to WASM, but the most mature are:
- AS – AssemblyScript (if you can read Typescript you’ll be able to read AssemblyScript)
- Rust has good tooling for WASM
- emscripten – a very mature toolchain for C that now compiles to WASM
WASM uses linear memory – it’s like one big array you can share between WASM and JS. This makes it easy to partition – great for security. It also relies on a capability-based security system, which provides some further control.
WASI is a system interface for WebAssembly, a standardised set of system calls for interacting with system resources like file systems, randomness and time. There are proposals for more.
You can use WASI through standalone runtimes like Wasmtime and Lucet. There are tight requirements around the permission you give WASM modules to do things like modify files on your system, you have to be very specific.
This gives performant modules with really powerful capabilities.
The Edge represents putting your servers closer to your users – eg. with Fastly’s edge cloud platform. The idea is to serve from locations that are optimised to deliver content to users, wherever they are. CDNs are the best known face of this.
You can also use this model for compute – commonly called “serverless”, where it’s the compute that closer to the users, not just storage and transfer.
To make this useful Fastly considered what users consider important for compute: language portability, security, runtime performance, memory usage, fast start/minimal cold starts. A cold start is where a user’s request has to wait while code is transferred to their nearest node, parsed and served.
So what are the options? We could ask people containerise their code. It would give good portability and security, but cold starts would be really slow and resource consumption high.
You could also put JavaScript at the edge – V8 can run WASM but requires JS so there are multiple execution layers. Cold starts still wouldn’t be great and as an interpreted language execution could suffer.
But WASM is great for the edge:
- portability is high – almost any language that compiles to WASM could be supported with a slim SDK
- security is great – sandboxed, continuous heap, capability based security
- runtime performance is generally good (there are always caveats with performance)
- memory usage is reasonable
- cold start times are much quicker with WASM than with containers or JS
So those are great technical reasons, but let’s look at this another way. Imagine an example where you have a large group of users with cheap, low-powered devices; and reasonable but not great internet speeds: for example lower-income earners in a big city.
WASM is kind to profiles like this – it takes less CPU and latency is reduced by edge hosting; so those devices can still use powerful features.
WASM is really new with lots of work still to be done. Things that are second nature are still missing, simply because they’re not done yet. But it has an amazing community driving it, people who are not just smart but see the good it can achieve. WASI is also growing with a lot of cool innovation – eg. ideas coming forward for machine learning and cryptography interfaces
Standalone runtimes:
- Wasmtime is a popular choice for a general standalone runtime for WebAssembly. It’s designed to be light and fast.
- Lucet is built by Fastly and it’s what they’re using for their edge solution. It notable for having an ahead-of-time compiler rather than runtime. Lucet is fast for instantiation – as little as 50 microseconds (not milli, micro!), which is very good news for cold starts.
Languages that compile to WebAssembly:
- Rust has been a strong contender in the WASM space for a long time. Good WASI support; enthusiastic community.
- AssemblyScript is a very young language, but has some big backers; and has a good JS/WASM story; there is a lot of opportunity to get involved if you are interested.
- Fastly have been experimenting with Go for WASM
Even if a language doesn’t compile to WASM… maybe its runtime will…!
Communities:
- Bytecode Alliance is a group of companies investing and working together on WASM
- WebAssembly SF is not just a great meetup for SF locals, most WebAssembly SF talks are on youtube
- Wasm Summit also put all the WebAssembly Summit 2020 talks online
There are lots of really exciting projects too:
- Wasm3 runtime (small, good for IoT)
- Wasm itself is also getting better
- Lots of new projects around games – game engines, physics engines, etc
The tech is cool, but the reason Aaron stays so interested is the community is great to be part of. If you (and your company!) are interested you should get involved.
Together we can build an awesome WebAssembly for the browser, edge and beyond!