DEV Community

Serverless Chats

Episode #93: WebAssembly and WASI with Aaron Turner

About Aaron Turner

Aaron Turner is a senior engineer at Fastly. They were previously doing rad stuff at Google and various startups and agencies. In their spare time, they are hacking on various WebAssembly projects on the web, cooking up some dope beats, and shredding local skateparks.

Links related to the content in the episode:
Watch this episode on YouTube: https://youtu.be/Ef1iE9KaAd8

This episode sponsored by New Relic and Epsagon.

Transcript
Jeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm joined by Aaron Turner, hey Aaron, thanks for joining me.

Aaron: Yeah. Thanks for having me. I'm really excited to be here.

Jeremy: Awesome. So you are a Senior Software Engineer at Fastly. So I'd love it if you could tell the listeners a little bit about yourself and your background and what you do at Fastly?

Aaron: Yeah, totally. So what is it about me? So what I do is I work a lot of WebAssembly. We've been doing that for about two and a half years. I started getting really involved in the community and through that work, I was going through a lot of meetups and things, and I ran into Tyler who was the CTO Fastly and they were working on this new edge WebAssembly thing. And just the timing lined up and our interests and both were passionate about the moment it did. So I joined the company and it's been going great so far. And there, what I'm working on is a lot of WebAssembly work, both in terms of bringing on new languages to the platform, but also it's a lot of community work, participating in a lot of events, still doing podcasts and things and just hanging out with people and having a good time.

Jeremy: Awesome. So actually I had Tyler on the show not that long ago. And we talk mostly about computed edge, but we got into WebAssembly a little bit and I'm finding this whole thing fascinating. Because I remember way back in the day Java applets and of course Flash if anybody remembers that, I think that's still around. But this idea of trying to bring compute and more complex applications in a bytecode form, bring those to the browser. And this a really interesting thing, I don't think it worked out really well in the end, but it seems like WebAssembly is a better shot at doing that. And I find that really, really interesting. So I'd love to just pick your brain for a little while here and talk about WebAssembly, but I think maybe for the benefit of the audience why don't we start with what exactly WebAssembly is?

Aaron: Yeah, totally. So WebAssembly I like to describe it or really what it is is bytecode for the web like you were alluding to. And what that means it has a few implications. Two of my personal favorites are predictable performance. So when you look at something like JavaScript it's an interpreted language, but we got really good at running it really fast. So we built a just-in-time compilers. So what that's going to do is go ahead and read your JavaScript and compile it over and over many times. It makes some assumptions about what your code is doing, which can get really, really fast if it assumes the right things. But if it makes the wrong assumptions they can get really slow. Whereas if you're running a bytecode it's always predictably performing. So a really bad analogy people tell me not to say, but I like to think of it as like, if you're driving on the freeway, it's like your WebAssembly. Taking their freeway depending on what you're trying to do most of the time it's going to be faster.

There might be sometimes you're taking the streets driving around, doing the neighborhood might be a little faster, but nine times out of 10, if it's far away in a few miles, we'll just use the freeway. You know what I'm saying? That sort of thing. So that's what I like to describe the predictable performance. At least that's how it works in my head. And when kids ask me or my little brother is like, what are you doing? I'm like, that's it. And then another thing about is that it's very portable. So as the nature of the web it's great for distributing logic wherever it may be. So both portable in terms of, it runs in all major browsers which is a huge solid, because you start shipping in. It's very bondable so if you wanted to throw WebAssembly into an MPM package, for example, and use it there that can run in the background and do some of that predictable performance for you in your JavaScript ecosystem.

It's also very language-agnostic. So if I guess parent language compiles down to WebAssembly the actual bytecode then you can use any language essentially and have an interface with this JavaScript WebAssembly API. And I'll get into it's very portable and the fact that multiple runtimes support it. So for example, Nodewell it has its own adapters there, but also people have built their own runtimes for WebAssembly itself like WASMtime which has extended long run time and as well what Fastly built, which is called Lucet. And it's an ahead of time compiled WebAssembly runtime type thing, but yeah, that's probably how I would describe it best.

Jeremy: All right. So there's a lot to unpack there. And so what we can do is we'll go through some of those things. But just in terms of like, I think this is where we look at things that run in the browser. And I know we'll get into this, that you can run a WebAssembly in more places than just the browser. But running in the browser one of the things that I think we think a lot about is security, what does it have access to? Can it do network calls? Can it access local resources, things like that? What are the capabilities of WebAssembly?

Aaron: Yeah. Thank you very much for asking that, because it's always like, I'm always performance, portability. Awesome. Then it's like, oh yeah, there's also these other great things. So yeah, total insecurity. The one thing that's really nice about WebAssembly is that it has this concept of linear memory. So the idea really is that you are given a heap or just the way I like to think of it from a JavaScript background, self-taught here is, just this one really big array and you can't go out of the array and you can't go before the array. And that's all you can access and it's sandbox. So because of that, you can't escalate out of that memory and do things with the host. So WebAssembly has a really nice feature in which this linear memory of sandbox. So you can't really escalate out of it just because WebAssembly don't allow that. And on the topic of capabilities one thing that's nice about WebAssembly as well as this concept of host calls.

So essentially you can say, hey but we talked about the host here. It can be JavaScript like you mentioned, or one of those standalone runtimes. You're like, hey, host I know you have access to this function let's say, if I call this, I want you to go do this on my behalf. So for example, a common one in WebAssembly that people often use is like, let's say you want to use console.log, for example, you can go ahead and import and say, hey, look, I want to import console.log. And when I call it, I'm going to pass it this value and then JavaScript can then say, oh, hey, you called this function that I gave you access to, this host call that I provided. Cool, I'll go do some work for you.

