3: Web Assembly

Web browsers and web sites have been around for quite a while. Javascript has been the language driving those pages but there's a way to write in a lower-level language and speed up the slow parts without losing cross-platform compatibility. That way is called Web Assembly (WASM). In this episode Jim explains exactly what that is, and Wolf asks questions.

Show notes:

Take-aways from the episode:

1. If you have a compute intensive part of your web application, it may make sense to implement that bit of code in a compiled language like C, C++ or Rust and then compile them to WASM so they can be executed in the browser.
2. Security and Portability. WASM code is secure as it utilizes the browsers' sandbox and portable as all browsers are supporting the W3C Standard WASM.
3. You are almost certainly using WASM based applications. It's in use in Google Maps & Docs, Netflix, Spotify, Amazon and many more.

Links:

• https://emscripten.org/index.html
• https://emscripten.org/docs/getting_started/Tutorial.html - Nice tutorial
• https://github.com/WebAssembly/wabt - Web Assembly Binary Toolkit
• https://collabnix.com/top-20-companies-that-uses-wasm/ - Companies using WASM
• https://developer.mozilla.org/en-US/docs/WebAssembly/Reference - WASM Instruction set
• https://developer.fermyon.com/wasm-languages/webassembly-language-support - Languages supported
• https://github.com/snaplet/postgres-wasm - Postgres implemented in WASM

Hosts:
Jim McQuillan can be reached at jam@RuntimeArguments.fm
Wolf can be reached at wolf@RuntimeArguments.fm

Follow us on Mastodon: @RuntimeArguments@hachyderm.io

If you have feedback for us, please send it to feedback@RuntimeArguments.fm

Theme music:

Dawn by nuer self, from the album Digital Sky

Transcript

Wolf: 0:03

Welcome back to another episode of Runtime Arguments with Jim and Wolf. Uh we've both been curious software engineers for quite a while, and each episode we try to learn something new or report on things we've built or done and share it. Um topics we've covered so far have mostly been questions that came up in our conversations over lunch, and usually tack or tack adjacent. We're just starting out in this podcast world, uh, and we appreciate you listening and helping us get better. Um I'm Wolf, and my friend and partner in this show is Jim McQuillen. How are you doing, Jim?

SPEAKER_01: 0:47

Oh, Wolf, I'm doing great, and I'm really excited about this episode we've got for you today.

Wolf: 0:54

Um we have gotten uh more feedback, which we love and value. Uh we want to get this whole thing right uh and we want to get better. Feedback drives those things. If you have feedback, you can reach us on Mastodon uh runtimearguments at hackyderm.io or by email feedback at runtimearguments.fm. Those will both be in the show notes. Um two pieces of feedback to share with you from previous episodes. Let's start with thoughts on uh Jim's cloud transition. Jim.

SPEAKER_01: 1:33

On our May 3rd episode, we talked about my adventure moving from the data center to the cloud. My old friend John uh uh he sent me some feedback saying that that's a really good case study for uh highlighting just how little resources you need. Um it turns out uh most people think they want the most powerful server they can get, but you really don't need that. Uh and as I showed in that episode, I'm using a very small uh server with very low RAM to run lots of Docker containers, and it's performing really quite well.

Wolf: 2:10

Um we also got a little bit of feedback um in person uh on our pass keys episode. Our good friend Ron pointed out that um he's been he's been using a password manager, uh, in particular one password, but right now for every password manager that we looked at, there is no import or export of pass keys. Um that is a thing they are working on. It doesn't look like it's vendor lock-in. It looks like um the passkey people are trying to uh f come up with a uh standard for how that's going to happen. Um there was one other thing I wanted to mention, not on pass keys, but on crypto, uh, and that is um our very paranoid friend, and and I'm paranoid too, so I respect this. Our very paranoid friend Ron uh took my uh thoughts that you don't want to have a wallet managed by a broker with a ton of crypto in it, and he said, Well, what about where you have two wallets, one you manage yourself, and that's where you really keep all your money, and one that you keep on the brokerage so that you can do exchanges and you just move the money just in time. So that was another thing that was pointed out. Um that's our feedback.

SPEAKER_01: 3:43

