The Changelog: Software Development, Open Source - Code Cartoons, Rust, WebAssembly (Interview)

Episode Date: April 25, 2018

Lin Clark joined the show to talk about Code Cartoons, her work at Mozilla in the emerging technologies group, Rust, Servo, and WebAssembly (aka Wasm), the Rust community's big goal in 2018 for Rust to become a web language (thanks in part to Wasm), passing objects between Rust and JavaScript, Rust libraries depending on JavaScript packages and vice versa, Wasm ES Modules, and Lin's upcoming keynote at Fluent on the parallel future of the browser.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com and we're hosted on Linode servers. Head to Linode.com slash Changelog. This episode is brought to you by Airbrake. Airbrake is full stack, real-time error monitoring. Get real-time error alerts plus all the info you need to fix any error fast. And in this segment, I'm talking to Joe Godfrey, CEO of Airbrake, about why getting to the root cause of errors is so important. Look, Adam, to me, root cause is everything. All software has bugs. We all know that.

And when you find a bug or when you can't find a bug, the amount of time that typically gets spent trying to chase around and figure out how to reproduce the problem a bug, the amount of time that typically gets spent trying to chase around and figure out how to reproduce the problem and what's the cause of the problem, even like what part of the code kicked it off or what sort of actions drive it. I mean, that's hours and hours of time wasted spent chasing your tail instead of actually fixing the problem, improving the customer experience and getting back to building more features, which is really what your company is all about. So to me, being able to really understand like what is the root cause of this problem is the key factor to being able to solve that problem and get back to doing what's most important, which is building new

features and improving your product. And quite frankly, fixing the customer experience is broken as long as that bug is out there. All right. Check out Airbrake at airbrake.io slash changelog. Our list is controlled Airbrake for free for 30 days. Plus, you get 50% off your first three months. Try it free today. Once again, airbrake.io slash changelog. All right, this is the Change Log, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, leaders, and innovators of open source.

I'm Adam Stachowiak, editor-in-chief of ChangeLog. On today's show, we're talking to Lynn Clark, well-known for creating code cartoons. Lynn is able to explain complex topics and concepts in ways everyone can understand. We talked about her process, the concept, the execution, her work at Mozilla in the Emerging Technologies Group, Rust, Servo, WebAssembly, aka Wasm. We discussed the Rust community's big goal in 2018 for Rust to become a web language, thanks in part to Wasm, passing objects between Rust and JavaScript, Rust libraries depending on JavaScript packages and vice versa, Wasm ES modules, and Lynn's upcoming keynote at Fluent on the parallel future of the browser.

Lynn, let's start with Code Cartoons, which is a very cool project. Seems like a multi-year project that you've been doing, maybe not doing anymore. It's some of the questions that we have around it. But this is where you basically are doing educational work by drawing awesome diagrams and cartoons around code. Can you tell us the concept and when you started doing this and why? Sure. Well, the idea behind code cartoons is to take this technology that people sometimes find intimidating and explain it in terms of metaphors that almost anyone can understand. And a lot of people think that because it's like that, and I'm using cartoons and stuff like that,

that it's meant for novice developers, but really it's meant for almost more senior engineers, because I find that a lot of senior engineers sometimes have a hard time saying that they don't understand something, that they don't know what's going on. And if you present it in a very clear way, and in a way that they can relate to quickly, it brings down that concern about, you know, losing face. And so it can make senior engineers more comfortable having these conversations without getting, you know, that kind of bluster of I know what I'm doing. So a lot of these posts are actually meant to help dialogues by reducing people's insecurity around not knowing something. That's interesting, because I realized that kind of without realizing

it for those following along at home, you can go to code-cartoons.com to see some of Lynn's work there. The topics are not novice topics. It's a cartoon guide to Flux, to hot reloading and time travel debugging, to Redux, to really things that are difficult to understand, even for what we call seasoned software engineers. And yeah, you're really kind of bringing them down to a level that somebody, it's like just making them more approachable. And like you said, for people who may be too embarrassed to ask.

I mean, the visual aspect too is a big piece too, because like you can explain things, like you said, in metaphors, like this person exchanges this paper with this person. So you can see the, you know, whatever it is moving from one place to another. And now the state has changed or the responsibility of the state change has changed hands. So you can see that in real visual artifacts that people can relate to because they are in the real 3D world. And I think also giving personalities to the characters that are interacting helps people latch onto it and understand more why something acts in a certain way. So for example, with Redux and Phlox, actually, I

talk about one of the characters being an overbearing bureaucrat because it doesn't want anyone else touching the state. And I think that that helped a lot of people understand more what's going on with not being able to touch the state independently from different components, only being able to send these messages to that component and then have it make all of the changes to the state. That's interesting. The personality comes through. Exactly, yeah.

And we should say it's not just cartoons. So there's rich dialogue and explanation around the cartoons. The drawings themselves are almost XKCD style with stick figures and very simplistic but drawn with, it almost as if you draw them with skill, but you kind of draw them in a childish fashion on purpose. Did you have a background in drawing or? Yeah, I do have some background. I took some design courses at CMU.

But the reason that I do it that way is because that is a way for me to get out of my head to stop thinking it needs to be perfect. If it's meant to be messy and if it's meant to be a little bit sloppy, then I can just get it done. Otherwise, I would be overanalyzing and I would never actually finish one of them. The color blue is pretty interesting, too. Yeah, was that I noticed most of these were like Facebook related libraries at the time. Was that like a Facebook theme or where did you get the color scheme? Well, kind of two things. It is also partially because in the early days,