In this case, log out a number let's say, and then let you continue executing. So this opens up all types of cool use cases of depending on what the host wants to provide, you can start doing some really cool things and have this security where the user can give you some code that you don't really know what it's doing, but only has as much power as you will let it have a doing those calls really. And that, since that memory is sandboxed they can't work out of there either. So starts to build this very secure. You can start trusting code that people are giving us because of these two features, which is really exciting.

Jeremy: Yes. So you mentioned use cases and I think use cases are probably the best way to communicate to people what the capabilities are, right? So great performance, linear memory, sandbox, security, that all sounds awesome. But if you can't explain what you can do with it, right, it's hard sometimes to visualize. So you mentioned this idea of calling JavaScript or being able to do those host calls and stuff, but what are some of the practical use cases that you would use it for? And maybe even more importantly, what's the use case and then why is WebAssembly better for it?

Aaron: Yeah, totally. So WebAssembly started off as something that's for browser, it's starting to evolve more into serverless use cases and things, but just taking a step backward started the major use case here was speeding up JavaScript in the browser. So JavaScript was in this interesting place where it had this unwilling monopoly, I will say, on the browser, where you had to use JavaScript. So because of that lots of different companies at different interests in it and started pulling in different ways that it really wasn't ever designed for it. So WebAssembly was like hey, look, that whole performance thing we're trying to a JavaScript yeah, it's good for that. But let's take a little bit of a weight off of JavaScript and give something else. So I bring all this up to say that speeding up JavaScript really. So if you have let's say a loop that maybe it's doing image blurring, for example, that isn't supported by the browser natively. I don't know if there was a CSS thing proposed, but let's pretend there isn't but it'll be, go ahead.

Jeremy: Even if there was, it's not going to work the same way in all browsers I'm sure, so ...

Aaron: Yeah. So that's really computationally intensive. You're going to be looping around trying to figure out what pixels need to be duplicated, which ones don't, and WebAssembly is really good at those tasks because of that whole predictable performance thing. So what you would do is take that block of JavaScript and instead replace it with a WebAssembly module that you then pass and say, hey, look, here's the pixels that I want you to go ahead transform, turn back in your linear memory, what the new images, and I'll go ahead and display that. And having access to that predictable performance then lets you do those things on the browser a lot easier, and they're not so taxing. You can also imagine this same computationally intensive speeding up JavaScript is great for game engines. I've seen a few game engines already take some of their physics engines and start replacing pieces with WebAssembly modules, because it's just built and designed for doing these computationally intensive math operations and things that game engines really need.

And then another one is probably just general business logic. So there's all types of different times where we're just like, hey, we got this data structure and we just going to make it look like this now for the server. So sometimes JavaScript's good at that or will be. It definitely depends on the use case. So that's one thing I'll note here is that what does sound most of the time works is I'm sure there's that one use case it's like, okay, fine. But you know what I mean? But nine times out of 10, let's say we have to take some JSON. It's huge and we need to maybe convert these objects into an array let's say, I don't know. I'm just making things, you get the point ...

Jeremy: I get the point.

Aaron: That type of business logic where you're trying to translate things and just stuff that's really tedious on the CPU. You can start to put that on WebAssembly modules and from the portability too, you can start sharing it on different platforms. And it's like, oh, this is really exciting. Yeah.

Jeremy: So I'm curious about this too. You said if JavaScript isn't fast enough and a lot of companies have to use JavaScript sometimes make it do something, sometimes it shouldn't do maybe. So if I'm a developer now, I love Node on the backend, I love to know because I'm just so familiar with JavaScript that it's just really easy to go back and forth between the front end and the backend using this one single language. And pretty much anytime you have to write something for the front end, it has always been JavaScript. You had to basically do that. So is this something though where ifw... We will get into the other languages you can use ... could I compile an entire application or maybe a front end app or what do they call it a single page app or something like that, that I might write in JavaScript now, could I do something like that compile it down to WebAssembly and then do a similar thing?

Aaron: Yeah. So that's actually a really interesting question. I'm glad you asked that. So the short answer is no, but we'll get into why. And it becomes really down to two different reasons. The first being WebAssembly and its nature is binary format depends on strict typing. So you have to say, hey, I have an i32, I have a i64 integer, i64, so on and so forth. JavaScript is dynamically typed and that's part of why we need to interpret and do that just in time thing to figure out those types on the fly. So JavaScript just isn't quite designed to compile down to WebAssembly. And then two I'll say, is that there are some alternatives. Let's say you wanted to write a Rust step that is a Full SPA. There's a few products out there that do that, I've seen them on GitHub. I don't know any off the top of my head, but they totally exist. And that's something you're into then totally feel free to do it.

But I will make the point that JavaScript as we mentioned, has been being pulled in a lot of different ways. But one thing that was sure was designed for was interacting with DOM and building UIs. So that's where I think JavaScript really excels where I would say you really want to just compile a straight SPA into WebAssembly because WebAssembly really get those computationally intensive things. But SPAs, for example, when you see those react demos of like, look, we got 10,000 triangles that are rendering every second. JavaScript is amazing at that because we've been iterating on making JavaScript good at that for so long. So yeah, I hope does that answer it. Does that make sense?

Jeremy: It does. No. No, it does. And actually, to extend that though, there are things that you might want to do in a browser that are fairly I would say insecure especially if you have to do anything with crypto or you have to sign a call or some of these other things call an API that you maybe you need to have a secret in that API call. And obviously, you don't want that available via your JavaScript by just viewing source. So are those some of the things that you could potentially do with WebAssembly where you could compile down something that did cryptographical signing or something like that. And then with the bytecode could you reverse engineer that bytecode? Could you come back and find the actual source on that? Or is that something that might be secure where you could use something like that to do some of those more complex and maybe things that would add a little bit of security to your app?