Yeah, that that that idea of two accounts, that's I mean, that's how a lot of people do it with a normal bank, moving money uh between accounts so that if somebody hacks into your your uh uh your checking account, they can't take all your money. Yeah. They only can take what what you put there.

Wolf: 4:03

Uh doesn't work that way for me because my checking account doesn't have very much money. Um so let's actually get into this episode. I'm gonna hand it over to Jim. He did all the research this time. Uh Jim, start us up.

SPEAKER_01: 4:20

Yeah, I think today's episode is gonna be a little bit different, maybe more conversational, because uh uh this is just something that I researched and I I talked a lot with Wolf about. Uh so we're just gonna sort of lay out what we learned. Um years and years ago, I played with assembly language. I I uh I did some x86. Uh if you remember back in the days of MS DOS, I I was writing um um TSRs, the Terminate and Stay Residence programs that you'd run in a in a DOS environment that would run kind of in the background, although DOS was not a uh multi multi-threaded uh environment. Um but I'd write uh little service interrupts that would run when an interrupt happens, like a clock tick or a keyboard or something, it would fire off this little bit of assembly code. Um I also did some uh 6502 and 6510 assembly. Uh you know, of course, I I started like a lot of people with uh a Commodore VIC-20 and then moved up to a Commodore 64, and those are the processes, processors that those computers used. And I played a lot with uh writing assembly language code on those. Sort of cut my teeth on that. And then as I moved into the professional world, I did some assembly language on a TMS 9900 chip, and that was the text instruments, that's what they put in their business systems. I think they also put them in their their little uh home microcomputers too. But I I uh I was writing COBOL code back then, and we need to we needed to run some things faster. Like COBOL didn't have a sort verb just for sorting arrays, so I wrote something in assembly language to sort an array. Um and we would call that from COBOL, we would call out to the assembly language routine, and it was much, much faster than trying to do trying to implement it just in COBOL, or or the COBOL way was to write it out to a file and then sort that file, which was kind of silly. Anyway, I I I do have some assembly language uh experience, and Wolf, I think you said you you dabbled in assembly language as well.

Wolf: 6:24

I have um I've written assembly language for the 68,000 um for the x86, of course. Um uh I'm trying to remember what else. I keep meaning oh, the PowerPC. I wrote wrote code for that. Uh I keep meaning to write stuff um that runs on an ARM chip. I'm particularly interested in the the M chips from Apple. That would be interesting to me, and I just never seem to get around to it.

SPEAKER_01: 6:56

Cool. Well, the reason why I'm talking about assembly language is uh at one of our one of our lunches several weeks ago, I I had seen an article that somebody had implemented Postgres in WebAssembly. And I what is that? I I'd heard of WASM, I've heard of WebAssembly, but I wow, somebody's doing Postgres in that? That's that's pretty neat. Uh so I thought that might be an interesting thing to dive into and learn about. And WebAssembly, um, or or it's pronounced WASM, W-A-S-M. It's it's kind of like JavaScript, yet not at all like JavaScript. Uh, it runs in the browser, uh, although it can run server-side in like node if you want it. Um, but it's uh it's it's uh it's very much assembly language like. It's got an instruction set. Uh, you know, when you write assembly language, you write it for a particular CPU, usually. Uh you might write assembly language for an x86 or uh or a 6502. Well, you can write assembly language for WASM and uh WASM. Um it there's an instruction set. Uh it's uh there's a stack-based uh virtual machine that runs and interprets that uh assembly language code.

Wolf: 8:20

Wait, wait, can I ask you a question? Yeah, yeah, yeah, yeah. Um so I I know some of the things you were doing to research this, and I have some knowledge of WASM, uh, but suddenly it occurs to me, do you actually can a person actually write WASM? Can you sit down in your editor and type the instructions in and have it run?

SPEAKER_01: 8:46

Yes, absolutely. There are uh tools to to let you do that. So for you to type it and and assemble it into a binary file that's that's uh consumable by the browser. So yeah, you certainly can. It wasn't it wasn't written to be human writable and human readable, although you can write it. It's really meant to be translated from another language, like C or C ⁇ .

Wolf: 9:13

I feel like um this is a lot in this is a lot like Postscript.

SPEAKER_01: 9:21