code cartoons were around React and the React ecosystem. So I did pick blue that was close to that color blue because of that. But also I just really like the visual style of blueprints. And so it's pretty close to the color that you would use in blueprints as well. It's better than black because, you know, just like when you sign a signature for official documents, they always say sign with a blue pen. And the reason is, is because it's less likely to be copied or it's just got this official feel to, I guess. I think there's a reason more than that behind it, but on the web, most things are black and white, black text, white backgrounds.

That's like the primary, you know, colorscape of the Internet, basically. And so having them be blue, they stand out. There's a book to this, though, too. Am I correct in saying that or is there not a book? So things have kind of changed. I've not done a great job. I'm not very good at the brand management part of all of this. And so I originally when I started code cartoons,

I wasn't working at Mozilla, I was just doing it in my spare time. And I planned to do a book around all of the React ecosystem, doing code cartoons. And then I got a job at Mozilla. I was working in dev tools at first, but managed to turn code cartoons into my full time job at Mozilla. So a lot of the latest work is on the hacks blog, Mozilla's hacks blog. So I can send a link for the show notes for that. But there's no book in the works currently. There may be in the future, but I'm doing a lot more work around web technologies,

things like WebAssembly, JavaScript, how the browser works right now. You kind of answer one of my questions, because one of the things I did notice on GoodGartoon is it doesn't appear that you've been publishing to that particular website anymore. And so I was wondering if maybe the magic wore off or if you got sick of drawing or something. But it sounds like you just transitioned that into your day job, which is cool. Yeah. And I need to do a better job of actually updating my site so that it points to all of the recent stuff as well. Right now it's just a medium blog, so I need to

just spend one weekend making that all work, but it hasn't gotten to the top of the list yet. Well, if I found the right place, there's a treasure trove of them. And the very first one is actually on a topic we'll talk about later in the show, which is ES modules, a cartoon deep dive, which is very recent in March. Yes, yes, just a few weeks ago. And one of the things that I use code cartoons for is actually teaching myself about things that I need to learn anyways. am working with the WebAssembly community group to standardize ES module interoperability with WebAssembly modules, basically making it so that WebAssembly modules can be loaded using the ES module API. And that way, WebAssembly modules can be used in the same module graph as JavaScript modules, just as if they were JavaScript modules. But in order to do that, I really needed to

understand how ES modules work at a deep level. And so by doing the code cartoon about them, I taught it to myself. And it also is really helpful when I'm explaining it to, for example, people in the WebAssembly community group who maybe haven't familiarized themselves with all the details. You know, I can actually use these cartoons in the standards body presentations that I do. So it's a nice overlap. Well, I can say it was quite effective for me. I was reading for this a recent post you had on the Mozilla Hacks blog, which we'll talk about in detail, making WebAssembly better for Rust and for all languages. And as I was reading along, I was, you know, I know Wasm a little bit,

like I get it from the outside, but like even I didn't know that it only has support for taking integers or arrays of integers or something like this. Integers or floats. Yeah, integers or floats. Thank you. You can't pass strings. And so you start going into description of what we have to do in order to just have string support. And all of a sudden, I'm seeing some code cartoons.

And I'm following along. And I'm like, oh, I'm learning. This is very effective. So I guess I would just compliment you on the effectiveness of sneaking them in there. Thank you. And I'm learning. This is very effective. So I guess I would just compliment you on the effectiveness of sneaking them in there. And I'm learning by accident there. I haven't gotten to catch one of your talks in person. Do you point these into your slides or is this part of anything you do in person or is this simply something you blog about and include on the web? All of my talks are actually also

code cartoons. I think it's even more important when you're giving a talk because things are moving so quickly and people can't really change the pace to fit what their learning style is. So I try to make sure in my talks that I'm extremely clear in the diagrams that I'm using what exactly is going on, where we are in this process so that people can, you know, if they zone out for a second, they can come back and seamlessly get back into the flow of the talk. I might be going a little too deep here, but I'm curious of the process of actually making them. Is it a computer generated thing or is it pen or is it? Yeah, I was actually thinking, is that too deep or is it cool for me to ask on that? So I mean, how do you make these things? There's the physical process of actually

making the cartoons and then there's the mental process of actually figuring out what should go in them. So I'll start with the mental process, which is basically consuming everything I can on a subject, you know, video, blog posts, the spec itself, all of that, and just like filling my brain to the brim. And then doing a lot of like yoga and jogging. I try to like load up in the morning on a particular topic. And then when I go for my run, I'll just be have that going in the back burner, because I find that thinking about it consciously, a lot of times doesn't work, I have to let those metaphors come to me. And so then once I've had a few that come to me, I'll put them on post-it notes on my wall, and I'll start filling in this wall of post-it notes until the narrative becomes clear through that. And then I fill another wall of post-it notes that actually have all of the images that I'm going to do in order. And at the same time, I'll usually be recording. I don't actually write them. I

say them out loud because I find that that helps me keep my words shorter. You know, if I imagine the person I'm explaining it to, I tend to explain it in a much more accessible way. So I actually will record it and then transcribe it. So that will be happening at the same time that I'm putting these post-its on the wall that are all of the images. And then at that point, it's just a matter of busting through all of those images and drawing them all out. And for that, I use Photoshop and a Wacom, the Wacom Cintiq tablet. I was thinking you might use something like that because I've done a couple things that are like drawing related and I use my Wacom as well. My setup is left hand has the trackpad that Apple has, the magic trackpad, keyboard in the center, and then right hand is the Wacom. So I kind of got that. I almost