Aaron: Yeah. So that's a really interesting question. I'm glad you asked it. So I will first iterate and say again, we're talking about that cryptography is going to use a lot of math operations very performance-intensive, which makes it a great fit for WebAssembly. That being said on the security side of things, it gets really interesting because there is a text format for WebAssembly. It's not the same as JavaScript where you can go and view source and it's just like, oh yeah, this is totally what's running on the page. Nowadays with mangling and the translation, it gets more complicated, but WebAssembly is more of a binary format where we can do some funny things. You'd be like, hey, look, it's moving this memory here and there, but to see the actual source code is a little bit more difficult. That being said, I won't pretend I'm a security expert especially in cryptography space ...

Jeremy: I'm not either. So yeah.

Aaron: I've definitely seen some projects that are like, hey, look, we can make this things secure with WebAssembly. Here's our white paper on why, but I wouldn't be able to confidently sit here and be like, oh yeah, totally just throw secrets and WebAssembly, no one will ever know what it is. You know what I mean? So I would definitely suggest maybe I always get back to you about that or we can do ...

Jeremy: Yeah. No, I'm just curious. I'm thinking through the places where it really fits in. Because I think that's a problem, security in the browser, it was with so many people using APIs now usually, and again, a good use case for serverless is essentially setting up a function that all it does is just adds that secure key or whatever it is that access token into a third-party API calls so that you can just pass it through from your from browser. So if you could eliminate that step, you know what I mean? And be able to do some of that I think that would be interesting.

Aaron: Yeah, totally. Yeah. And I definitely agree. For example, whenever we're importing a bunch of packages, and let's say they're both accessing global scope just cross their fingers and hope they don't do something they're not supposed to. That is one benefit again about WebAssembly is that all that sandboxing, that linear memory and dances that only really has access to what you give it to. So if I were to have three WebAssembly modules, they couldn't go and talk to each without JavaScript being in between hey, you're telling this person cool, here you go. Let make sure you're not doing anything funny between one another in the current state of WebAssembly today, so.

Jeremy: Awesome. All right. So let's move on. Let's talk about WASI. What is WASI?

Aaron: Oh yeah. So WASI is an acronym for the WebAssembly System Interface. And this is where in my head, WASI is the node of WebAssembly. I know it's a very loaded term, so please take it with a grain of salt, but essentially it's a standardized system interface for WebAssembly. So you get things a lot of positive Slack calls, if you're familiar with a lot of ... it's getting low level, but you can imagine stuff like fd write, fd read. So reading file descriptors and things, you get access to those things. So you can imagine a Node, you have file system and that's how you would let's say, make generate files on a server. He used the module fs. WASI offers that lower-level primitive that allows you to do those things in WebAssembly like create files, read them and move them around your file system, which I'm talking in circles, but I think I get the point. So what actually ...

Jeremy: So you wouldn't use WASI in the browser, right?

Aaron: So it gets funny there because there have been some ... you can use things IndexedDB if your familiar to create a pseudo file system and start to port, maybe let's say you wanted to compile something in the browser. If you want to bring a C compile into the browser, you could use the WASI things and mock out some of these system-level resources as a browser equivalent and get into this funny world where it does make sense. But WASI itself one of its goals right now isn't really to run in the browser if people are bringing it there. So if you want to, again, bring a compiler but you totally could, which is exciting and really cool. And I think that there's a talk by Ben Smith they did this exactly for their class. They taught I think I forgot what university, but yeah, they made like a C compiled WebAssembly compiler that link took C source compiled it. And then there's something else is I wanted to say about that?

Jeremy: Well, I'm just curious, so then if it's not really for the browser, I get it. Everybody loves to do those things like, oh, can I take this thing that wasn't built for this and make it work in that. But so what would you say are the primary use cases then for using WASI?

Aaron: So a lot of it is probably bringing WebAssembly to the server. Yeah, probably for the server or just even standard command line applications. WASI is really exciting. There's a lot you can do. And you'll hear me say that a lot about WebAssembly, there's a lot you can do with it. So really I like to think of WASI as like all the benefits of WebAssembly, so that sandboxing that you get and that host calling interface. Because really what WASI is using is it host call just like, hey, you have access to the file system please, do what you want with it. So because you get those benefits. There's an infamous tweet. I know I'm talking, but ...

Jeremy: I think an infamous.

Aaron: Infamous, that's not the right word, but a tweet that went viral by Solomon Hykes. If you're familiar, the co-founder of Docker about how WASM plus WASI existed. And I think in 2008 is when they made Docker that they maybe had not needed to make Docker. And the reasoning there is that like, if you could take different applications and compile them down and give them access using a system interface that's standardized and have access to things like file systems, you can start to imagine this world where you get container-like functionality where you're just like, hey, I'm gonna compile my whole app and all of its dependencies down to WebAssembly, give it access to WASI and they can start to do things, and operate in a sandbox way where you don't have to worry about it messing with the parent operating system or completing with other apps and things like that.

And then of course we're on Serverless Chats. So a lot of serverless use case there because WebAssembly is very I guess lightweight and things of that sort. Sandbox, it makes it a great contender for serverless because you can just instantiate the WebAssembly module start running immediately and then close it down. And even do things like snapshotting of the memory and saving state and things like that. But we get to in the future there's still some kinks to figure out there just in general in the whole ecosystem. But yeah, and then a lot of standalone applications. So we were mentioning if you want to compile a C compiler to WebAssembly, give it access to WASI and run it on your local machine. Now you can start compiling things on your actual let's say standalone runtimes. If you just wonder if for some reason it gives C source code to just a WebAssembly module and have it compiled.

Yeah, sure. Cool. And I'm sure there will be use cases for it because then you could imagine a world where it's like, I won't use the exact same file that I used my exact same compiler binary, because I use Mac windows and Linux all do recompile for each architecture at each operating system. So again, that portability and yeah, it was probably, those are really good use cases I can think of off the top of my head right now.