Yeah, kind of. Postscript is uh is a stack-based language. Uh I I I've written a fair amount of PostScript in my time, and it's uh it's not exactly human, it's not exactly intended for a human to to write or read, but it's sort do certainly doable. So yeah. Um the the the benefit of using WebAssembly though is it executes much faster. Uh it's at near native speeds in the browser, faster than than JavaScript, certainly. Um it's uh it's an attempt to uh to to for you to write code that needs to perform well in the browser, uh where you might not be happy with uh the performance of JavaScript. Um so in my in my digging into this, I I looked at all kinds of things. And and uh first off, uh where did it come from? Um it was written by uh initially created by uh the World Wide Web Consortium, uh W3C. It was a successor to something called ASM.js, which was like a subset of JavaScript, uh intended to be fast, um, but it wasn't a standard. Uh so Wasm was was kind of uh created as a standard way to write fast code for a browser. Uh it's first uh the the first public announcement was in June of 2015. So we're at like, I mean, next month we're gonna be at uh at 10 years. Um actually when this when this episode comes out, it'll be 10 years since uh WASM was was uh initially announced. Um the first viable product, the minimum viable product, uh what came out in 2017. Uh and at that time in September of 2017, it came out on Safari, that was Safari 11 uh for Apple people, and November 2017, all major browsers uh supported it. Um so it's you know it's it's been out there for real use uh for eight years now. Um the the people in charge, W3C is still in charge of it, but also uh Mozilla, Microsoft, Google, and Apple are all working uh on this, uh helping develop it, uh, help helping to keep it going. So it's got a lot of support from from the big players. It's it's an important piece of technology, I think. Um that that that these big companies are are behind. So I think that's good.

Wolf: 12:01

Um why exactly I'm trying to figure out what the place of Wasm is in in the world. I mean, people are usually using their browser, that's sort of the center of user interaction with stuff that exists today, uh, or else they're on their phone and they're using an app that does the exact same thing. But my question is um what does WASM do uh in this world? Where does it fit? Where does it come from? Um tell me more about the performance. Why is it better? Uh does it follow the same rules as JavaScript? Um fill me in.

SPEAKER_01: 12:46

Well, it's uh uh yeah, the the I think the primary goal is it's faster, faster than JavaScript. Uh I I think that gap might be shrinking a little bit as JavaScript uh is is continually uh uh getting better with their just-in-time compilers and and stuff. But wasm is still quite a bit faster than JavaScript. Uh it follows all the same rules. It runs in a sandboxed environment within the browser, so it doesn't by default have access to any local resources. You can't you can't uh uh send a WASM program to somebody's browser that has that could access their hard drive uh or anything else in their computer unless that person gives it explicit permission to do that.

Wolf: 13:34

Um let me ask you, uh I I just absolutely don't know the answer to this. Um does WASM see the same things that JavaScript can see? Does it have an interface to the DOM? Can it can it m do things to your web page?

SPEAKER_01: 13:54

Uh WASM doesn't have direct uh access to the DOM. It goes through JavaScript to get that. There's a real nice interface between WASM and JavaScript. Uh WASM can call JavaScript routines and JavaScript can call Wasm. So it's a it's a nice back and forth thing. Uh so getting to the DOM, um you go through the the JavaScript layer to do it. Uh I I don't think that's where the performance uh benefit happens. Uh I think the the performance is more on just the raw uh uh processing of data. Um you know maybe you've got um some uh encryption uh uh routines you want to run. Maybe you want to encrypt data. Uh uh you could write that code in in C, compile it onto Wasm, and then run that in the browser. Um I think that would run much faster than a JavaScript implementation of that code would. Uh yeah. When it comes to accessing the DOM, yeah, you'd go through JavaScript to do that.

Wolf: 15:00

It sounds like um since WASM and JavaScript can talk to each other, um, they must, I know there's sandboxes involved. It must be that the the WASM in question and the JavaScript in question, they they must be together in the same sandbox. Uh is that right?

SPEAKER_01: 15:21

I I believe they are. I think when you when you fire up a web page that that includes Wasm, I think it it naturally uh includes JavaScript as well. And I think it's the JavaScript that invokes the Wasm routines. So I think they're both running in the same uh security context, uh the same sandbox at that point. That's how you you can play back and forth.

Wolf: 15:44