feel like a musician, but different instruments because I got the left side is that. In a lot of ways, it's like my left hand is the scroll and zoom and all the gestures. My left hand, which is kind of funny because I'm right-handed, but I can totally relate to what you're using. Well, it's funny because I'm right-handed too, and I have the same setup. I have the trackpad on the left and the walk-on on the right. I've heard it's become very popular. I've been doing this setup for six years, maybe more. What do you draw, Adam?

I make the internet. I don't know. I draw signatures. You know, I do a lot of like, just like doodles. Like before when I was doing a lot more interface design, like I would hop into Photoshop, click the pen tool. And, you know, I might even have a particular setting for doing this. And I would just literally draw out interface like with the Wacom tablet in Photoshop and then save that and hand that to, you know, our design team. Like I would product manage and I would use UX design with them kind of in real time.

And we would sit there and this is going way deep. But maybe maybe Lynn's digging this and some of the audience at least. But I'm digging it. You know, you just draw some stuff out and it's just, it's paper and pen basically, but it's not. And I would choose Lynn's Blue. Like I, that's my favorite, like not that particular, but in that genre of blue. So we're definitely kindred spirits in that front. I have two thoughts on this.

The first one is I think Amy Hoy has a rant. I was just, I just loved how Lynn, you described your, your mental process first. And then you talked about the tools. Cause we can all nerd out about like, yeah, which app are you using? I think Amy Hoy has, I think it's a blog post where she has this, you know, she's a great copywriter and a great designer and she just puts out things that are envious. You know, you see him, you're like, oh, I wish I could have created that. And so, so many people ask her like, what app did you use? You know, as if you say in Wacom tablet, I can just go into Amazon and acquire one

and suddenly, you know, create what you're creating. All the skills. Exactly. And we tend to like boil it down to like, what's your process as if it's magic, but really it's, you know, the, the process like that, that, you know, get all the, get all of the stuff in your head, go for a run, right? Like think it out, boil it down. Like those are actually even more actionable, um, for people that want to do similar things. It just reminds me I get out less, not often enough to go through the thought process. And it just shows the commitment Lynn has to what it takes to mentally break these things down. And then also reveals what time is involved. We see, you know, in plain view, a fairly simple drawing.

But behind the scenes, there's all this thoughts and, you know, the run and the processing and the filling to the brim and then all the post-it notes to the wall. It's a process, Lynn. That's pretty intense. It's true artistry. It is intense. And I'm so exhausted after every single one. I'm just ready to collapse.

In reading these, what I was reminded of was why is Poignant Guide to Ruby? Why the Lucky Stiff? Talk about bringing like advanced concepts to people who are intimidated. And there's, your drawings are more, I don't even know if professional is the right word. His were more whimsical, you know, it was kind of crazy. Lynn, are you familiar with that book? Why is Poignant Guide to Ruby? I've never actually read it. A number of people have pointed me to it because they have said, you know, it reminds them of, uh, that guide, but I still need to read it. Yeah. So, I mean, I guess that, that puts a bullet in my question, which was, I was wondering if there was an inspiration, you know, that direction,

but if you haven't heard of it, if you had never heard of it, then apparently not, where'd you, where did you draw inspiration for this? I mean, do you just take a shower one day and think, I'm going to draw code cartoons? Well, I'd seen a few people doing kind of similar things. But where I really got the inspiration from was I told the BrooklynJS folks that I would give a talk there. And I chose Flux because I wanted to learn more about it. And as I was diving deep into the internals of Flux, it sounded like a conversation to me between the different parts. It really sounded like people talking to each other. I was like, well, the best way to explain it, if it sounds like people talking to each other, is to draw

stick figures and have them talking to each other. So I did it for that talk. And then that talk went over so well. People just kept coming up to me afterwards and saying, that helped me understand it so much more. I've been working with it and I didn't really understand it. So I thought, well, I'll put it in a blog post so that everybody can see it. I put it in this blog post. It went up on Hacker News, got, you know, I think it's probably at 200 plus thousand views now. So it was very successful. And I thought, well, maybe other things would benefit from this kind of treatment. So I just started playing around and seeing if the style would help people learn other things as well.

And when it consistently did help people, I thought I should really run with this. Yeah, you can tell by the number of claps these have on medium. And I don't even know what a clap is anymore because this is like pre-claps, right? This was back when it was just like hearts. And then you can give like infinity hearts or 50 or whatever. But lots of love on medium translated into multiple languages. So that's when you know that you really resonated. Did people approach you and say, hey, I'd like to put this into Mandarin or

whatever language? Yes, I still get that on a lot of the articles is people will just comment saying, oh, here's a French version or here's a Russian version. So it's great to have all of those translations and to make it accessible to even more people. This episode is brought to you by Linode, our cloud server of choice. It's so easy to get started. Head to linode.com slash changelog. Pick plan pick a distro and pick a location and in minutes deploy your leno cloud server they have drool hardware native ssd cloud storage 40 gigabit network intel e5 processors simple easy control

panel 99.9 uptime guarantee we are never are never down. 24-7 customer support, 10 data centers, 3 regions, anywhere in the world they got you covered. Head to leno.com slash changelog to get $20 in hosting credit. That's 4 months free. Once again, leno.com slash changelog. so lynn you are at mozilla now where you work on well what do you work on at mozilla besides drawing more code cartoons i do a few things i work with some of the teams like the WebAssembly team. So as I mentioned before, I'm working on standardization of the interop between ECMAScript, ES modules, and WebAssembly modules. I also work a little bit with the Rust team on their work to make it possible to compile Rust to WebAssembly and making that integration between JavaScript and WebAssembly really nice to work with so that