Jeremy: Right. And this might be a stupid question, but I guess the idea of it being the Node of WebAssembly in that sense where basically that's what it is. It's its own container essentially that can do anything, it can interact with the file system, it's got all of the capabilities, HTTP networking calls, it can do all that stuff. And I know the V8 engine is pretty popular with edge computing and things like that, is that something where that can run on like a V8 engine or is there another type of underlying, I guess, container management system or something that would need to run those?

Aaron: Yeah. So I'm glad you brought this up. So one thing I would just say as a quick note so HTTP is still being standardized. So all this is really young. So I wouldn't want somebody to like, oh, HTTP is in there? Cool. All right, let me just close the tab and start crying. You know what I mean? So there's a lot of standardized API still in the works. And we can get into them that too if you'd like, but to answer your question, I'm like, hey, could you use WASI inside of VA? Again, we can probably polyfill some things and then you can totally it in there and that JavaScript way. But what gets interesting about that is that you can run it if you can imagine a world where maybe you don't really need the JavaScript as well that V8 provides, then you're instantiating a JavaScript runtime and a WebAssembly runtime. Whereas if you use some of these other runtimes that only support WebAssembly you get a lighter weight output from it and things like that.

So yes, you can use V8, but it's depending on your use case if you want to have that solid WebAssembly JavaScript relationship at all times, V8 is probably the right answer, but if you just want to use WebAssembly, then the standalone runtime is going to be lighter weight for, and be able to optimize specifically for WebAssembly a little bit better.

Jeremy: Right. So there are standardized runtimes for WebAssembly?

Aaron: Yes.

Jeremy: Okay. That makes sense. All right. So you mentioned some standardized APIs and we talked a little bit about crypto and how that's a good one to deal with. But you've got crypto, you've got machine learning, all kinds of these complex things that are really hard to do especially in JavaScript. And again, I know we're now more towards the server side of things, but what are those types of ... You mentioned they were standardized APIs, what can those do? What are those capabilities?

Aaron: Yeah, totally. So I will say these are also still in flux, they're still being developed. And if you want to participate there's totally community group for WASI that you could totally hop in and join, but this is me, I attend the meetings, having for a little bit. So it's like sharing this little things is going on here and there. So yeah, one of them is definitely crypto, a colleague of mine, Frank Dennis, is working on that where there's a lot of common crypto applications that we would want the host to say, hey, the host runtime we know that you're running just raw bytecode, there is no layer between you and the kernel essentially. So could you please provide SHA256 and make sure that it's working correctly, you won't expose the right thing.

So probably like common crypto functions that people are often using. I don't know if SHA256 is one of them I heard ... you can imagine. If you're a crypto person out there you know, exposing those common ones that folks use. And then machine learning, I'm a little bit more familiar with that because the Bytecode Alliance is a group of different companies that are working together on WASI and WebAssembly and all these specs and they recently announced they're working on a WASI. So a neural network and WASI and providing the primitives there of, if you want to build neural networks on top of WASI what are some of the host calls that we'll need? What are some of the functionalities that we'll need? So we start to build our own neural networks in WebAssembly, which is really exciting.

Jeremy: So are these standardized APIs? Again, this may be a stupid question just because I don't know enough about this stuff yet, but are those NPM packages or Python packages from PyPI or something. Whatever it, is that the idea behind some of these APIs where you say, I need a crypto package, or I need a machine learning package, or I need an image manipulation package, is something where there will be an ecosystem where people can write and contribute packages that other people could just pull in?

Aaron: Yeah. So this is more a little level above that I would say, you can imagine 10 portal, for example, as a new date thing was coming into JavaScript. It was already a few libraries out there, hey we're playing around with this new date API. Here is my version of it and your version of it, but a lot of the community is working together on deciding, okay, well, my organization has these needs for temporal, my organizations as these, what are the compromises that we'll need to make from the entire community to have access to this one standardized API? Eventually for example, Chrome or your whoever's implementing your JavaScript runtime will support natively you wouldn't have to use a library anymore. So I would say it's a little level above, and I'm sure as these APIs develop people will develop like, hey, look, here's the current version of WASI and Rust let's say. And you can include it in your Rust program it then compiles all the way down to WebAssembly. And so, yeah, I hope that ...

Jeremy: Yeah. No, I'm just wondering here because one of the things that I think makes Node and JavaScript, the reason why those ecosystems grew so much was because people contribute to those things. So if there's a way for people to do that and know oh, if this doesn't do this now I don't have to write this whole thing myself. Somebody else may have done this for me and I can just go ahead and bring that in. Yeah. So I don't know if they'll eventually be like an NPM for WASI or whatever or for, I guess WebAssembly in general. But yeah, anyways, I'm just thinking that would be a cool thing to have. So if there's not one of those things out there, then my suggestion is you create one of those things and make it so that people could contribute code.

Aaron: Yeah. So if I could on that note like I had mentioned a little bit earlier before I grazed over, is that in the browser at least, I think in WASI too you could ship just an NPM package of what saying today. And if they used WASI like we mentioned, so it's a little part in there depending on what you want to do. So just a registry in today's world is probably MPM and I have seen some smaller WebAssembly package manager type things that are popping up here and there but right now I think NPM is the ... for a lack of better word the king of the packages right now. We'll see if something else comes up may do something that's more WebAssembly focused rather JavaScript with the WebAssembly if that make sense.

Jeremy: Yeah. Cool. So let's into the toolchains here and maybe we just focus on the popular ones because I'm sure they're a lot of people that are going down this road but you mentioned earlier that WebAssembly was language-agnostic, so you can just write it in any language you want or? There's got to be some limitations here.