So I know that there's not predefined hunks of WASM um that come from the browser itself. Um I I I know they come down uh along with the web page and the JavaScript for that that page. They're another resource that the client is reaching out for. Um is that some kind of file? Like a like there's.js files. What does a how where does WASM come from on the server?

SPEAKER_01: 16:18

Well, it it it's served up by the server with uh with a uh a mime type, I think of application slash wasm. Like normally you would you would have uh um what do you have application slash JavaScript? Uh what is the mime type for JavaScript or or uh or text slash JavaScript? Um just like you'd have text slash HTML. Um wasm comes the same way as a as a stream of data. It is a binary stream. It's it's it's uh I don't know if it's compressed, but it's certainly compiled down the binary. Um when you're developing, it includes all kinds of uh uh simple tables and and map source maps and stuff. So it's it can be fairly large. But so it has source maps.

Wolf: 17:06

Source maps means that you can use a debugger.

SPEAKER_01: 17:10

Yes, yes. In fact, uh both Chrome and Firefox, uh the debuggers in those browsers uh can debug Wasm code. And what I saw, I I didn't look into the Firefox debugger, but the the Chrome debugger, you can debug at the original source code level. So if you wrote your program in C, compiled it to WASM, included the source maps, which I think they're there by default, uh, unless you strip them, uh when that code gets down to the browser, you can be debugging your JavaScript code, and then when you call into a a WASM function, you can be looking at it uh at the C code, and then there's a mode where you can actually drop down to the individual uh assembly instructions, the WASM assembly. Uh, you can debug at all those levels in the Chrome uh debugger, and I think you can do that uh as well in the Firefox debugger.

Wolf: 18:07

I love the JavaScript debuggers in both of those. Um yeah, yeah, they're both fantastic. I I bet the WASM debugger is just as good, I'm hoping. But you said compiled from C down to WASM. So that makes me want to ask if you can compile C down to WASM, what else?

SPEAKER_01: 18:33

Well, the the the big players are the C, C, and Rust. Uh they're the those three are very, very well supported. Uh and there's a lot of code out there that has been compiled down to Wasm. But there's a lot of other languages uh as well. Um C sharp is is fairly well supported. Swift, you can write Swift code. If you're an Apple developer, you can write Swift code, compile that to Wasm. Go uh is very well supported. Uh uh Google is is doing a lot of Go stuff, and uh they can compile that down to Wasm. And there's many, many more languages. Uh there's there's some support for for uh uh Python and uh you can compile JavaScript down to Wasm. Uh some of the languages are very well supported, some of them a little less well supported. Uh those are ongoing projects uh with an aim to make it better. Uh I'm including a link to a page that shows the various uh languages and the things that they support. Uh that link will be in the show notes. Um this podcast.

Wolf: 19:43

In my day job, uh I write a lot of Python. I happen to really enjoy writing Python. Um and uh I participate in the community and I see people talking, and one of the things they say is, oh yeah, you You can download uh you can compile CPython, the Python interpreter, you can compile that down to WASM, send it down the pipe to the client, and then you can write Python programs that run in your browser. Um that's interesting to me. These things seem huge. Like how much how much data is going down the pipe? How big is a Hunk of WASM? And why wouldn't uh I mean I guess this is political, but um it seems like there's a couple of things that would be awesome if they were already in WASM and already in the client and didn't need to come down the pipe. Um I think earlier we were talking about SQ Lite. Um that seems like a great thing to have locally that uh that your JavaScript andor WASM code can access. Uh so how big are these things? How do they get down? Where do they live? How come the browsers won't include some?

SPEAKER_01: 21:11

Well, there's a lot of questions there. Uh why don't the browsers include them? Uh you open up that door, you know, it's a Pandora's box. You you open up that door, and pretty soon the people are going to expect the browser to include everything. I I think there's a case to be made that let's keep the browsers small uh and and download the pieces you need when you need them. Um you know, if you compile a small uh hello world uh uh program in C, it's it's a couple of K, you know, a couple thousand bytes, I think, by the time you you compile it and link it and convert it into WASM and all that stuff and set it down. So that's just a few K. That's not a big deal. But uh you know, you can get up into many, many megabytes uh worth of payload. The Wasm code comes down just as though it were uh another JavaScript module. It's it's just uh it's a binary stream that the that the server sends. You know, the browser requests it, the server sends it and it loads it into memory and and starts executing the code. Um I I I you know some of these big things. Uh you know, SQL Lite, I think is not that big. Uh there is a what looks like a fully supported SQL Lite implementation on the SQLite.org website. Um the original article that I read was about running Postgres as a WASM module. That's probably much larger. Postgres is a is a is a much larger project project. I I don't know in terms of megabytes or even gigabytes how big that would be. Um I but I was uh it wouldn't be it It wouldn't surprise me if if uh the some of these things are tens of megabytes in size.