you don't have to think, oh, no, I have to bring a WebAssembly module in here. Instead, it's just another module. So I work a lot with those teams. I've also done a little bit of work with other teams like our CSS style engine, Stylo, which came to Firefox. It was developed in Servo, which was a web engine that we used to test out the idea of parallelizing everything in the browser engine. And so once we figured out that that really works well, we brought it over to Firefox last year. So I do jump around a little bit and I get to work with a bunch of different teams, which is fun. Let's focus in on Rust a little bit and something that you wrote the first sentence in this post back from March about making WebAssembly faster, or sorry, not faster, but better for Rust and for all languages.

You say one big 2018 goal for the Rust community is to become a web language. And so I guess the first question is why, and then we'll go to how. But why does Rust want to become a web language? Well, you can just reach so many more people. There are so many web developers out there. So making it possible for those people to

use Rust in the context of their applications means that Rust can be used a lot more widely. And the Rust community also just really likes bringing down barriers, making sure that there's as few barriers as possible to working with Rust. So making sure that web developers can use it is a big part of that. And so in order to do that, of course, WebAssembly is the gateway drug to the web for these other languages that are not JavaScript, right? Right, yeah. I mean, WebAssembly is pretty much the first opportunity that any language besides JavaScript has had to really be a part of the web platform. What about Dart? Isn't that another language that was sort of aiming at similar type of desires was to be a browser component?

Dart has shifted gears over the years. From what I understand now, they had talked about having a fully separate virtual machine that would run Dart instead of JavaScript. And I think that now they're compiling to JavaScript. I don't, I'm not totally up to date on what the Dart team is doing, but I think that that was what they decided to do. The thing about WebAssembly is it actually runs in the same engine as JavaScript. It gives you a lot, it will give you a lot of the same capabilities as JavaScript and give you a lot of the same access and a lot of the same security protections that JavaScript has because it is part of that VM and it can reuse a lot of the code. How should, how should web developers who aren't very familiar with WebAssembly think about it? Is it a runtime? Is it a compiler? Is it a language? Is it like assembly language? What's the story on exactly

what it is and what it provides? Yeah, it's hard to completely describe it because it's kind of the first of its kind on the web. It is kind of like assembly language, but it's more like a virtual assembly language. It gives you pretty low level operations, but they're not exactly targeted for a particular machine like assembly code would be. And that's because you don't know when you're sending a file across the web, what machine that other person is running on. So you can't have assembly code that is specific to that machine. So what WebAssembly does is it, uh, gives you something that looks like assembly and it's pretty close to assembly, but then the virtual machine will translate it into actual assembly code

for whatever machine that is running on. So like in the browser, the browser will do that short little hop between WebAssembly and actual assembly. So then for these other languages to run in the browser, so for Rust to run in the browser, then its job is to somehow build or compile itself into a WebAssembly compatible binary? Or is that the right language? Yes, basically, it targets WebAssembly. So you put in when you're compiling your Rust code, you'll say target WebAssembly, you know not the most descriptive flag that we could have. But that will tell Rust, the compiler, okay, you need to turn this into WebAssembly, WebAssembly binary.

And so any language that wants to run in like Manor, the authors of that language, the community around it, whether it's Go or Ruby or any other language, would have to do similar work. Is Rust kind of leading the way? Did you know the landscape of different programming languages and their support for WebAssembly? So the ones that really led the way were C and C++. And the reason for that was really the games industry

that was the first user of WebAssembly, because it was very hard to run games in browsers. And so because of performance limitations, you know, when you're playing a game, you don't want to have the frame freeze while it has to do some computation. And you want to have that really fine green control over performance. So it was the games industry that really pushed WebAssembly forward for the first few years. And you want to have that really fine-grained control over performance. So it was the games industry that really pushed WebAssembly forward for the first few years. And a lot of those folks are coding in C and C++. So those are the languages that have the best support for WebAssembly at the moment. Rust is coming along. I'd say that Rust is right behind them. The work really only started in earnest to make WebAssembly compilation of Rust

work well, maybe six months ago, I'd say. But they've come a long way and are really pushing WebAssembly forward at this point. There are also other languages that are starting to, I think that Go actually just landed their initial support for compiling to WebAssembly in the main tree. So there are other languages that are pushing in this direction now. But Rust is definitely behind C and C++, the one that's gotten the furthest. And one thing that I was surprised to find about WebAssembly, we talk about support from the language side, but support from the browser side is actually pretty good.

Pretty much every modern browser except for Edge has it in preview mode, which maybe you can tell me exactly what that means. But it's out there in the browsers to be used today. It's unique. The WebAssembly standardization effort is unique in how quickly and smoothly it went, I believe. They started standardization of it in earnest in 2015. And by 2017, all of the browsers were announcing that this is ready, we're turning it on. So that was a really big deal. I think that a big part of that is that so much of the work in figuring out how it needs to work had already happened with Asm.js. And they'd figured out a lot of the, like what

you need for a minimum viable product of WebAssembly through that process. So it was really just standardizing, paving those cow paths. But it's also a really functional standards body. They are able to move things along more quickly because they know how to work together really well. So a lot of the people who, there's a lot of people that love JavaScript and then there's other people that don't like it so much. And then there's a lot of people that really, really dislike JavaScript. And so people are excited about Wasm for different reasons, right? But, you know, some people who are really into Go or really into Rust, they're excited

because they think, I may never have to write JavaScript anymore. And, you know, some people may think the Rust community is trying to replace JavaScript, but you don't need it anymore. You need Rust. But what I'm hearing from you and from other people at Mozilla is, it's not really, that's not the story here.

