 Hi, I am Ryan Hunt. I work at Mozilla on SpiderMonkey, specifically on the WebAssembly team, and yeah, that's all you need to know. Hi, I am Conrad Watt. I kind of wear two hats as a research fellow at Peter House, which is a college of the University of Cambridge. I do WebAssembly research with a specific focus on programming language theory. And then I have another hat as a co-chair of the WebAssembly community group, which is the main standards body for the core WebAssembly virtual machine. Hi, I am David. I work on the JavaScript core team at Apple. Lately I have been working on the WebAssembly baseline compiler in that, but I have worked with both WebAssembly and JS in the past, and I guess mostly on compiler optimizations. I am Adam Klein. I work on V8 at Google, focusing on WebAssembly and JavaScript standards. The last couple of years I have been focusing mostly on WacomGC and pushing that over the MVP line. Fantastic. So I want to jump back to you, David. You mentioned baseline compilers. Do you mind letting us know what those are in case people aren't aware? Oh, yeah. If you are not familiar with the concept of a baseline compiler, I guess just a general introduction is that whenever you are running WebAssembly in a browser, it is getting compiled in the browser runtime. In order to make sure that starts up quickly, we usually run it through several different compilers with increasing amounts of optimization. The baseline is the first one, so it compiles really quickly, so you start up fast. It doesn't necessarily run the fastest, though, in terms of the final code. Does your baseline compiler have a special name? I know of a few others that are in the ecosystem. Yeah. Like a lot of the JavaScript core compilers, it has a fun acronym name. It is BBQ for build byte code quickly. Our higher tier is OMG for optimized machine code generation, and then sort of unrelated to that, we also have the Web template framework. I feel like I need to share Mozilla's once, because so far we have two tiers. We also have a baseline tier and an optimizing tier. And the story was that our optimizing tier was called Baldr, which I don't remember the origins of that. But then the person who wrote our baseline tier called it Rubaldr, and I'm told it's a really funny joke in Norwegian, but I don't know what it is. How about V8? V8 also has a baseline compiler called Liftoff, and then an optimizing compiler called Turbofan. Yeah. I think the compiler landscape is really vast. There's a lot of innovation for WebAssembly specifically in that space. Are there any cool projects that you think are worth highlighting right now? I'm going to open it up to all of you. If there's any new things that you're trying out or experimenting with, I think we would love to hear it. I mean, going back to WasmGC, that's the thing that we're currently heavily invested in. There's an origin trial right now, so people are experimenting with this in the wild, and we're excited to be moving in lockstep with SpiderMonkey on having engine implementations aligned with each other. And so that's the main thing for me, that WasmGC allows you to take managed languages like Kotlin or Java and compile them to Wasm while making use of the garbage collector that's already in the Web VMs, and so that's super exciting. Yeah, I think that's going to be huge for the WebAssembly ecosystem, letting us bring new languages that previously didn't compile WebAssembly online. How long has WasmGC been in the works? Oh, sure. I guess I'll give this a go. So we've been talking about it for many years. I think you may have remembered, if you were following the standards process, that back in 2018, we were very excited about the idea this was just going to be, if not around the corner, then at least coming in the next few years. And obviously, there are a lot of things that went wrong in 2020, 2020, 2021, that I don't think we all need to relive. But now I feel like we're just about at a place where it really is around a corner, which is quite exciting given the promise of being able to compile new languages to WebAssembly. I think it'll be quite exciting to get away from just the C, C++, Rust angle and see what Java can do on WebAssembly, for example. And like with many things in WebAssembly, it's a big group effort to make this possible. There's engines implementing the stuff and people working on the spec, but there's also language tool chains that have been experimenting with us and applications using those tool chains. So it's really many layers to make it possible to experiment and vet these ideas and see that we're getting the benefits that we expect. Yeah. And I think that's the reason why there's such a long lead time on a lot of proposals is because it starts out like as a twinkle in someone's eye, like this would be a great thing to do. And then it kind of gets thrown out to the community group as an idea. And there's usually a lot of discussion with that. And then there's a lot of work to kind of pull together like a group of people who would say, like, I would commit some time developing this in my WebAssembly engine. And then some tool chain folks who would end up using it too. And sometimes you have to break the chicken egg problem a little bit because people in tool chains don't want to do things if the engines aren't going to do it. Engines don't want to do it. Tool chains aren't going to do it. And so sometimes it takes a bit of effort to figure that out. And then there's usually a feedback loop then where tool chains started doing something. And they say, Oh, this was a great idea. It just doesn't work. So you have to tweak it. And it just takes a long time. But hopefully the end result's pretty good. How often do you feel that an implementation works in one of the runtimes but not in the others? And how do you resolve those differences? So when you say works, do you mean like it is implemented or like, are you talking like web incompatibilities? Like, yeah, I would say it could be, could, could run and could work in that one runtime. Maybe it's not necessarily implemented yet, but they see a path forward and somebody else says, that's going to be terrible. It's going to just, it's just going to destroy all of our performance gains. Well, I think so. So I'll say just on the web compatibility thing of like how many times when people implement features and like ship them, usually so far, just the nature of things, I think we've been pretty well interoperable across engines, which has been very nice. In terms of like different browsers having different opinions on standards about whether this is a good idea or not. I don't think that's been the largest issue. Sometimes there's usually like, I think there can be agreement that things are like good problems worth solving, but some of the details about how to solve them can change. And I think that's the most common thing that happens. And there is sort of like this, at least so far in the WebAssembly community group, like a nice implicit set of things. Like, these are goals that we want core WebAssembly to have. And there's been broad agreements, so we're not fighting too many philosophical wars. It comes up sometimes, but there's been a good amount of agreement on things like predictable performance and avoiding the need for like really heavyweight optimization things. Even though it's never been formally agreed upon, but it does seem like there's good agreement on those things. Circling back a little bit to Wasm GC, are there other proposals that interact with the Wasm GC proposal itself? I know there are many others that are in flight. Conrad? I guess I could talk both about proposals that are currently interacting with Wasm GC and proposals we would expect to interact with Wasm GC in the future. In terms of proposals that are interacting with Wasm GC right now, I think exception handling is pretty inextricably linked with that, given that a lot of languages that have interesting exception behavior would also want to use Wasm GC as part of their compilation strategy. In terms of features still to come, the one I hold close to my heart is threads. Right now, the threads proposal for WebAssembly is effectively entirely disjoint from Wasm GC. And it's really only facilitating languages that are able to compile into linear memory in order to do multithreading. But the dream would be one day to make these proposals kind of talk to each other so you can have languages using the GC proposal but access the objects allocated through that proposal in a multithreaded way. And that's certainly something that's on the roadmap for a post-minimum product version of threads as a future proposal. I haven't heard anything about stack switching yet. I'm just going to like stack switching. Anybody? Well, yeah, if you were going to ask like what the next big thing that I see, I mean, multithreading would be one and probably stack switching would be the other. This is another place where I think it's going to be really valuable to find partnerships with languages and language tool chains. A little bit of background stack switching is a would be addition to core Wasm that would serve as a basis for a bunch of different asynchronous primitives and various languages. So in Go, there's GoRoutines. In Kotlin, you have co-routines and Dart has async await. All those things could be made more efficient in the format, so smaller binaries and hopefully more efficient at runtime if there is support added to engines for stack switching. And so that's something that we've been experimenting with like a precursor to with JavaScript promise integration in V8. And that's currently available behind a flag. We hope to be able to use that same basis infrastructure to implement core stack switching, but there's still a lot of work to be done to see what the surface area of that thing looks like. And then like I said, I think it's going to be really important to work with language implementers to see what constraints they have and what works better for different languages. Yeah, so Wasm GC is going to let us bring more languages to both browsers and any other WebAssembly runtime. Stack switching kind of the same thing, bring new different types of primitive types. Wasm threads proposal. Thank you Conrad is going to let us do threading inside a core Wasm module and that's huge. Are there any other big standards or proposals that are in flight that I'm missing here? I mean there possibly could be. I do want to think another thing that's worth calling out to is like whenever we think about standards at Mozilla around WebAssembly, I feel like there's sort of two tracks that sort of intersect at times. There's like for linear memory languages with C++ and REST and then there's this future GC thing and we're super excited about the GC thing too, but there's been a lot of proposals really about like making the linear memory languages like a much more mature target over time. So there's been a lot of work done on SIMD, relax SIMD and memory 64, multi-memory and there will probably continue to be new ones as time comes up. So that's also another really important area that we care quite a bit about. Tail calls is also a thing too, although that's also sort of a weird intersection. Like linear memory languages can use that but also it's like much more critical for certain GC languages as well. And some of those proposals that I mentioned are like not far off from shipping, they're like Phase 3, a lot of implementation work's been done but it's not quite ready to be released yet. So hopefully we'll be able to finish that up soon. Yeah and I think as a general trend of how we're thinking about extending WebAssembly in the future, there's still a conversation we're having about a kind of conceptual split in the way we deal with WebAssembly proposals. There are some WebAssembly proposals like GC that kind of assume the existence of a very powerful virtual machine under WebAssembly and then you're exposing their capabilities of that virtual machine as WebAssembly instructions to help with compilation. And there's a whole other genre of proposals like SIMD that are much more about tunneling down to the hardware without assuming there's some kind of intervening VM giving you a lot of capability there. And I think as we continue to think about future WebAssembly proposals often there will be problems that can be solved with either one of the two general ways of thinking about a WebAssembly instruction set. So the example I'm thinking about now is memory mapped IO. You can either assume you have a big VM underneath that knows how to allocate buffers and talk to them and then you're just exposing that capability to WebAssembly and that's kind of like a web view. Or you could assume you're working in a more constrained environment where you maybe don't have that and then you'd want to solve this problem in a different way with a different feature set. And working out where to draw the line, where to put the capability and how to express it in WebAssembly is a conversation we're still having and I don't think we have an easy answer as to where the right thing falls in each case. Yeah I think that's the tension that comes up is because like the high lofty idea is like what if we could do both? What if we get something that works for both of them? And I think that's what we often shoot for but sometimes you do have to just say no we can't do both we have to pick it. And so far it hasn't been the case but I do think the further we push along we might run into that a lot more. It sounds like you need multi-tiered compilers but for standards right? Okay I love it. Now Conrad you mentioned tail calls. I think it would be helpful if you described why we would want tail calls, what did they enable? And then you know I think we can't really assume that most people know about the CG phase process. So once you finish that can you tell us a little bit more about what phase three means? Okay so what are tail calls useful for and then what is the CG phase process? So the high level idea of a tail call is that in a particular pattern of calling functions and moving control through between different functions you'd really want to reuse the space on the stack for the call frame to ensure that as a result of calling functions repeatedly recursively you're not overflowing the stack in a situation where conceptually you don't need to. And there are a lot of so it's not so much a feature of languages so this isn't the feature that's necessarily facilitating different languages being compiled to WebAssembly. It's more about a style of writing code in those languages and an assumption about the cost model for those kind of code that we're not necessarily accurately replicating in WebAssembly right now. So there are a ton of source languages that assume if you syntactically call a function in a particular position you're not going to get a stack overflow. And so long as a function at the source level is turning into a function at the WebAssembly level well then you get into an issue if you call between WebAssembly functions and you do overflow the stack. So that's the kind of thing tail calls facilitate. It's about a different cost model of function calls and a particularly useful one given the assumptions certain source languages make about the resources that are taken up every time you do a call. I don't know if anyone else would like to give a different perspective on tail calls before I go into the CG phase process. Sounds like that's good enough. So in terms of the CG phase process the key driving concept behind every stage of discussion in the CG is consensus. So the idea is we're not just having a vote and then you have a 50% plus one result and that's the thing we have to go with no matter how many people are unhappy on the other side. Really our ideal scenario is a situation where no one's objecting to a proposal going forward or if they are objecting it's only on minor grounds and not because they don't want the proposal to go forward because they think it's totally the wrong idea. So in some sense you could think of the default position as being well if people don't agree nothing moves forward and that's kind of reflected in each stage of our phase advancement process. So we go from phase one to phase four and phase one is essentially does someone have an idea that we think is feasibly something in the scope of WebAssembly that could exist in WebAssembly and there can be a lot of disagreements on the particular way this problem is going to be solved but so long as in general we think there's something that can be discussed and there's some solution that could be arrived at. Generally it's pretty easy to move your proposal into phase one without anyone complaining about the specifics of it. Phase two to three is where things get a little bit more involved. With phase two we generally expect you to have a pretty precise description of exactly which instructions you want to be part of your feature and exactly what their behavior is going to be and phase two is generally where we apply the test of do people in the committee as a whole as a community think this particular approach is the right way to solve the problem that we agreed we were generally interested in looking at at phase one. So that tends to be the real test of phase two given your specific design for how to solve the problem do you think do people think this is the right approach even if maybe you've not actually completely implemented it yet at the design level do we think it's correct. Phase three is generally where we start acknowledging that there is a complete prototype available for a feature and at this point it can be just one web engine or one other engine it can be behind a flag but so long as there's pretty much one feature one implementation that people can look at as an example of how this feature should be implemented if there's a test suite if there's a fairly final description of exactly all the corner cases of how the feature works that's what we consider to go phase three and then phase four is full implementation so that's two web engines its unanimous consent effectively to unflag it and have everyone just have this thing exposed on the web in other environments and that's really the point of no return if you get to phase four you're basically going to be in the language forever because we have very strict backwards compatibility requirements and at every stage when we're talking about well does this proposal advance from phase one to phase two phase two to phase three phase three to phase four we are announcing ahead of time there's going to be a vote on this so that everyone who cares can turn up and when it comes to a vote we ask people do you agree with this direction are you neutral or do you not agree and generally we hope there's only a very very small number of people ideally zero are saying not agree because of groundwork we've been doing in terms of discussions beforehand we generally don't like to call a vote on any point of the phase advancement process if we think it would be contentious the point of the vote is not to force a decision that we're unsure whether it's going to pass or not it's effectively to acknowledge a state within the community that everyone's comfortable with and put a marker saying this is actually what we're happy about so the ideal situation is that while we put a high bar on phase advancement each time we're not really having the vote unless we know it's already going to pass and generally the hard part is the conversation that happens before the vote so that we know everyone's happy with where we are and where we want the feature to be thank you Conrad that was an excellent answer I am going to ask all of you a question which is what is your favorite application of of WebAssembly it could be a demo an app a specific use case know that probably each of you are going to duplicate probably one so think of at least two and to give you time to think of it I wanted to highlight what you had mentioned earlier Ryan about SIMD I think that type of advancement in WebAssembly meant that we are now able to say just about everybody in this room yes we're all in wasm cons we're all really into WebAssembly but also everybody on the street that's walking around probably use WebAssembly that day because it's in so many different use cases we're blurring our backgrounds because we're all usually you know now after the time period that you mentioned a lot of us are now all virtual online and we're blurring our backgrounds because we're working from home and you know it's it's Google Meet it's Zoom it's it's it's it's everywhere so most people don't realize they're using WebAssembly and so what that means is that there are so many cool applications and so I'm going to start with you Ryan and then let's go down I appreciate you giving me time to think about this I know that you had mentioned that you were going to ask this and I was preparing things I put a little to do like okay do some research because I know there's like a lot of I always forget about things and then I didn't do it so but two things I can think of here one of them I think is really cool is called Ruffle which is a Rust program which does like flash emulation in the browser and I think that's just I I think that's a cool many different layers of things I love Rust as a programming language I love that compiles to WebAssembly runs in the browser and I love that it solves a problem of like flash emulation and I like I just I love the idea of emulation too so I think that's a really cool one um another one too and this is like one of the first use cases WebAssembly is just running like Unity programs in the browser and like seeing like 3D graphics and things like that you know like I don't I don't usually play games in the browser or anything like that I just think it's incredible that we can do that so those are two two broad things well I'll just give one just to minimize the chances that I'm gazumping someone else's one one of the things I found are really nice and the appropriate use for WebAssembly even in its early days was image processing and manipulation in a website and one of the reasons I thought this was nice was because it's kind of turned out that a lot of the ways people use WebAssembly is you have a big end-to-end app that kind of paints one pane across the whole web page and you're just in WebAssembly world and in WebAssembly rendered world for the entire time you're in the website but another thing we had always kind of hoped WebAssembly would be used for would be if you have a whole website but one particular part of that website is doing some very intensive computation that's the part you can swap out for WebAssembly and suddenly your entire life gets better and I think image processing is one of the places where that's turned out to be absolutely true and I think we've seen a lot of websites where you now have all of these upload an image and it gets compressed in the browser using WebAssembly or re-encoded using WebAssembly and that's exactly the kind of thing I hoped WebAssembly was going to be used for when I saw the story of how it was going to make intensive computation on the web possible so that's my example yeah well I had two examples that I thought of and the first one was ruffle and the second was unity so and I couldn't think of anything that I liked quite as much I might just go into I think a little bit of why I think it's so cool which is that like WebAssembly essentially functions as this like basically like co-processor almost like a GPU or something for the web like you know something like an emulator you might be able to cobble together with JavaScript certainly people have but WebAssembly just makes it that much easier and you know in terms of just sheer performance especially once you know you have these instructions like SIMD that go pretty much directly from WASM to hardware instructions like one to one in a lot of cases then it really opens up this massive use case of yeah like you can run Unity and you know Unreal and other engines in the browser and I really think it shouldn't be understated how like absurd that is like that's wild that's possible and it's all just because there's this like really nice close to the hardware mapping now and that's where I think like WebAssembly like really impresses me okay so I should I had the most time I should have the most elaborate answers here I have actually more than two I'm trying to figure out what to talk about but I'll start with you know one that was a big deal for for me over the last five years which was Photoshop and you know there's a couple things I wanted to say about that one piece is just that it was you know it is one of these things like getting 3d games or something running we're just having it is this major shift for people to say oh this is actually a thing that can be on the web but one of my favorite things about the story of getting Photoshop onto the web was sort of in the development process seeing how they didn't just say okay we'll take Photoshop and make it and just like compile the whole thing with the UI to the web you know there was a whole web team that that worked to you know do a web components based UI um they thought a lot about like how being on the web would change the workflow how it could be you know link based and um and and how things that you know we got to this point actually where I where it was loading faster than the native app did and yet it still seemed really slow and so you know the we spent a lot of time on loading because the expectations for the web are different and it was fun to see a team and the company that was had this really old product that was used to working on that in a one context try to bring into another context and you know we're have to work to fit it in and then doing that going through that process with them and as someone who is you know working for WebAssembly as part of the web web is the like key thing for me and so that was that was fun to see um the the other thing I would say is the the thing that excites me about WebAssembly yeah there are examples now but I think building on some of the kind of the same things that folks just said the thing that the reason I'm still excited going forward is because I think this is a way to to enable the web to grow stuff that we haven't thought of so image processing is one you know we're seeing a lot of stuff like third backgrounds using client side ml and we're not I don't know what the next one is actually going to be that's really going to be good for users but there will be something and I'm happy that that thing is happening in an open standard that works across browsers so we don't have to do this via a proprietary thing you know I think of like the video tag in in html as the kind of thing that I want to enable whatever that next thing is whether it's the metaverse or I don't know but like I think WebAssembly is going to be a key part of making it possible to do stuff we haven't figured out how to do on the web and do it in a way that works across browsers yeah I love that answer I think there are so many different things that we haven't seen yet but I think over the next year we definitely will WebAssembly hit MVP I want to say in 2017 I want to see some nods okay all right we got that date right and then in 2019 that was when it became the official language of the web you guys hate that huh fourth fourth language of the web I said that wrong I get the I get the Snickers now I'm sorry what if I said that on purpose I didn't though believe it it is the official language the official language of the web thank you okay so I think now we should probably open it up to get a few questions from the audience if you're okay with that okay I see one hand back here Apache TVM that uses it so so I don't know a lot I don't know anything about Apache TVM in particular there's a ton of I mean the you know ML space is moving very fast right now I know there's a lot of questions about yeah how what the right way to layer this stuff is how many layers we want to build whether those layers are going to be in the browser I think I don't I don't really I do I do think that WebAssembly right now is a really important piece of this and I think it goes into the being able to bootstrap this and experiment and do that stuff in user space before we have to make decisions about you know working with other folks in W3C about whether there are things we do want to build into browsers that that are you know higher level that sort of builds on extensible web manifesto stuff from from years ago that's my thought for now and we're gonna and we're continuing to add stuff so simd and relax simd both were heavily influenced by by machine learning use cases and I expect more of that getting access to fast things in the CPU and one other pieces that were there's also a speaking of sidecars web gpu is a piece that's being used a lot in this space and so in in chrome and v8 we're thinking about how we can better interact with gpu either through you know lower overhead calls ways of of sharing the memory space so we don't have to do copies that's the way I mean at least from the v8 perspective that's how we're thinking about ML I think from the chrome perspective and the product web platform there are interesting questions about can we add something higher level do we have other questions hey yes so this is like a area that has had a lot of history in terms of like proposals and I'm not probably the best person to like go over all the different iterations of it what I can just say is like from Mozilla's perspective there's the very first thing is like today if you have web assembly and you want to call a DOM API you can already do that with a lot of tool chains like if you're on rust you can use wasm buying gen I think with M scripts and you can use an M scripts and thing and so it's already possible to do a lot of this stuff and we've also done a lot of performance optimization to make when you cross between javascript and web assembly as fast as possible and so there's a couple angles that when I hear this question I wonder is it is it ergonomics like is it that the tools are painful to use is it performance that these tools don't like the cold the code that they have isn't fast enough or because it's not to my knowledge something about expressivity because I think you can use any API today from what assembly so when it comes to ergonomics I have not heard anything that makes it sound like this is something that's really pressing and then when it comes to performance I would love to hear more data on that so that's been sort of my stance on it and I think we could totally add new features to like web assembly to make it easier to call DOM things but they need to be motivated by like especially performance because it already seems like it's something that's feasible today so in particular my understanding of this is that one of the key bottlenecks for DOM interaction web assembly is string manipulation which is a topic that I think everyone here is aware we've been talking about quite extensively in web assembly ways to make string manipulation especially in interfacing with JavaScript faster so it's an active area of discussion especially over the last couple of months and GC is the first step towards this and we know more will come in future yeah it's a little bit I mean it could also be like a chicken and egg thing like if I don't know if there's people out there who don't even try and do this because it's just so terrible that they don't even try or I also don't know if it's just actually it's just fine and so this is an area where like I always appreciate community engagement and there's it's kind of hard because the avenues for it that I know of is right now is you can file like a bug for Mozilla you can file an issue for Chromium or by the kid or you can like show up to like the web assembly standards process which is almost sort of like a alien culture if you've never been around it before but yeah I appreciate anyone reaching out with like you know real concrete things of like I want to do this and it's really slow because it's something like web assembly specifically does and so that'd be really helpful yeah so feedback and joining the community group is a great way to get involved but all of these projects are also all open source or open standards and I think that's really important to highlight David do you mind mentioning where the people could get started with what you work on as in like if they wanted to communicate with WebKit in some way wanted to contribute yeah um oh gosh I probably should have looked at the full like documentation for this there is if you go so WebKit is fully on GitHub you can see all the WebKit source including JavaScript core which as part of that contains our web assembly engine as part of that we have some documentation on how to contribute you can also reach out in terms of there's an open source Slack that I believe is linked from there and we all you know on my team and you know other other people on WebKit I'll check that pretty often so I think if you want to reach out probably that Slack is a good place if you want to contribute I mean we have like we have a public bugzilla you can look through there you can ask on the Slack if there's anything in particular you want to contribute to and there is there is a bit of a process that I don't remember all like 100% of the details for for you know getting a little bit more status in terms of like being able to commit more freely but uh yeah you definitely can so if if any of you are interested in contributing towards you know WebAssembly features in WebKit it's definitely open do we have any other questions from the audience if not I think we just finished exactly on time so good work everyone thank you