Wolf: 23:00

I um I as a Python user uh a thing I sometimes do is use Jupyter notebooks or Jupyter Lab, whatever. Um and that's when you use that almost always you're separately running a server. Um it might be on the machine you're on or it might be uh across the internet somewhere, but you connect to it and it does the real work. A thing that people have been talking about um is called Jupyter Lite, and JupyterLite is a hunk of WASM that you download to your machine and suddenly in the client, in your browser, with no connection other than where you got the WASM from, you are running a Jupyter Notebook. Um and I looked it up. Uh JupyterLite is about eight megabytes. Um and Jupyter uses Python, so that must include a Python interpreter, I would think. I don't know that for sure. Um what do you think? Is eight megabytes big? Is that a little tell me more.

SPEAKER_01: 24:13

To me, eight eight megabytes is not that big. I I you know I I write a lot of JavaScript, and I try to keep my JavaScript down um into the hundreds of K size, uh certainly less than than half a megabyte. Um but I don't think it's unusual for uh for somebody to download eight megabytes of of Wasm. And I think it's you know, in in in today's uh uh broadband, uh I don't think it's that big a deal to pull down something of that size.

Wolf: 24:44

It's kind of breaking my heart to hear you say that. Yeah. Because I want things to be small and fast. But uh it is.

SPEAKER_01: 24:53

Yeah. Well, you know, uh that initial download will uh uh uh if it improves the performance while you use the app, if it's something you're gonna download, use real quick, and throw away, eight megabytes is huge. But if it's a if it's a large app um that that's gonna be long running, um it's not that big a deal.

Wolf: 25:15

That's sort of a thing they say about uh various different uh algorithms in computer science. Usually it's got a big O and some some kind of expression, but almost always it starts with capital C plus that thing. There's always some kind of constant setup time. And often in the complicated things, C is big. Um so I'm just sort of relating it to a thing I'm more familiar with, but it sounds like with WASM, C is big. So you want to make sure you're only using it to solve problems that are big.

SPEAKER_01: 25:57

Well, sure, but there are there are plenty of small things you might want to do. Let's say you want to you want to encrypt things in in your browser. You might have uh some text or something that you want to encrypt before you send it. Uh you could write that encryption code in in C, compile it into WASM, and and that could be potentially pretty small. You know, if that was 40 or 50k, that's not a big deal. Uh it can do really big things very quickly in a small footprint. So I like what you're saying.

Wolf: 26:32

I do have one off-topic point about what you're saying, which is um this is a good example, but in your example, you have ordinary programmers writing their own encryption. Um totally off-topic. I think that's a bad idea.

SPEAKER_01: 26:53

Sure, but you could take a standard implementation of uh uh some encryption. Maybe you're calling uh an encryption library, um, and you can compile and link that and send it in uh convert it into Wasm and send it to the browser. You didn't have to write that encryption code. That encryption code might have been written by somebody else, might be a library.

Wolf: 27:13

That sounds much better to me. Thank you.

SPEAKER_01: 27:16

Yeah, yeah. You get the idea. The code doesn't have to be big to do important things. Uh and and if it's if it's compute intensive, I think WASM makes a a a great uh case for for itself by doing that. Um there are an awful lot of people using WASM. It really surprised me when I started looking into it. I thought it was a a very obscure thing that maybe a research kind of a thing, but it turns out uh Google's using it in maps, uh in translate, in Google Docs. Those are all used in Wasm. Microsoft's using it in Visual Code. Uh I think VS Code that runs in um Electron, is that right?

Wolf: 27:58

That is right.

SPEAKER_01: 27:59