There's more to it or it's nuanced. What is the story with this interop and making them almost merge that you guys are trying to do, as opposed to just saying, hey, we can just use WebAssembly. We don't need JavaScript anymore. Well, there are a lot of things that JavaScript does really well. And it does it without increasing the barrier to entry for new developers. And so we don't want to tell new developers, oh, you have to go learn a language that might be more difficult. We want people to still have that easy onboarding ramp.

So JavaScript gives that. And there are also just a lot of places where JavaScript, the performance is fine and you really don't need to have a really fine-tuned level of performance. We think that having them work together better is really the answer, not saying we're going to replace this really easy to use language with a host of other languages that may be harder to use. Also, there's just so much innovation that's happened in the JavaScript ecosystem because of this low barrier of entry. You have all of these different ideas that people, you know, one person will create a library that, you know, does something cool, but maybe not in the most efficient way. And other people will jump in and help them make it more efficient. So I think that we really want to capitalize on all of that innovation that's happening in the JavaScript ecosystem and make that available to people who are coding in other languages.

Make it seamless to integrate with those other tools. So, yeah, what progress has been made there? And, you know, what is it exactly? Does it look like the the interoperability between the two so you can use the best, you know, you can use Rust when it makes sense, you can use JavaScript when it makes sense. And you don't have to have a like a partition between them. It sounds like there's a lot of glue that has to go into that. Yes. And we're trying to make some of that glue something that people don't even notice that they don't see that they're using. So one of the projects that we've been talking about at Mozilla is called Wasm BindGen. Because as you noted earlier in the show, right now you can only pass integers and floats into WebAssembly functions.

But a lot of times you need to do something like pass a string into it. And the way that you do that is by actually encoding the characters in the string into their number equivalents using something like the TextEncoder API, and then putting those numbers into an array buffer, which is basically just like a JavaScript array, but what it holds is bytes. So you put it into this array buffer. And then on the WebAssembly side, well, you just have to pass a pointer, which is really just an integer, the array index. You pass that from JavaScript into your WebAssembly function. And then WebAssembly will use that array index to figure out,

okay, I need to start getting the bytes for this string here in this memory and pull them out. And then it will decode them into characters again. So that's a pretty complicated process for a lot of JavaScript developers. And even for people who are not working with JavaScript, it's just very low level. So we have a tool called Wasm BindGen, which will automatically wrap your WebAssembly module with some JS code that will actually do that for you, all of that conversion. And it will also make it possible to use Rust classes

or Rust structs in JavaScript as classes. It'll do a lot of that wiring up and marshalling the data for you. So right now it is pretty Rust specific. We're hoping that we can expand it to support other languages as well so that all languages can then have this easy passing, you know, pass a string, pass a struct,

pass whatever you want from JavaScript back to WebAssembly. And there's also some work that's happening in the WebAssembly community group to make this easier as well. There's a proposal called AnyRef, which will make it possible to take references and share them between JavaScript and WebAssembly. And there's also something called host bindings, which would do a lot of the translation of values at the boundary between JavaScript and WebAssembly. I want to say, calling back to the cartoons too, like your visual description and then your code description of this is cartoons that go with it are just – as you're talking through it, I can kind of almost hear you creating these in the transcription process that you mentioned earlier.

Like I can hear your process for describing these complex things. And it's just so much easier to see as code cartoons. I agree. Yeah. Yeah. It's a shame that – I wish that all podcasts were visual and I could just be drawing as I'm explaining things. That would be awesome. Maybe an opportunity to mention our Twitch channel, Adam,

as we're doing a little bit more video. And we have been live streaming some coding sessions and we would love to be bringing guests on those. And we've talked about, by the way, to the listeners, JS Party is back. I'm not sure if you've heard. But every Thursday we are doing the JS Party thing. We have a huge cast of experts on that show, so check it back out.

If you haven't yet, changelog.com slash jsparty. We talked about doing that live on Twitch because you can always use a video component. We do believe in audio as a great final product because of the versatility in which you can listen anywhere. But yeah, for certain things, especially talking about code, looking at code, drawing things, diagramming, doing the kind of stuff that Lynn, you're so good at doing. Audio is definitely a constraining medium for your skills. Can you talk a bit about the process for the languages to take part? You'd mentioned that C, C++, obviously Rust, and even Go you'd mentioned, but you're inviting at the bottom of this post other languages to jump on board if you want to start to support WebAssembly. What's the process for something

like that happen? Well, really, any language that has a compiler of some sort can build in support in the compiler and figure out exactly what the high level language constructs translate to when you're talking about these low level operations that Web Assembly gives you. I could go into great detail about exactly what kinds of operations it has, but it would probably take a half hour to explain. But basically, it's this thing called a stack machine. So if you want to add two numbers together, you put two numbers into the stack, and then you say, add and because the the add command, the add operation is, it knows that it takes two things, it will take those two numbers off of the stack, add them together, and then put the value back onto the stack. So basically need to output code that can do things in that stack machine kind of way with the operations that WebAssembly makes available.

One of the things that WebAssembly doesn't support yet that a lot of languages do need is integration with the garbage collection in the browser. You can write your own garbage collection and ship it down with your code. And that works fine. But it can also it you know, makes the file size larger. It can be hard to if you have objects that are going between JavaScript and WebAssembly, Hard to keep track of those. And it's just kind of tricky to write a good industrial-grade garbage collector. But all of the browsers have really good garbage collectors. So we're trying to, over the next year, really push that forward and make it possible for languages to depend on the garbage collection in the browser. Now, this isn't going to work for all languages,