Aaron: Yeah. So there are some. Pretty much the limitation is that, is your language willing to support WebAssembly? So especially if it's a strictly type language. So there is, for example, Go is working on something. Let me think of another, Swift has a WebAssembly implementation, Zig is an up-and-coming language that has WebAssembly implementation. There are some languages where it gets funny. So for example, these dynamically type like JavaScript and Python, they're in a world where it's well, just the language doesn't quite line up with what WebAssembly needs when it comes to being compiled. So I mentioned those, but probably the biggest three right now is Emscripton, which is a toolchain for compiling CNC plus to WebAssembly. A lot of folks use it. Google I know it has a lot of folks working on Emscripton and they highlight a lot of projects using it. If I'm not mistaken there's a talk from WebAssembly SF in which the Google Earth team talked about how they're using Emscripton to like, again, take all that business logic and make it more portable across where they need to run Google Earth which is really exciting.

Another big one is Rust. I had mentioned earlier, it's a language that's grown to become quite popular. It's got another systems-level programming language, but Rust has a little flavor of both taking these older C applications I guess not really porting, but building these one-off modules to go off and do maybe me to put JavaScript, serverless type stuff, whatever it may be, Rust is really starting to shine in that area. And a lot of folks really passionate about it. The community is really cool and there's a lot of great documentation. I guess what I'm trying to say really is that Rust has a really solid WebAssembly support. They are going all-in on it, which is really exciting.

Jeremy: Well, just thinking back to things that I've heard, I feel like whenever I hear Rust I just think WebAssembly, is that the wrong way to think of it?

Aaron: Rust does a lot of different things, but it's not maybe the wrong thing just because they spend a lot of time really building out a lot of the tooling, a lot of the community around it and things. So Rust definitely also has lots of great use cases that I've seen at Rust conferences where they were in Rust on no server, they do it in games, so on and so forth. It's a systems level approach, so programming language. So you can imagine you can run see there. Nine times out of 10 I think you could run Rust there, but just there WebAssembly ... What's the right word? Involvement, there's another word starts with an "I" that means what I'm trying to say, but they spend a lot of time working on creating a great developer experience on WebAssembly and Rust. So yeah, because right now I will say like some languages like Go and things are still very young in their WebAssembly implantation. So some of the tooling is like, good luck, but I'm sure that will get better over time as more of the community works on it and things.

And then if I could transition too, there's one more tool chain that's really popular right now and it's called AssemblyScript, I'm a member of the team on that. And what a AssemblyScript is it a very TypeScript-like, not TypeScript exactly, but if you can read TypeScript, the Typescript-like language that compiles to WebAssembly. So the target. There's a lot of these JavaScript developers that we mentioned earlier, JavaScript can't compile WebAssembly. So it's like, come on, we want some of the fun too. So we're hoping to maybe fill that gap and getting developers the closest thing to JavaScript that we can provide it for them that allows them to access all the benefits of WebAssembly. So yeah.

Jeremy: Yeah. Well, so the AssemblyScript thing because I was doing some research before this and when I saw that, I was like, okay, now you might have me because I'm thinking some of these other things. I spend a lot of time in Node and in TypeScript and JavaScript. So for me, I was like, oh, this would be really great. So I do have a bunch of questions on this though and since you work on the AssemblyScript team, you're the perfect person to answer these. So what are the differences between TypeScript and AssemblyScript? Is it almost exactly the same or are there some significant things that I'd have to worry about?

Aaron: Yeah. So one thing is I'll definitely point out is that we mentioned earlier about SPAs, but just imagine not even ... I'm trying to think. So if you take a TypeScript React app or TypeScript Node app, you can't just grab the AssemblyScript compiler and be like, hey, I get WebAssembly for free. Cool. That's not how ... There's a lot of small fundamental differences where you have to actually take the time to port things. But the porting comes down to like, okay, you know this number type number isn't again, that strictly type integer of whatever many bits. So you have to take your numbers and convert them to i32s, you'd use a float there, you need to specifically say like, I want to float here. And things of that sort. But for the most part, I actually wrote an article in the Facet Blog about porting TypeScript to AssemblyScript and what that looks like.

Yeah, I think it might even have been a JavaScript application, but yeah, just like, hey, look, there's this variable here. It's a number we know that but JavaScript does the work for us. Let's just explicitly say this is a number. And yeah, pretty much that's like a lot of the big fundamental differences. There are some "gotchas" to some of the script. One of them being is that since it's young, it's only about a two-year-old language, it's been getting popular though thankfully, is closures is a big one. So if you're doing a lot of callbacks, that callbacks, I call it callbacks. As of right now, we're still working on getting that working in WebAssembly memory and things. So you have to pull those functions out to separate functions which is a little annoying, but we'll get there. You know what I mean? And in most use cases you have that. And then ...

Jeremy: So in terms of the workflow for some of these things, like I'm writing TypeScript now you got to compile it, right? And then I usually run tests against my TypeScript and then compile or compile and run the tests. So what does that workflow do I have to go from ... Or I guess I just writing in AssemblyScript which has to be very similar to TypeScript and then just compile it down to Rust, but how does the testing work and some of that other stuff?

Aaron: Yeah. So that's actually probably the best closest thing. So AssemblyScript is an NPM package that you MPM install into a project and you can scaffold out in AssemblyScript project essentially. Another thing is AssemblyScript it pretty much uses the .TS file extension, so if you'll put the .TS code it's like, oh, hey, this is a TypeScript. And it comes with a TSConfig. So the TSConfig will say like, hey, i32 was an alias for number for your Linters and things. So you open up VS Code and it's like, oh, this is just TypeScript. Cool. Awesome. So you can just hit the ground running in that aspect. If you're used to writing TypeScript, the amount of workflow difference should be near nothing to my experiences. When you start doing some really specific TypeScript things or if you have small things here and there, it gets funny.