And and that's a that's kind of a browser type thing. Uh that's using Wasm. Um I I won't say the entire the entirety of uh VS Code is written in Wasm, but there are pieces of it that are written in WASM. I think that's pretty neat. Um Visa is using it, uh the credit card people, uh to make more secure and reliable payment processing systems. Uh Tesla is using it uh in some of the safety critical code for for controlling things like brakes and steering. I'm not sure I'm crazy about that, but I'm I'm not wanting a Tesla.

Wolf: 28:36

Thanks.

SPEAKER_01: 28:36

No, no, no. Um uh a lot of players. Spotify is using it, Amazon is using it, uh, Netflix is using it in their in their web interface. Uh if you're a gamer and you're running some of these games that are that come across the web, uh Unity and Roblox are uh those game engines are using Wasm. Pinterest is using it. Um it amazes me the the the people that are that are doing this. Uh so it's out there. And it's and it's been out there for for years. I I think it's pretty neat. Um uh there's a lot of tools. When I when I started into this, it's like, how do I you know how do I how do I write my hello world program um and and run it? Uh well it turns out there's a there's a project called M Scriptin. It's E M-S-C-R-I-P-T-E-N. Uh and there's a link to it in the show notes. Um and it's uh it's the the compiler, the the tool that you use to take your C program or your Rust program and convert it into uh WASM. Um it it works with uh Clang and LLVM. And if you think about it, it's really kind of like a kind of like a uh it wasm is just another instruction set. So if your language if your compiler can compile down to down to um x86 or down to ARM, uh well inscript and allows it to compile down to Wasm. Uh so if you think about that, it just think about WASM as though it's another CPU.

Wolf: 30:14

I'm not a hundred percent sure um how this arrangement works. Like, I can't imagine that these WASM guys have written a Rust compiler. It's got to be your Rust compiler that you already have. Where does NScripton fit into that?

SPEAKER_01: 30:33

I think it's it's just the part that spits out the the the uh uh machine dependent part. The uh the the CPU instructions, I think, come out of an M script, and I think I I haven't actually done the Rust part of it. I'm not a Rust developer uh like you are uh you are working to be. Uh I've only done the the C uh stuff, and somewhere in that toolchain uh it it parses your C code and turns it into WASM code. Uh I think there's several layers of of that happening.

Wolf: 31:11

I see. Um I know in C you might be using Clang and LLVM and whatever. Those allow you to stick in backends to generate the right thing. Um that makes sense to me. Uh I don't know enough about Rust to know if it does the same thing.

SPEAKER_01: 31:32

Well, Rust is available for a lot of different CPUs, so I think I think that mechanism exists. Um it would make sense that it does. Uh anyway, I know for sure you can compile Rust into Wasm. Uh and there's tools to do that. Um I uh when I when I looked at the uh uh EMCC is the name of the command you use within the M script and project. Uh EMCC has a ton of options. Just there's there's got to be 200 options you can specify. Uh different uh mallocks that you want to use, different memory models, different all kinds of stuff. Um and what I stumbled upon though was uh WASM by default is 32-bit. Uh you know, you think about uh languages these days and CPUs these days, 64-bit has kind of become the norm. But by default, WASM compiles down to 32-bit, which means the memory pointers are 32-bit, the integers are 32-bit. Um, but there is a simple option to run WASM 64 uh to generate 64-bit code. Um it would make sense to me that that it would be faster, although bigger, right? Yeah, you your integers are twice as long, your pointers are twice as long. Um so it could be that that 32-bit is just fine for most everything. Um but the choice is there. You you can do that. Um there's another really neat toolkit. Um uh it's pronounced Wabbit, it's W-A-B-T. It's the WebAssembly Binary Toolkit. That gives you a whole bunch of tools. For instance, when I compile my hello world program uh written in C down to WASM, it produces a binary uh.wasm file. I can use uh Webit to convert that binary file into a text file. Basically it converts uh WASM format to WAT format, that's WebAssembly Text format. And then I can read the assembly code. And it's a lot like uh the assembly languages that I've used in the past. Um uh you can look at it and and play with it. And you can also write this is the tool you would use if you want to write WebAssembly by hand and then uh convert it to uh a.wasm file. You would use the Webit toolkit.

Wolf: 34:08