but we think that there are a lot of languages that then will be able to target WebAssembly really easily. Going back to the bind gen conversation and what you're providing there, it sounds like all the plumbing necessary to convert things into the right formatting, the serialization, or really the marshalling into classes and stuff on the JavaScript side. Recently I saw a Hello World Rust thing in WebAssembly. By the way, there's WebAssembly Studio,

which I hadn't heard of until maybe today even, which is pretty cool. For those out there who would like to play around this stuff, WebAssembly.studio will link that up as well. And you can see examples of people doing things. And they have an example, a very simple hello world, where it's using Wasm bind gen. And there's a function defined in the Rust side called greet,

which takes a string as an argument. And then there is a function on the JavaScript side, which I think you're probably familiar with. It's called alert. And so that one's, you know, built right in. And they are both using the opposite functions, one on the JavaScript side, one on the Rust side. That is pretty cool. You can imagine all the places that could go. And I mean, once you get this native support for all the functions over here and all the functions over there, now you have access to like both the best of both worlds, right? Exactly. Yeah. And WebAssembly Studio is a great tool for people that just want to try out playing

around with Rust to WebAssembly compilation or really any language to WebAssembly. Because it means that you don't have to download the compiler tool chain or anything. It'll just run in your browser, which is fantastic. And we're actually building a project around that for JSConf EU. It's this light environment. It's a space that this artist that I know from Pittsburgh is building that has all of these LED bricks all over for the big space. And you can program it to have different animations on these LED bricks.

And so we are going to make it possible to program it using WebAssembly Studio and write animations that can then be shown on this space while people are dancing inside of it or whatever. Is this a WebAssembly working group thing? Is that right what this is? That project in particular is a Mozilla thing. And the WebAssembly Studio is also a Mozilla thing.

Michael Bebanita, who is one of our folks in Emerging Technologies, created WebAssembly Studio kind of in a spare time, I think. And people were so excited about it that it's now something that he and a few other people work on. This episode is brought to you by our friends at GoCD. GoCD is an open source continuous delivery server built by ThoughtWorks. Check them out at gocd.org or on GitHub at github.com slash gocd.

GoCD provides continuous delivery out of the box with its built-in pipelines, advanced traceability, and value stream visualization. With GoCD, you can easily model, orchestrate, and visualize complex workflows from end to end with no problem. They support Kubernetes and modern infrastructure with elastic on-demand agents and cloud deployments. To learn more about GoCD, visit gocd.org slash changelog. It's free to use,

and they have professional support and enterprise add-ons available from ThoughtWorks. Once again, gocd.org slash changelog. So Lynn, tell us about the work that you're doing with the Wasm ES modules spec. Sounds complicated. It is complicated. In a way, it's actually pretty straightforward because the WebAssembly group really designed the module system to eventually work with ES modules. And then when ES modules were taking longer to be standardized, they switched to having this imperative JavaScript API for instantiating web assembly modules. But it was really designed for it to easily interop with the JavaScript ES modules. But the complicated part is that you have to work with three different standards bodies

across at least four different specs. There's your complicated, yeah. Yeah. Red tape. So it's a lot of explaining to everybody what's going on, why we have to make the changes that we are making. And so far, everybody's been on board, which is great. And hopefully we'll continue to be that way. But the goal of the work is right now, as I said, there's an imperative JavaScript API. Basically, you have to tell

JavaScript to build this WebAssembly module for you. And you have to go step by step, you have to tell it, okay, fetch the file first, and then take the imports that I need to pass into the module and initialize those, and then pass those in, instantiate the module using those imports. And then finally, you can actually use whatever export from that module you want it to whatever function or value you wanted to from that module. So what we want to do is move it to a declarative API, like what you have with ES modules, where you can just say import foo from bar.js, and it just gives it to you. It does all of the other work for you. The tricky parts there are figuring out where exactly, because the ES module spec breaks up the process into three different phases. First, you construct the module graph, you download all of the module

files that you need, and you parse them into module records so that you know what's going on in this file. But this process has to happen in kind of an iterative way, because you first get the first file, then you first get the first file, then you have to parse that to figure out what modules it depends on. And then you go and fetch those from the web, then you parse them. And so you have to keep going down and down and down, fetching and parsing and fetching and parsing through this whole module graph. And then the second phase, once you have your whole module graph figured out, the second phase is linking them together. So finding places in memory for exports, and then connecting both the export

statement and the import statement to that same place in memory when they're referring to the same thing. And then you actually fill in the values that will be in those variables. So that the second step, that linking step is called instantiation. And the third step is called evaluation. That's where you're actually evaluating the code that's outside of functions in the module. And so figuring out how to make WebAssembly fit with this, but there are certain ways in which it can't quite. So figuring out what to do in those cases, that is a little bit tricky. But so far, we have some good plans in place for how to make that work.

I can tell that you're deep in the weeds on this work. So we very much appreciate your efforts put in because, you know, as you get these things ironed out and formalized and then the implementation with WASM, I mean, it affects everybody, right? Because so many languages potentially can integrate. Where are you looking at in terms of progress and what we can expect, you know, this work to be done and you can finally go out and I don't know if you have a drink or celebrate your success. It's always hard to say with standards. It's hard to give dates. We've been making good progress. And so I presented to the WebAssembly CG two weeks ago, basically explaining how exports are going to work in every kind of case. When you're importing JavaScript functions into WebAssembly,