So good examples is that even for documentation, for all the AssemblyScript packages I've been writing, I just use TypeDoc. TypeDoc can look through AssemblyScript and be like, cool. Yeah. This is, this goes there, this goes there and there's almost no actual small things I need to do there. And in terms of testing AssemblyScript has its own testing libraries, but I can promise you it's extremely solid. It's called Aspect. It's a just library written by Joshua Tenor. And if you've written Jest, it looks like JavaScript testing. It's like, describe it does that, yeah, expect to be, it offers all of that in AssemblyScript so.

Jeremy: Right. So you write something in AssemblyScript, I know we were talking, so that is compiling it down, is that using WASI? And then what can I do? Can I pull in Node packages in there or does everything I do need to be AssemblyScript?

Aaron: Yeah. I'm glad you asked. So it ends up compiling to it. So this is really technical but it uses a compiler backend called Binaryen. And it pretty much sits at the same level as LOVM if you're familiar. So it uses their immediate representations you then compile to WebAssembly. And then on the note of using separate NPM packages, it would have to be AssemblyScript all the way down. So that is one thing that some people are like, oh, but my favorite image thing is it there? And it's like, we'll have to port the dependencies to you which is annoying, but the ecosystem is really growing. For example, I've been running a lot of URL packages lately for URL parsing. And I saw we have the testing library, there is someone who recently wrote a JSON parser. So there's lots of little small things popping up. The community is growing and it's all an NPM.

So if it says like, hey, look, I'm an AssemblyScript package the VM can install it, and then it should work in your MPM project. I think you asked one more thing.

Jeremy: No, I was just wondering again, if you have the same access to some of the low-level things. So if you're compiling down to WebAssembly using AssemblyScript, are you then able though to do things like HTP calls and access the file system and those things?

Yeah. So that's what you'd ask about WASI. So yeah, essentially you would say, hey, import WASI, and then it'll give you access to those fd read, fd write and stuff, you don't have to directly access through file descriptors. Another community project as-WASI, is kind of like sitting at the same level of Node where you import file system as a whole word. And then it has a create file or maybe not create file, read file, write file, whatever the API names are that I can't remember in my head. But we do into this interesting place. We have a project, an AssemblyScript project, that we're waiting for HDP to be standardized on WASI for that is just called AssemblyScript/Node, because ideally since the APIs are so similar there's nothing stopping us from creating a very as close as to Node as possible API where you can start to just maybe copy paste notes then they should just work, because the languages are so similar.

Aaron: One last ramble if you don't mind ...

Jeremy: No, go ahead.

Aaron: ... is that AssemblyScript is so similar to a TypeScript that even though you can't take AssemblyScript code and run it through the TypeScript compiler, you can take AssemblyScript code, do some small tweaking here and there and get it to run through the TypeScript compilers. You can have the same source code, and let's say you're running in an environment for whatever reason, doesn't support WebAssembly you could just compile it then to JavaScript and stab and call it a day. Which is I think as a testament to how similar these two languages are. So yeah.

Jeremy: Well that's portability too, right? That's really actually, that's cool. So you mentioned a little bit about the ecosystem and the community around it. That is a huge thing where again, things grow when stack overflow is a lot of people's friends, right? So if you can't get your questions answered there or you can't Google for some of these things. So I know you said you've got the ecosystem is growing and you've written a bunch of blog posts and there's a bunch of other people working in this. But if I'm out there and I'm working on AssemblyScript, am I going to be able to find a lot of blog posts on this or is this still very, very early?

Aaron: Yeah. So I think it's probably a little 50/50 not that it's that early. So I guess the reason I'm saying 50/50 is because there's not swaths of people in stack overflow, they're all the AssemblyScript experts that can answer all your questions. The community's a little tighter. So we have a discord server and we have a help channel that's very active. If you want to have a question asked by the person that writes AssemblyScript. Yeah. They're there almost ready to answer any questions, I'm there. Our teams about four to five people, I'm sorry, a sixth person, but we're all there. And I check at least maybe every couple ... whenever I have downtime at work, I'll check and see if anyone asks me any questions. So it's a tight community on our discord.

In terms of blog posts, there's a lot of blog posts. The only reason why I'm 50/50 there is because the project has grown really fast. So there are some blog posts even that I've given that's like, hey, here's how you use pointers in AssemblyScript. Yeah. Not everyone wants to do that. Now it's like, we have more mature runtime, garbage flexes to someone's stuff. So your mileage may vary depending on what block ... There's a lot out there, yes, but maybe 50% of them are still very relevant to the AssemblyScript you would write today. If that makes sense. Or be there like, here's how you write your own JSON thing, but now there's a package for it. So they don't do it? So yeah.

Jeremy: That makes sense. So have people been using this? Are there some success stories here? Have people been successfully building applications with AssemblyScript?

Aaron: Yeah. So just going chronologically in my head. The first one if I may a little self-plug here, is that the reason why I got involved in the project was because I was really excited about WebAssembly when I heard about virtual performance and I was like, oh, I got to get on this asap. So one thing I like to do was build emulators because I think they're really good at testing any new technology because you need graphics, you need audio, you need to make sure that it runs fast enough or things of that sort. So I built in Game Boy emulator called WASMBoy in AssemblyScript. And it's really early days where I was just pointers, memory, stuff's moving, but because it was a Game Boy emulator that's what you have to do anyways. And from that, we found a lot of bugs in the project and we worked through them together.

Yeah, that was probably I guess maybe got no one in with this only community early on, it was like you have to do the build the Game Boy thing, nice! So that's probably the first one. Probably the most recent one I can think of as of recently in terms of just general community is there's someone named Marshall Duin. I said their name right. But they work on a storyboarding application. I think it's called Micrio. And they wrote a whole article about how they were using Javascript and think Canvas at the time and things like that. And they had taken all those hot paths, those things that were computationally intensive and rewritten them in AssemblyScript and started using WebGL and stuff just updated the application to modern-day. But AssemblyScript was a huge part of that. And they wrote an article about like, yeah, I could read it, it made sense, compared to alternatives I didn't have to learn a whole new language they had a really good experience with it.