Now I have another question. Um I'm as I said before, paranoid. And uh a thing about having software that runs on the client and works together with the server is that attackers can be running the client and they can, for instance, in the case of JavaScript, um, they can see the JavaScript right there. It's one of the things they downloaded. They m they can tell what it does, they can modify it to make it do new things. Um and so a lot of things that happen, uh if they need to be uh not influenced by the client have to happen on the server to make sure attackers don't get any uh input in that way. Um is WASM since it seems easy to take Wasm and disassemble it, is it subject to the same attacks?

SPEAKER_01: 35:11

Well, it it it probably is, although you would have to get that WASM code out of the web page and into a file. And I think if you just do uh you know your browser has a show source mode, uh you wouldn't see it. I think you would actually have to fetch that WASM code from the server. I I imagine you could do it using curl or or um wget or something to to get your hands on that code. Um but then you would have to if you wanted to do something malicious with it, you would have to modify that code and then figure out a way to get that code back into the browser to execute something. So it's it's uh I'm gonna say there probably is a way to do that, but it's a much higher barrier uh than you know just opening up a debugger and looking at the JavaScript code and manipulating it. It it's it's quite a bit more work than that. It wouldn't surprise me if it's impossible to do what you're thinking.

Wolf: 36:10

I think.

SPEAKER_01: 36:12

But yeah, I think I think WASM is gonna turn out to be much more secure in that regard. Um I I don't know if they're doing code signing. I would hope that there's a provision for you to do code signing uh of of your WASM modules. That'd be interesting to look at. Uh I'm not sure if that's there. But um the the what when I installed like in script m m script, and it's kind of hard to say. Uh when I install that, it uh it's just a download from from the web. Uh the Wabbit uh WebAssembly Binary Toolkit. Um you can that's a Git project, a GitHub project, you can you can fetch it that way. Uh it had a few dependencies, so I just ended up uh installing it using Homebrew. Uh I'm on a Mac. So I just used Homebrew to install it. Uh and that was really simple. And immediately I was able to start disassembling Wasm code and and looking at it. So that was that was pretty neat. Um I keep talking about the the one of the real benefits of Wasm is that it performs better than JavaScript. So I did a few simple benchmarks. I I'm not a benchmarking guy, but I uh I took a program that uh that that our friend Dave uh well I I don't want to say that he created the program, he actually used uh I think ChatGPT to to create this program. He's uh he's a sudoku player, and he over the years has written several Sudoku solvers, and he asked ChatGPT to write him a Sudoku solver uh in C. And it's uh it's a real simple program, it just uses the recursive algorithm to to brute force solve a Sudoku puzzle. Um so I played with that a little bit. Uh I ran the C program, uh the C version of it, compiled it and ran C, and I put a loop in there to run a million iterations of this one puzzle. And in C, a million iterations on a M1 Mac uh took 139 seconds. I thought that's pretty fast for you to run a million anything. Uh 139 seconds. Um I wrote almost line for line the same implementation in JavaScript, because they're the those languages are similar enough uh syntax-wise. I I I rewrote it in JavaScript, and that took 619 seconds on the same machine. So 139 seconds at the command line, 619 seconds in JavaScript in the browser. Um when I take that C program and I compile it using Wasm down to uh a dot Wasm file and I run that in the browser, um it was quite a bit faster, and certainly not as fast as the C version, uh, but way faster than the JavaScript version. Uh I tried several different browsers. Um to my surprise, Safari was the fastest browser. It ran a million iterations in 158 seconds. So that's uh that's four times faster than the JavaScript version. Um slightly slower than the the C. Yeah uh C was 139 seconds, Safari was 158 seconds, Chrome was 181 seconds, uh and again to my surprise, Firefox was the slowest at 223 seconds. These were all running the exact same WASM code. I just I I served it up from uh M script and Provides a little uh built-in web server, uh EM run that will serve up this code. Uh so I just pointed these three different browsers at it, and uh it really surprised me the JavaScript that Firefox was the slowest one at two or something.

Wolf: 40:17

Can I ask you a question about your benchmarking? Yeah. Um you gave uh the time of 619 seconds for the JavaScript. Um what did you have executing the JavaScript? Was that in one of the browsers or Node.js or where?