when you're exporting from WebAssembly to JavaScript, when you have cycles between the different things. And everybody seemed to be on board for the design. So now the process, the next step, is doing a rough draft of the spec text and making sure that everybody from the different groups is on board for that spec text. So I'll be going to TC39 in May to talk to them. They're the standards body in charge of JavaScript.

And working with them to make sure that everything that we're doing makes sense from their perspective as well. And once we've gotten everybody on board for the decisions and we have some spec text, we should be able to push it through. We also need to have some people implementing it. And I just saw on Twitter a few days ago that JSC, JavaScript Core, the JavaScript engine that is in WebKit, they have already started playing around with an implementation. And we've had interest from other people, folks on the Chrome team, folks in Node.

So I think that we're going to be able to get the implementations done pretty quickly, too. So I think that it should be moving along at a nice pace. Let's zoom back out again. We're talking about, you know, the low level grinding that many that you and many other people are doing in order to push these things forward. Let's look at it from Firefox perspective, perhaps, you know, all this goal for the Rust community, Rust to become a web language, this, all the progress on WebAssembly. What does this mean for Firefox? Well, Rust in particular means multiple things for Firefox. We're using Rust, not Rust compiled to WebAssembly, but just Rust in our code base in Firefox now.

Because, and actually that will be what I'm speaking about at FluentConf in July, or June, sorry, is about how we're using Rust to make it possible to parallelize different parts of the engine in a fine grained way without it being dangerous, because that it can actually be, you can introduce really dangerous bugs that way, but Rust avoids those bugs. So Rust is helping Firefox in that way. Once we have people compiling Rust to WebAssembly and using that on the web, WebAssembly is a lot easier for an engine to compile. So it's a lot easier for the VM that's in the browser to do a good job of making the code run fast

when it's in WebAssembly than when it's in JavaScript. Because with JavaScript, the engine has to make a lot of guesses about where it can cut corners with the code. And those guesses sometimes work out, sometimes they don't. It can be really unpredictable. And you have to have some really clever people working on the engine, figuring out what shortcuts they can take that won't negatively impact too many people's code. So it will be nice for us if more code is in WebAssembly on the web.

It will be nice that we don't have to do quite as many hacks and quite as many shortcuts in the JavaScript engine. Do you see a world maybe three, five years from now, maybe longer, where WebAssembly is powering a significant portion of the web, similar to how, you know, not years from now, maybe longer, where WebAssembly is powering a significant portion of the web, similar to how, you know, not similar to WordPress, but you know, WordPress powers 25% of websites or jQuery was like a ridiculous amount of times, you know, of the percentage of websites you can go to and, you know, open your console up and find the dollar sign defined as the jQuery constant. What about WebAssembly? Like, if everything goes well,

do you think it will be a niche where only things like games and high-powered rendering, video, what have you, needs WebAssembly? Or do you think it'll reach out and have common use amongst what we'll just call regular websites? I think that we are going to see it spreading once it gets into a few key pieces of software. I think we'll see it spreading pretty quickly. So what we think is going to happen is the frameworks will start building WebAssembly components within the frameworks that everyone will be using them and nobody will realize that they're using WebAssembly because they have a JavaScript interface to interact with that WebAssembly.

So I don't know if you've seen the EmberConf keynote that Yehuda Katz and Tom Dale gave maybe a month ago. They talked about their work to using WebAssembly in the Glimmer engine. And we've talked with the React team about how they might use WebAssembly. There are other frameworks I know that are looking at how they can use WebAssembly for parts of their framework that, you know, don't really need to be in JavaScript and where they could see performance gains from switching to something like WebAssembly. You know, we just had a show about Ember last week with Chad Hytale. Adam, did we talk about that? I mean, he talked about Glimmer quite a bit, but it didn't ring a bell. I don't recall us talking at all about WebSite. Neither. He held out on us. So you mentioned Fluent and you have a keynote coming up at Fluent. And hey, what do you say? We'll be

at Fluent. Adam, why don't you tell the good people about our role with Fluent this June? Absolutely. So we have a fun working relationship with O'Reilly, and we always enjoy working with them. And we're actually going to be there in the hallways, kind of doing the hallway track. We got Kevin Ball going, also known on JS Party and fun stuff he's done for Foundation and Zurb and the things he does. And then Tim Smith is a recent hire for us, senior producer here at ChangeLogin. We're sending both of them over to FluentConf to kind of do the hallway track, get some interviews. We're sending a video camera, doing some fun stuff. So we're trying to do more stuff for our YouTube channel and just different stuff we haven't

really had a chance to do yet. So Kevin and Tim are going to go to Fluent and at the same time velocity because they're technically the same conference in the same venueent and at the same time velocity because they're technically the same conference in the same venue but at the same time. And just sort of pull back the layer of the hallway tract, talking to people, talking to some of the speakers, obviously. Maybe Cory Docter might get on camera with us. We'll see.

Will they have swag? Will they have stickers for people to – I can't see why not. I mean, I don't know how much it makes sense for them to carry, but maybe a few. It might be better to take names and numbers and addresses and say, hey, we should do something.

We gotta get these guys some stickers to hand out. Well, stickers for sure, but t-shirts, we'll see. Stickers, definitely easy. We'll 100% on that for sure. All right, so find the guys with the changelog t-shirts,

Tim and Kevin Ball. He likes to go by K-B hear that's right go by k ball and uh hit him up for stickers at least and hey adam's talking about t-shirts so and check the show notes too if you plan to go to fluent call if you'd like to go we have a coupon code for 20 off changelog without coupon and the url will be in the show notes it's kind of a cryptic one it's one of the special ones so use that i think that might actually automatically get you the 20 off but use the code changelog and you'll see a 20 off most passes very cool lynn you are keynoting at fluent you meant as you mentioned and your talk is called the parallel future of the browser and i'm sure it's it it summarized it for us once again i know you mentioned a little