And I think I'm 99% sure she's on the article up right now, but they shipped it to production and their users are happy and they saw huge performance increases from just the nature of WebAssembly because they used it in the right places and things. So that's really exciting. And then probably more recently today Fastly has been using AssemblyScript that's one of our supported languages on computed edge. So it's still in data and we've had some customers try it out and had some really good feedback about it. And some folks really like it again because it's like, hey, look, I know JavaScript this isn't too much of a transition for me. Cool. Thank you. So that's really exciting.

And then I know Shopify publicly announced they've been playing with AssemblyScript a lot. I know from being on the team we chat with them a bit, but I don't want to get too into their business, but I'm very happy for them. But I would redirect you over to what they've said, just I don't see any wrong. Yeah. But they're trying us out as well, which is really exciting. And shipping stuff if I'm not mistaken. So, yeah.

Jeremy: Awesome. So it sounds like WASM and WASI, AssemblyScript, all of these things are coming together. It's growing, it's becoming more solid like you said, you wrote some blog posts where it was really low-level stuff, and then you started building ways that make that easier. So I guess there's still some limitations in here, it's probably not the right choice for everybody, but I'm excited about it because I think that it could change a lot of things, but I guess maybe since you work on this team and you're part of this ecosystem, what's the future? Where do you think this is going to go? And are we going to get to a point where we can use this for pretty much just everyday stuff?

Aaron: Yeah, totally. So the first one that I'd probably be most excited to bring up is this idea of nano processes. So that sounds really flashy. So I'm not the one championing this, I'm not the main person behind this. I would very much redirect you to Lin Clark's talk who gave a talk about this idea WASM summit of last year. But from how I interpreted when nano processes has this idea of that there's this concept of shared nothing linking. So for example, in the MPM ecosystem, if you have an MPM module that requires another MPM module, and this top MPM module was like, hey, look, I want access to everything that MPM or Node provides. And in this bottom module, and for some reason, this module is like, going to throw some things on global because I feel like it, and the bottom module is like, oh, that's cool. I'm going to figure out some way to get required by this person. That way I can start accessing the things that I didn't have to require.

Therefore, I look okay from a security perspective, but I'm taking advantage of some of the JavaScript type things that MPM allows. And we've had a lot of security, I guess, scares that they were valid scares because things in the ecosystem, because of this problem. So the idea of shared nothing linking is that in the future we're hoping that WASI modules can import other WASM modules. From that you have to declare again from the host call or whatever it may be like, I want these specific things so we can figure out like, okay when we run in the runtime, we know you only need access to fast. You don't need access to machine learning you, whatever crypto, you don't need access to that. Your parent module has access to that, but you don't need it. So we're only going to make sure you only have access to those things, not everything that your parent needs only what you need. So this creates a really good thing so that way you're not escalating out of MPM WASM modules to new WASM modules, because you're really only linking what you need and not the whole everything. If that makes sense.

And another big one is interface types. Again, so we're already on this topic of WASM modules importing other WASM modules and linking together and things. So not every language is the exact same. You talked about this language on let's say WebAssembly. So to see a problem where it's like, well Python strings are different from JavaScript strings that are different from Rust strings that are different from Java strings, what do we do? So this idea of interface types. So pretty much a specification for like, hey, look, if we know your language uses UTF-8 and this language is UTF-16 let's figure out a way so that when you y'all talk to each other, there's not a huge performance cost that needs to be paid of reencoding every single time y'all go back and forth between each other. Or if you just take a string and you just pass it to a third WebAssembly module, we shouldn't have to reencode it from like UTF-8 to UTF-16 back to UTF-8, it should just go straight through, you know what I mean?

So trying to specify that and find a where we can standardize that so that WebAssembly stays fast in that regard of passing memory around between other WebAssembly modules and leading towards that. And take it with a grain of salt, but that MPM-ness, everyone is connecting these packages, like LEGOs that build a bigger picture and a better structure using community and open source and things. So, yeah. Let me try to think, and then ...

Jeremy: Was there anything on performance? I know the performance is pretty good, but any updates or ideas on performance?

Aaron: So glad you brought that up. Thank you. So yeah, one of the big ones is SIMD. One of the champions for it, one of the most involved people is Thomas Lively and they give her a really funny talk, in which ... SIMD what it stands for is, Single instruction, multiple data. And I can't explain it over video, but the idea is that pretty much they're like, hey, let's say we have this four different array of four numbers and we want to add them all to another four numbers. If we were to do that in JavaScript, we'd be like, okay, well array zero, plus array zero of this one, because the new array zero array one of array one there goes a new one. And then in their slides, they're like, but we have SIMD we just add them directly and it equals any result. And you know it's faster because it took less slides to explain that then if you're going array zero to array zero.

So that's really the idea is that if you had a vector by the mathematical terms, but if you had an array of numbers and you want to add them to another array or do the same single instruction to multiple data, it just does it all once. And it's lots of performance benefits out of that. So getting that working in WebAssembly it has a ridiculous number of different instructions because you have to think, okay, well, if I have an i32 that's six long versus it just creates a lot of WebAssembly instructions. I'm probably rambling a little too much. And then I had one more note and threads. Thread is another ...

Jeremy: Yeah. Threads, I was curious about that because I didn't ask you that earlier. And I'm just wondering is when WASM runs, is it single-threaded multi-threaded, can it do to do multiple threads? How does that work?

Aaron: Yeah. So as of today WebAssembly is all synchronous and it's all single-threaded. In JavaScript ... I've given a lot of talks about this. If you use Web Workers which unlocks multiple threading on the web with WebAssembly, that is the performance, like chef's kiss. Yes, if anyone out there is building a computationally-intensive of intensive web app, Web Workers and WebAssembly is a match made in heaven. But for a lot of folks out there that wanted maybe reporting over a larger C application, for example, threads is launching off threads and WebAssembly itself is something that lot of folks are excited about. If I remember correctly last Google IO or Chrome Dev Summit or whatever it may be, VLC has been talking about a port to the web and what they're doing there.

