WebAssembly and React: A New Era of High-Performance Web Applications with Ramon Huidobro === [00:00:00] Hello and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it free at logrocket. com. I'm Noel, and today we have Ramon Udobro joining us. He's a keynote speaker, DevRel speaker, egghead. io instructor. Co founder of the bad website club. I'll have to ask some more about that because I'm curious. But he's here for specifically to talk about a talk he gave recently titled web assembly and react a new era of high performance web applications. Welcome to the show. Thank you so much, Noel. I'm so excited. You want to talk about the Bad Website Club as well. It's one of my favorite things that I'm working on. No, it's a joy to be here. And yeah, thank you so much for having me. Oh, of course. Of course. I'm excited to jump in. I feel like this is web assembly in general. I think it's one of those things that's like on a lot of devs is radar, a lot of people's radar, but they're not like interfacing with it much day to day. And [00:01:00] everyone's this is probably coming, probably something I should be thinking about more, but it's not really something I'm worried about at the moment. So I guess, yeah, with that in mind what prompted you to give this talk now? Why do you think people should be thinking about web assembly and react? Tch. More than they are. I'm going to be fully upfront in saying that a lot of that came from personal experience because my approach to new technologies when I hear about one is to be, interested, but also let me see where this goes. Let's see what's going on with it. Let's see if it sticks around. I've been in software engineering for about 14 years now and you see stuff come and go over time and you're like, when stuff strikes you as interesting and I will admit, I'm a bit of like, a nostalgia nerd, so when I found that people were finding ways to Run software that has been around for decades in the browser, , in a new context, in the web and making this more freely available to folks, this is something that immediately piqued my interest. And over the last year and a half, I started working in the WebAssembly space, specifically around the extensibility stage, which we'll get [00:02:00] into, as well, but learning what folks were doing around WebAssembly and how this was evolving in a standard based way, as opposed to having sort of one company lead the charge of a standardization of a technology is something that I have found really compelling. I just find collaboration to be such an important cornerstone that we may be sometimes take for granted in the web development space and software engineering in general. So like seeing something evolve like this is something that. I've just found spectacular. And that's like why I've been, I'll be honest. I would be lying if I said I wasn't being a little bit bombastic with the term new era, but I think that's to be expected. And, a bit doesn't stop it from being in and of itself a new era, because what we're seeing is a new way to run your code that does away with a lot of. Complications, standardizations, and perhaps even difficulties that we've seen in the past, but not in ways we haven't seen before, in terms of like, [00:03:00] I feel like the world is changing from underneath us, and we're just moving along with it in a very positive way. Yeah, I think the web is unique in a lot of those attributes you mentioned where there are several players and there's this kind of, you know, bored getting things done collaboratively, in a way that seems like a net positive for a vast majority of interested parties. totally. I mean, If we look at something like Flash, for example, which was mostly spearheaded by one company, i. e. Adobe, as a web technology, and I'm gonna, at the risk of aging myself a little bit, was a very large component of how I interacted with the web when I was younger. So seeing that go away in favor of having something that's more, as I said, openly approached, is something that I find really compelling. Yeah, totally. Totally. Let's let's try to contextualize this a little bit. For those again, I feel most people have a loose understanding of this, but can we talk history a little bit? Like how did we get into this state where web assembly was the approach that, we wound up taking in the thing that's being pursued as the front runner to solve the [00:04:00] problems that it's trying to solve. absolutely. And, , of course, being able to cover like all of the technical nitty gritty of what goes into WebAssembly itself, what some people have called it is a fourth pillar of the web, right? Where you've got your HTML, your CSS and your JavaScript. And then on the side, you've got your WebAssembly as well. But that's doing both the web and WebAssembly a bit of a disservice because WebAssembly. Is not a programming language WebAssembly is not really something you can just throw up and run code against as you would in a browser, your HTML, your CSS, your JavaScript, the problem that WebAssembly is trying to solve is by making it possible to run code written in other languages. Again, from its inception in your browser, and of course, going back to what we've had in the past before, this isn't the first time that's been attempted. We were talking about Flash earlier, but we've also had stuff like Java Applets. Did you ever run those? Yeah. Yeah. Many moons ago. Yes. Yeah, Which were a way of running [00:05:00] Java apps or Applets in your browser powered by Virtual Machine or JVM. Later on, both Mozilla and the Google native client teams started working on something called ASM dot JS. And that's where the assembly part comes in web assembly, a way to run native or near native byte code. In your browser. So ASMJS, which has now been mostly replaced by WebAssembly, was a standard for, as I said, low level bytecode that is I like to think of it as code that compiles down to \ , like low level JavaScript,, that allowed this code to be run in the browser. Now the thing about JavaScript, and don't get me wrong, I love JavaScript. There are contexts in which JavaScript is not an ideal language for doing, for example, very low level, very efficient, efficiency oriented procedures. One example that comes to mind is image compression. We've got these extremely prolific and very well written Image compression algorithms that we've been running for [00:06:00] decades in order to, for example, transfer images as we are doing, as you and I are recording now sending these video images over the web where JavaScript is not ideal, but being able to run these low level algorithms in your browser, yes, was possible, but not as approachable, but now with web assembly, which, now we can get into what WebAssembly is, which is a standard so that a standard for low level bytecode that you can run in your browser or in other places so that you can take, for example, those existing out image compression algorithms and run them in your browser now. The way this works nowadays, because of like the work that's being done in this, a lot of the work for the standardization of WebAssembly is done in something called the Bytecode Alliance, which is a working group made up of a ton of different entities and companies working together to further along the WebAssembly standard. And they've been making some really interesting strides, even like in the last year, since I've been like working on this. Presentation and content [00:07:00] what it has evolved to is a collaboration so that you can run. This WebAssembly support directly in your browser without having to rely on JavaScript, how do you frame this to devs maybe like when you're explaining it to especially newer web devs who don't have any like preconception of how this kind of fits into the mix? How do you try to build that kind of mental picture of what web assembly really is? right? And this is such a good question because it's something that confounded me at first not because I understood what WebAssembly was but Approaching it as you would a web technology was something that I found a little bit difficult to approach at first because When I said to myself, I'm gonna go and learn WebAssembly wasn't learning low level, I didn't need to learn low level bytecode. I didn't, like I would say, React. I go and understand how the React API works. working with WebAssembly, it's not really that. So when I tell folks, who are interested in what WebAssembly is, what it really is, is a, compilation target. And in order to go into that, we need to talk [00:08:00] about like how code is run. And we've got like , different ways of running code. We think of JavaScript, we think of like it's immediate execution. There's more to it than that, but it's a scripting language, right? It's. Compiled as it's run, but most especially in the olden days, like some of the older programming language were compiled languages, meaning that the code would get translated from this human rate, readable code that we write day to day into byte code. And this byte code is what's then passed on to the operating system. And then by extension, the hardware to run that code. So WebAssembly is that byte code stage that gets passed on to the browser. So it's low level. But it was primarily designed for the browser. So it's just like you would say, compile a program so that it runs on Windows or MacOS or Linux or iOS or Android or watchOS, so too, would you compile your code so that it runs in WebAssembly and by extension, your browser. Yeah. So you've obviously. Spent a lot of [00:09:00] time kind of thinking about this paradigm and, just the mental model of how this should all work, I think maybe web assembly is maybe a little bit unique in that I feel we're not, we don't really talk about like compilation targets or ways in which we can run bytecode normally is devs very often. I'm sure there's a subset of devs who absolutely do like we're very low level devs or like writing compilers and stuff, but I, that's not the norm, there's not, most devs aren't thinking about that. So my question maybe a two part question. One, why do you think WebAssembly is unique in that way? Where us as these higher level air quotes, web devs need to think about it. And two, do you think long term this will manifest as a thing devs have to care about, or , will it be more just, and you can write code in this language and then the things will happen that makes it, able to be run in the browser. Yeah. And there's something that I find really exciting about that in that now I want to be very careful and respectful when I say this, because when I say that WebAssembly will hopefully become [00:10:00] an implementation detail, what I hope happens is that we can understand, for example, just as we would say, debug some very. Low level JavaScript things that we're like, Oh, you know what? This might be like a bug in our browser. So too, do I see it being that down the line, what we'll hope, what we'll see hopefully is as we've seen the browser as a platform and the APIs that it has developed over time become more and more powerful and make our lives as software developers all the better. Or web developers, I should say. So too, I see WebAssembly already going in that direction. The use cases we're already seeing coming out of WebAssembly, some perhaps less obvious, some perhaps more obvious, some, especially as we talk about what happens when we go out of the browser. I find this to be Terribly exciting. And the first I said, perhaps obvious again, I might this might be the nostalgic nerd in me speaking being able to use this, to work on software archival purposes is amazing. One of my favorite examples is archive. [00:11:00] org have. A whole slew of it's not just way back machine. There's so much more to archive. org and one of the things, many things they do is make it possible for you to run a whole variety of old programs in your browser, powered by web assembly. Like the example I should always show my presentation is like an old DOS game called Prince of Persia. Which was one of my favorites from back in the day. The spikes and, yeah. Yeah. Yeah. Exactly. And I'm talking like late 80s Prince of Persia, not early 2000s. But but like the fact that this is running as it would on old hardware, because of that middle level of bytecode that separates the browser and the code itself, as if it had never stopped working. This software archival is going to be super important. We're already seeing this with operating systems as well. Some folks have actually got all of windows 95, from 1995 running in your browser, which is just remarkable. I talked about image compression. Like this is something that there's this the folks at Google [00:12:00] have this project called squoosh, which really let you like see in real time how you can leverage existing image algorithms. It's got like a drag and drop ability for you to apply that. That image compression algorithm in real time, again, in your browser and make this extremely apparent to users. And again, these are like very perhaps not important, but we've actually got like really really hands on approaches that are coming to us as web developers. Now, for example, the folks at StackBlitz who have their online editing software, what they have is an entire Node. js ecosystem running in WebAssembly. So , you're not running JavaScript from your browser and when you're developing and you wouldn't, you've got your little terminal and all that, you're running Node. js in your browser. one of my favorite examples, if I may just highlight one more, is LibreOffice. Which is a open source alternative to say Microsoft Word and that sort of thing. Some folks put all of LibreOffice and put it up on WebAssembly so you can run it [00:13:00] in your browser. Now, mind you, that's 300 megabytes that you have to download before you can run it, but still that is the entire LibreOffice in your browser. And we're already starting, and these are the more experimental parts of it. And, we're seeing like, more sophisticated things coming out of it. Archival image compression. And of course what stack blitz is doing, but then we go into what we see coming out of it, as I said, outside of the browser, because folks took a look at this sort of standard for byte code and they saw it being run on different browsers as if it were just one platform. And they thought to extend this to be outside of the browser. And this is where server side web assembly comes in and the context in which this is going to seem really familiar is with, for example, containerization. Where the objective was as we had these containers at which, over time filled a lot of holes where virtual machines weren't enough. And I'm starting to go a little bit into the DevOps side. I don't want to go too overboard with it. Yeah. No, I think this is an interesting kind of [00:14:00] thread, so let's keep pulling it. Yeah. totally. Yeah, no. What happened was we had this needs as we're, as our, as the software that we, quickly deploy and put out there onto the internet and like to our different networks and all of this, as this became more widespread and we started seeing the need for virtual machines in order to be deploying one chunk of a piece of software just as quickly and ephemerally as possible, that is just put it out there, let it run and do its thing and then shut it down as we need it. But of course. Shipping an entire virtual machine of Linux, which can be something like through a couple of hundred megabytes can get quite chunky. So what the, what a lot of folks, and this is where Docker came in, gave us this concept of containers where you could have these sort of like modularized lego pieces of different parts of a virtual operating system and put those on the web and then swap them out as needed. But even that Has \ it's advantages and drawbacks. So when folks were seeing the fact that we could run these ephemeral web assembly and these binaries, as we would call them, these chunks of binary bytecode, [00:15:00] they're usually called modules. They start, folks started thinking, why don't we also run these in. The server and of course, the big problem with that, especially because of the way WebAssembly was designed was that browsers don't have access to an entire operating system the way a program would, right? anD even like when we're running programs, even our browsers, they don't have full access to a computer's operating systems resources. Usually the, what you need to do is interact with this sort of like layer of the computer called the kernel. Where you say for example, Hey, can I get access to this file real quick? We're seeing this a lot in , modern MacOS when you're like, Oh, this program would like to open this file. Will you want to give it permission? This is like a quicker time thing of what's going on at the operating system level. And so what the folks at the bytecode align came up with was an interface so that you could, Interact with those system resources, and this is called web assembly system interface and this short and [00:16:00] wze for short. And so what we've been seeing is folks creating these teeny tiny web assembly modules, which are really just the s the code that you need, the bike code that you need in order to run a thing so that you can just put it up, run it, and then shut it down and by the way, if you want a much better explanation of how these sort of like an interactions work with an operating system, Lynn Clark has Lynn Clark did the series of blog posts for Mozilla called the illustrated guide to WebAssembly. They are phenomenal. I highly recommend them because they also. It's been interesting to especially after, I didn't finish my bachelor's degree in computer science, but it's been really interesting to see \, these concepts come back in a way where I can appreciate them and perhaps do my part in like understanding how this works and furthering that standard as well. Yeah. So this feels like we're introducing a new abstraction, just in our stack in general, and that we have this standardized compilation target. So [00:17:00] regardless of like source language, everything, okay, as long as we can get it compiled to web assembly and run it, this will work. Is this paradigm totally. Totally new. Are there it feels like this would have been a realization we'd have come to sooner. As just, the software community at large, if there were such high utility in this, because again, it seems obvious oh what if every machine could just run everything we could write it at this higher level? Why do we now need this, like higher abstraction where you don't feel like the demand was there before? I don't know. I would actually say that we always had this need and we've always been working towards it. I would call what we've seen with WebAssembly. Not so much a, , this is the new thing. Stop everything you're doing and use it. It's more like this is the next step in a series of steps we've been taking towards making. Not just the web, as said, but also running software as ubiquitous as possible. So for example, as we went from, say, because I don't know, I seem to remember, [00:18:00] I know we still have ways in which we do this, but I like to think of like back in the day of how we we had different ways of writing JavaScript without writing JavaScript because we didn't like writing JavaScript back in the day. I came from the world of CoffeeScript. Yeah I think so in the same way, are we seeing ourselves going into okay, we've got like our standard for JavaScript, that sort of web platform is continuing to evolve. So too, are we seeing this sort of running of platform, especially running of software, especially this very ephemeral sense, these very small modules that you just put up, run, and then shut down, it's not too different from, like I was saying, with containers. In terms of concept, same goes for virtual machines. Same goes for, having a bare metal server that would run, your GeoCities website or something. It's not probably all GeoCities, but like your older website. And the way this works. And of course, in order to avoid these sort of like complications across platforms, what we have is. An extra layer, as you very well put it, to run this WebAssembly [00:19:00] code in these different contexts. And this is called a runtime, right? So a runtime is a program that sits in your stack, whose purpose is to take that bytecode, and run it on your system. Which We've got runtimes all over the place. Our browsers have a JavaScript runtime. Node. js has its own runtime, the V8 if I'm not mistaken. And the same goes for our servers runtimes and so on and so forth. So this sits as a middle ground where It takes that bytecode and I think the big difference here is that instead of we're skipping a step of turning that code into machine code and instead turning that code into bytecode, which we can then distribute as an, a binary chunk and then run that on different places. I think that makes sense. , I think it's hard not to turn the conversation to the future then, because it feels like if we have this additional runtime, it's, it seems like this is solving the same problem that JavaScript is solving. This seems like there's no JavaScript has no unique problem. [00:20:00] It's solving anymore. well, I know the answer to this question, but I think for the purposes that like academically it's interesting to discuss why in the future would all JavaScript not just be compiled to WebAssembly as well? What, why would we ever need to run times in the browser? that's an excellent question. First of all, as of this year, we're actually already starting to see steps being taken towards running JavaScript in WebAssembly. a runtime for that is being developed by the folks at Shopify and with collaboration with some other Bytecode Alliance folks. But the whole purpose of and we need to make this distinction between, the browser and the server, right? Because as you correctly said, the vast majority of the code that we're running in the browser is of course, that JavaScript is that JavaScript runtime, that's not going to go away for purposes of low level code, or, lIke either simulation emulation,, running these low level tasks that were perhaps the JavaScript engine is not suitable, not because it's bad, but because [00:21:00] it's just not meant for that. This is where in the browser, something like a WebAssembly runtime, which to be super clear, nothing to do with WebAssembly, the WASI standard. The WASI is more meant for the server, although, because we're all nerds and we love it, there is a polyfill for running WASI in the browser, but that's not what we're here to talk about. But beyond that especially with with WASI there and WebAssembly in general, there are considerations to be taken, especially when running against user provided code, which we can get into in a bit, where we can, Give flexibility to software developers to really go a step further in how they can, not only, for example, write code in a polyglot nature. That is, you want to bring your code in Ruby and run it in the browser? No problem. You want to bring your Rust code? No problem. So on and so forth. Now, of course, Not going too far into the where there'd be a need for other programming languages. I don't know. But my point is being able to take, especially like this user [00:22:00] provided code and being able to run it in your browser is going to be, or your server, which we'll get into in a bit, is going to be super, super handy. Security is something that's also being thought of from day one with WebAssembly in terms of having and being capability based that is. The equivalent I like to think of because I used to be a macOS developer is sandboxing, right? And this works with the browser too, where, all of the stuff you do is limited to this sandbox, this area of access that you have as a program is running. The way that WebAssembly works is that a module needs to tell the system interface from the start, Hey, I want to have access to this file. Hey, I want to be able to connect to a network. Hey, I want to be able to, I don't know, print a file to a printer, right? Being able to limit it to that at the start and not have it do anything in case there's any kind of like supply chain security vulnerabilities. This is going to be greatly mitigated with WebAssembly, because these modules are really limited to the bytecode of the [00:23:00] program that they are, these modules turn out to be small, they're typed, and provisionable, which means you can just use them and scale them as you like. Again, this is thinking more in the server side aspect of things, and because it is near native, we're talking speed here. how are those performance gains typically realized server side? me, the biggest one is going to be start up and shut down, because you're running a module instead of an entire container and or operating or virtual machine, really start up, shut down, done. Like this is where we can really take this nature of ephemerability. That is, you know, you run it like in a stateless fashion and then shut it down, scale it accordingly. This is where this sort of thing is going to be super fast, like super fast. And it's not just in terms of performance. It's also in my opinion, in terms of a software development cycle. Instead of having to worry about which version of Linux you need to spin up your insert metaphor for server here by your [00:24:00] provider. No need to worry about what version you have. You just need to make sure you've got that WebAssembly runtime. Which I anticipate folks are going to start providing this down the line. Same goes for scaling and common security vectors like this speed is going to be greatly noticed. And because we are seeing this again, near native code just run on an instance, we're seeing that, especially in the browser, these algorithms that were really meant for being run as low level and as resource efficient as possible are being run. As if they were on bare metal, that is on an on hardware. I'm curious back on the server side. And I'm thinking of just how most devs, not maybe not most, but a lot of devs are writing code now where they have, they're just like clicking a deploy button against some functions as a service or something, CloudFlare, whatever AWS is Lambdas or GCP functions, you name it. But they're really just selecting a given. Language right now, and they're letting the provider do all the rest of the thing, right? Like they're usually not having to do much configuration beyond that. Do you think that would [00:25:00] change here? Or will the developers still just essentially be, pushing their node or python or ruby code or whatever? But then the these providers will say, okay we're actually going to, compile. WebAssembly and have this run as WebAssembly on this box. And this is the part that I'm so excited about because this is where it becomes an implementation detail. What we're going to see, especially as we do our functions as a service or, for example, folks like Figma, what they're doing, which I find really exciting is that they have an extension platform, an extension API that you can write your code against, compiles web assembly. And it's just, it's up there. It's being used. Like you don't need to worry about any kind of like runtime or security, especially as a provider, we're seeing the possibility for you to be able to provide your users. The ability to write functions against your code and you don't need to worry about like resource hogging. You don't need to worry about like runtime security, any asset security um, security vectors. Like we're just like letting folks [00:26:00] being able to write their code because, don't forget, it's not just folks who are writing the code that runs against your service. It's also you being able to now have the ability to let folks run code against your service. and this is where you see folks like Fermion. what the folks at Fermion are now doing is giving folks the resources to be, and the tooling to be able to build full scale web applications. In WebAssembly and just deploy that as a module that you just plop somewhere because we're seeing the ability for folks to be able to deploy their services into, say, a Kubernetes cluster, just like that, that is deploying them into a network and have them run again in this ephemeral fashion, and then shut down, what we're seeing is that really, it becomes an implementation detail, where all of these sort of security concerns are taken care of all of the speed concerns, all of the scaling concerns are taken care of. But as said, I find it so exciting that now beyond these providers, these giant folks as you said, Fastly and CloudFlare and SecondState and, the CNCF, the Cloud Native Computing Foundation, [00:27:00] now we're getting the ability with being able to run modules like this to even provide our own extensibility to our day to day web applications and letting these run as said, either in the browser or even. In a server against our application and knowing that this is going to be secure by default. We've talked about this full web stack paradigm a little bit more here and how this will impact it. Do you think a lot of the tooling is going to change or, like how these kind of meta frameworks interact with like a. Code base. Do you think there's going to be changes in the paradigms? Say you're starting a new react project in the future and you want to include some web assembly. Do you think that we're going to have like new kind of standards or new templates? Or just the way that these frameworks that are doing like, inspect this code and do the deployment step, right? Figure that out. Do you think that's going to change quite a bit as WebAssembly becomes more ubiquitous? I think so, because I think we're already seeing it happen. For example, I have to admit, I hadn't worked with it much before that, [00:28:00] but once I stepped into for example, Vercel's , API providing for next JS apps, and If you set it up in the, in, if you set it up correctly, you can actually just very quickly start running , these functions in a WebAssembly provider context. So ideally, what's probably going to happen is that we won't be able to tell much of a difference in a day to day front end aspect of it, but because these tools are going to become more available to us at a. I'm going to air quote this for folks listening full stack context, being able to declare and modularize our coach that it runs on the server, knowing that it's fast, secure, and. provisionable, I think we're going to see , a lot more overstepping that we've already been seeing over the last couple of years. And as this becomes more and more ubiquitous, as we can bring in more and more, for example, third party libraries in from other programming languages into our day to day, like this sort of Squoosh [00:29:00] experiment with the image compression, I see as like a first step towards making this more available. And you can actually already start playing with it.. There's a lot of like providers and tutorials that make us sort of a, like first steps in integrating WebAssembly into your react application. What you're going to be able to tell is that most of the time you're just importing a piece of functionality or a function from a WebAssembly module and calling it like you would any other function in your day to day JavaScript, I do you think devs will be running these You know, we're running a WebAssembly, like a server side WebAssembly runtime, a client side runtime and like, full traditional normal stack as well when they're running, like doing their local dev set up and it'll just all just be transparently happening for them. think. So , in several ways, actually one step that happened a year ago which a lot of folks were like. Some folks didn't think this would happen. Docker announced the ability to run WebAssembly , in this sort of container fashion, so [00:30:00] it is not impossible that just like we're running containers, , we'll now set up and run our. WebAssembly modules in Docker, but one thing is to be super clear about all that. It's just just like containers didn't replace virtual machines, containers only filled in the gaps where virtual machines were insufficient. I think we're seeing that also happen for. WebAssembly and containers. Containers are not going to go away. They're just going to fill in the gaps where containers are perhaps not fully suitable. And so what we're going to see probably, and as I said, I think it's really interesting to see what the folks at Fermion are doing with their spin framework, is seeing that all come together into sort of like, One chunk and the thing is especially when it comes to conversations like this, it's like the question becomes okay, but this is very fun to geek out about, but is this production ready? And what I've been trying to get during this conversation and with this presentation in general as well, is that, folks are already using it. Don't get me wrong, there's still a lot coming to WebAssembly and some stuff that's going to be super exciting. One that's been currently at work is something called a component [00:31:00] model, where this modularization of WebAssembly and the linking between WebAssembly modules, and by linking I mean having one being able to interface with another module. I'll give you an example. Running Python right now requires taking the entire Python runtime and plopping it with the code into a WebAssembly module, which kind of sounds like a container, doesn't it? But what folks are working on is now the ability to have, okay, one module for the Python runtime and one module for your Python code and having those interact. Gotcha. So then presumably you don't need multiple modules that are the Python runtime at exactly. Exactly. We're going to see that. We're going to see the folks are working on a standard , for WASI neural networking. I'm not super knowledgeable on machine learning stuff, but I know the power of WebAssembly and machine learning, probably going to be extremely powerful. Actually, I think it was last week or the week prior that they Just brought out like the first final standard of garbage collection in web assembly, [00:32:00] garbage collection being like, memory management. One thing we take for granted in JavaScript sometimes is that when we declare a variable and then we don't use it anymore, what we're seeing happen is that it gets some memory allocated to it and then put away, not the case in web assembly, but not for long. And even multi threading is coming to web assembly. So yeah, , this is work in progress, but what I'm trying to advocate for here is that we already have this running in practice and it's just going to get better. It's very exciting. Is there anything in particular that you'd implore devs to keep an eye on and look towards to to see what's coming down? Yeah, definitely. I said the Docker web assembly support is still relatively new. It isn't beta, but I think keeping an eye on that is going to be super exciting, keeping an eye on what some of the other folks working in the bike I think keeping an eye on the bytecode Alliance in particular is going to be super interesting because once we can start doing things like running neural networks in our browser or on the server in this ephemeral, self contained fashion, folks are even now doing IOT, internet of things like [00:33:00] running web assembly on hardware, which if we know anything about hardware, is that taking away that capability based security vector taking away the supply chain security issues is going to be great for IOT. Yeah. So As developers, what I think what we have to look forward to is making it easier for other folks to run code, making our code as. Approachable and extensible as possible is for me probably going to be one of the most important parts of this moving forward. Yeah. It sounds very very cool to be able to, hand off a binary, able to run it anywhere. It just works like the package ability of software sounds super nice. This is a problem we've been trying to solve in several iterations and we keep getting closer and it keeps getting better. But And, some folks might wonder is WebAssembly the final step? Have we done it? I don't know. I'm not even worried about whether it is the final step. I think that's the wrong question to ask. It's more like, isn't this exciting where we've gotten so far? The future can only be brighter. No, totally. Cool. Cool. I [00:34:00] feel like that's as good as point as any to, leave it to listeners to go explore more on their own. We'll get links to , Lynn Clark's blog posts in the show notes for sure. Yeah. Is there anything else you want to mention, Ramon? the only thing is we didn't talk about the bad website club. Can I just like Oh yeah. Yeah. Plug it. Let's go. Yeah, of course. Awesome. Thank you. It's completely unrelated to what we've been talking about, but it started out as an initiative that my friend Jess and I have been running for a while to run free educational stuff for folks to get started in their, in their programming journeys, but also to mitigate this sense of perfectionism that we sometimes get where we're like I've been working on this project, but it's not really there yet. And it's not really good and I'm not ready for folks to see it. And so like we started this bad website club where we make bad websites and we showcase that it's totally exciting. It's totally fun. I think we've now been teaching like over 35, 000 folks in the last couple of years, which has just been like, I actually, okay, I'm not, I'm going to brag just a tiny bit. If I may, I just got a message the other day that somebody like [00:35:00] from learning JavaScript for me, they got their first job in front and I'm just like, Yeah. hard not to. It's hard not to have that feel like it's, worth so much to be able to like, not just impart that knowledge, but,, make it more approachable and make it more human. And this is something that tying it back to WebAssembly, I think it's just I just wanted this to be more approachable to folks because it's not supposed to be just some sort of Oh, look at this, like low level, highly complicated stuff. It's more like, what cool stuff can I make with the tools that have been developed by folks who've been working on this stuff? And how can I take this further? Yeah, that's my little plug. Awesome. I can't believe I forgot. Yeah. Very cool. We'll get a link in the show notes to bad website club as well. Cool. Thank you so much for coming online and chatting with me, Ramon. It's been a pleasure. Thank you, Noel. This was a joy.