SPEAKER_01: 40:36

Uh that was in Chrome. I I did not try JavaScript in the various browsers. Uh that was just running it in Chrome. Um I I uh WASM, it's interesting. You can run WASM on the server in Node.js. Uh and when I ran uh WASM in Node.js, uh the Sudoku solver, 184 seconds. And that's very, very close to the Chrome uh runtime of 181 seconds. And I think it's because Chrome and Node.js are running the same JavaScript engine. So it's not surprising they're that close in performance, at least it doesn't surprise me. Um but yeah, uh WASM is faster uh for my tiny little benchmark. I I'd I'd like to learn more about uh benchmarking and profiling and stuff. And I think I think this sort of uh is gonna lead to another future episode on profiling and benchmarking and performance, uh how to squeak squeak more performance out of your code. I think that's coming up uh sometime in in the next few episodes. Um because we did learn a lot from this, and I and I want to learn a lot more. Um but yeah, uh uh WASM is faster. Well let me faster than than uh than just pure JavaScript.

Wolf: 42:00

Let me ask you uh kind of a final question. Uh what is the takeaway? What are the things you said that people should remember?

SPEAKER_01: 42:14

Well, first and foremost, I'd say if you if you have a compute-intensive part of your application, uh and your application, it's a web-based application, but you've got something that's compute intensive and you want to speed it up, it probably makes sense for you to implement that part of your code in a in a compiled language like C or C or Rust. Uh, compile that down to Wasm and Um and then make that part of your web app so that it downloads that WASM code and executes. That will speed up your program. I think that's the first thing. Uh security and portability, that's one of the things that that the Wasm people say it's more secure. Um I I don't know for sure that it's more secure and more portable than JavaScript, because that's gotten to the point where it's it's pretty secure and portable, other than the thing that Wolf was pointing out about uh you know, within the debugger, you can look at the you can you can poke into the uh the JavaScript and and manipulate it. Uh but Wasm I think is is more secure in that regard. Uh and it's and it's very portable. So that's a uh uh maybe the second point I I wanted to make. Um and almost certainly you're already using using WASM-based applications. If you're using Google Maps and Docs and Netflix and Spotify and Amazon and many, many more, you're you're running WASM code, whether you realize it or not. You won't even notice it's just running in the background. Um so so yeah, I think that's that's kind of my uh my my high-level view of of Wasm. I I learned a lot uh looking at this, and I I I I write web-based apps. I don't write a lot of stuff that's that's really client intensive, so I'm not sure that I'm gonna need to write uh WebAssembly code for for my apps, but just understanding that it's there and that it works, I think it's pretty neat.

Wolf: 44:17

Um so you did this research, and I'm gonna ask a question of you that is um out of band. I I'm just interested. You you came into contact with all this new information. Uh I I want to know what was the most um, I guess I care about surprising or interesting, or what fact uh was a big peak in your in your learning? What what stands out?

SPEAKER_01: 44:49

I I I think the fact that it's it's so widespread used right now by the big players. Um it's out there, it's it's being used. That really surprised me. I I I early on like i in this conversation, I said I thought it was kind of a research thing. Um I I didn't know that it was that that that well used. Uh, I think it's pretty neat. That was a surprise to me.

Wolf: 45:16

Um I think that brings us to the end of this show. I want to thank everybody who's listening. Please tell your friends. Um if you liked it, leave us a review wherever you get your podcasts. If you haven't already subscribed, uh subscription would be great. Uh, as I've already said, we love and value your feedback. Connect with us on Mastodon at runtimearguments at hackyderm.io or send us an email, feedback at runtimearguments.fm. Um I I think we're having a great time. I think I speak for Jim when I say that. Um, but this is great for us. I hope you are getting as much out of it as we are. Thanks for listening. Jim, anything?

SPEAKER_01: 46:08

Uh yeah, thanks for listening. And uh we're we're really enjoying doing this. And the fact that there's there's there's so many people that are that are listening and giving us feedback is just fantastic. Uh I think we would do this if there were one person out there listening. It turns out there's a lot more than one person. So yeah, we're enjoying it. So thank you everybody for listening, and we'll we'll just keep doing this as long as we can.

Wolf: 46:34

And we'll see y'all in the next episode. Bye.