And they're really building a lot of their port on top of WebAssembly threads, which a lot of folks at Google are doing a lot of specification work there. So it just shows like, hey, look, we can watch whatever random video format, the browser, only the supported ones using a VLC port. Yeah. And also, again, I'm not an expert on the work at VLC. So we can do some Google searches I can send a link or provide more research later, but yeah, those are super exciting. So yeah.

Jeremy: And I mentioned earlier this idea of an MPM type thing, but is it possible? Because this is another thing where I like about serverless is that, you can write one function in Python or another function in JavaScript and another function or Node, and then another function in Java or whatever. And of course, they're isolated, so they don't have to necessarily run together so you can use those different runtimes. But is that something that's possible? If somebody wrote a WebAssembly script in Rust and compiled it down and then somebody else wrote one in AssemblyScript, are those able to work together?

Aaron: So that's the future we're definitely headed towards and we're really excited about. There is a specification I mentioned earlier about the WebAssembly module for another WebAssembly module. We're hoping with this event called a Module Imports, which more of we're working on it. So essentially you wouldn't have to have all AssemblyScript or all Rust once they compile it at WebAssembly then they can say, okay, well we're both WebAssembly now. So let's import each other, it doesn't matter what our source code was. So module imports is hoping to solve that problem. And once we get more of these things standardized out while things are still young, that's the future we're headed towards of which my dream thing seems for you as well is like, oh, I would ... Personally I love all the work that Python does in the machine learning community, but Python's not for me, but I would love to access all the cool things that doing over there. But as a primarily JavaScript developer, I'm like, oh I'm going to play with Dom ...

Jeremy: And that's actually ...

Aaron: ... not to downplay myself, but you know what I mean.

Jeremy: No, no, no, no. No, but that's interesting because that's the thing where, think of a global NPM, you know what I mean? Where it's just some functionality was built and if you can pull that in to maybe you're AssemblyScript person because that's what you're familiar with, but you can't make AssemblyScript, do some complex crypto thing or whatever that may be some other language could and compile down because it's either further along or whatever it is. Being able to share those across applications and reuse those. That sounds pretty exciting.

Aaron: Yeah. It sounds super exciting. Definitely, I think that's the future we're headed towards. As a community, we'll see what gets announced here and there and things. And again, there are some folks trying it out already, this idea, but no, we'll see. Really it began also, as you are very bullish on this idea of like, yes, we can totally have this cross. It's no longer are we bounded to our languages. It's like, we just write code and we can all be one large ecosystem. It's going to be awesome. I'm looking forward to it.

Jeremy: Cool. So I want to ask you one more thing though. So let's say that I'm a developer I'm listening to this. And I say, WebAssembly sounds amazing, how would I convince my development team or more importantly, probably my boss, how would I convince them, hey, this is something we should start investing in?

Aaron: Yeah. I'm so glad you asked. So the thing about WebAssembly that's really interesting, and I get asked this often, it really depends on what you're doing. We've maybe covered like, oh, you can do this, you could do that, you could do this, so it depends what your area is. For web applications definitely if you're building an application that does computationally-intensive things, maybe you're working on an online photo that, or whatever it may be. Maybe you're working on a spreadsheeting tool where you have to do complex math functions. Just understanding really where WebAssembly fits into an application that's where you can start to make the pitch to your boss. So if you're really excited about this right now, I have some resources that I built called WASM By Example which is how you can get started with little bite-size examples of WebAssembly, but another one is Made with WebAssembly.

So wasmbyexample.dev and then madewithwebassembly.com. WebAssembly is just a showcase of a bunch of folks using WebAssembly in production and side projects pushing like, okay, well what's what WebAssembly good at, these are some examples. So if you can go on madewithwebassembly and you're like, oh, my app does something similar to that, maybe you're on the right track. Maybe it's worth considering well, what your team needs and things. So yeah, I guess really just understanding what WebAssembly is good at and then see, how can we fit this into our application is probably your best bet, because then you can make a solid argument for why.

Jeremy: Awesome. All right. Well, I'm going to put all of that information in the show notes. I know there's a bunch of links that you have and all really good documentation and just good ideas, like you said if you want to convince your boss or whatever to use it. So I'll make sure I get all that in the show notes, but Aaron, thank you for sharing this. This was super exciting because I just don't know enough about this stuff. So anytime I can, I just love learning this stuff. And I'm super excited about the computed edge stuff. I think WebAssembly is such a great packaging format for that. But I'll put some of those other links you mentioned in the show notes, but if they just want to find out more about you how do they do that?

Aaron: Yeah, totally. Probably the best way to get ahold of me is on Twitter. So my username is torch2424, just as a quick, people ask me why? I got to be in it really young when I was like six, Torch was my imaginary friend. And then 24 is my favorite number when my kid Brian was 24, 24 twice. So ...

Jeremy: There you go.

Aaron: Yeah. Hopefully that story helps drive with my name, but yeah, I'm on Twitter most of the time. Yeah, probably reach out to me on Twitter, probably the best. I'm trying to think. If you like ...

Jeremy: I've got your LinkedIn here, I've got your GitHub which is torch2424 as well, check out Fastly.com and everything that your team is working on over there. And then I think, yeah, you mentioned The Bytecode Alliance too, right? So that's just bytecodealliance.org. Probably some great information there and then I'll get everything else in the show notes so people can check this stuff out. Give them some weekend reading to do, but thanks again, Aaron. I really appreciate it.

Aaron: Yeah. Thank you very much for having me. I super appreciate it. And yeah, looking forward to keeping in touch and things.


Episode source