bit but sounds like a lot of the stuff you've been working on, a lot of stuff Mozilla's working on about trying to make Firefox better, faster, stronger. Yes. And in that talk, I talk about not just what Firefox has to do, but what all browsers have to do to get faster over the next 10 to 20 years. Because if you look at the direction that hardware is going, hardware is splitting up into multiple cores. You have these multi-core architectures. And I know that you've had other people on the show that talk about this. Basically, before we would get speedups at a certain rate, it looks like that rate of speedups in processors, like how fast a computer can work, at least when you have one chip, it looks like that it has a limit. We're only going to be able to make the circuits that are in there so small before they start burning up. And so

the chip manufacturers have started splitting up into multiple cores so that they can have a core, you know, because you can think of a core as kind of like a brain. If you have one brain working on a problem, it can only go so fast. If you have two brains or four brains working on that same problem, it can go faster. But you can have some costs of communicating, coordinating between these different brains. And so one way that people have gotten around that cost of communicating between the different brains is just have them work on pretty separate tasks. It's called core-screened parallelism. So you might have one of the cores working on figuring out what to show inside the browser window and another core working on the know, the address bar, the scroll, all of that stuff, and then another core working on whatever is in the background tab. But that can

lead to underutilization of the cores. It can mean that you're leaving some of those cores without work to do, like if the background tab isn't doing anything, if the address bar isn't changing. What we want to do, and what we have been doing over the past year and a half or so is introducing fine-grained parallelism into the browser, making it possible to split up work not just at that course level of one tab goes to one core, another tab goes to another, but actually having the work that happens inside a single tab be split up across different cores. And so that's what I am talking about in this talk is exactly how we're doing that and why

we're doing it and also how application code could then also be split up among these different cores. Is that kind of where Firefox is heading now? And what are some of the things that Firefox has already done to get there that you'll sort of say, hey, here's a great example? Yeah. So Firefox has really been looking at this. We released Firefox Quantum in November. And one of the big parts of that project was figuring out how we do this and actually taking some of the components from Servo, which was our web engine where we were exploring this, and moving them into Firefox. So one of these is Stylo, the CSS engine, where you can take all of the different elements that you have on a page and split them up, split up figuring out

which styles apply to those different elements across the different cores, so that you can speed up the CSS style computation, one part of rendering a web page. You can speed that up by however many cores you have because it's splitting up the work in a really efficient way across those different cores. And that means that as chip manufacturers add more and more cores, we'll see automatic speed ups in Firefox for CSS style computation. Another part of Project Quantum is this thing called web render. When you're rendering a web page, you know, you need to figure out the plan for what is going to show up on the screen. That is parsing the HTML into DOM nodes and then

figuring out the style for those and then figuring out where exactly like the measurements for where those things should go on the page. That's called layout. Once you have that plan in place, you actually need to paint it to the screen, you actually need to paint pixels. So a lot of browsers, including us, have split things up into this compositing stage. And then, or rather a painting stage, and then a compositing stage where they create layers and then basically put the layers together and take a picture of them. And what we're doing with WebRender is actually removing the distinction between those two and making the work a lot more parallel by moving it to the GPU, the graphics processing unit. That's a popular thing happening nowadays too, especially as you talk about the, you know, all the stuff happening with GPUs and just the acceleration things happening on that front

around NVIDIA and different hardware I've heard about. I'm not fluent in it, but I've heard a lot about GPU acceleration these days. One of the neat things about GPUs is you have a whole bunch of different cores. So with a CPU, you usually have maybe two or four or six or eight, you know, you don't have that many with a GPU, you have hundreds or thousands, but they can't really

do things too independently from each other. A CPU, the different cores are like different brains with the GPU. They all have to be basically working on the same task. So you need to figure out how to tell them to do things, um, in a way that's efficient. And so that's what WebRender really does, is it makes it possible for us to give instructions to the GPU and pass off all of this work to the GPU and do it in an efficient way. This is in the roadmap for this year for Servo, right? Well, it's already landed in Servo. It is in the roadmap for Firefox this year. For episodes on Servo, check out changelog.com slash 228. And

for more on Moore's Law and high performance computing, which is I think what perhaps Lynn referenced there, episode 284, Todd Gamlin, that was a recent favorite of a few of our listeners. So just cross promoting over here just doing my job i love it lynn uh sounds like a great talk everybody go to fluent use our code changelog say hi to lynn attend her keynote and do you have anything else that you'd like to uh chat about before we call us a wrap i think that we covered everything and so many things i'm excited about all the things that we talked about today well thank you so much for your time. This is awesome to have you on the show. Thanks so much for having me. All right. Thank you for tuning into this episode of The Change Log. If you enjoyed the show,

do us a favor, share it with a friend, rate us on Apple Podcasts, go on Overcast and favorite it, drop a link on Twitter. And thank you to our sponsors, Airbrake, Linode, and GoCD. Also, thanks to Fastly, our bandwidth partner. Head to Fastly.com to learn more. And we move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode servers. Check them out at Linode.com. This show is hosted by myself, Adam Stachowiak, and Jared Santo.

Editing and mastering is by Tim Smith. Music by Breakmaster Cylinder. And you can find more shows just like this at changelog.com or wherever you get your podcasts. Thanks for listening. We'll see you next week.