EPISODE 1727

[INTRODUCTION]

[0:00:00] ANNOUNCER: The Google Sheets calculation engine was originally written in Java and launched in 2006. In the early days of the product, all calculation happened on the server. However, starting in 2013, the engine has run in the browser using JavaScript. Google Sheets is now one of the first products at Google to use WebAssembly Garbage Collection, or WasmGC on Chrome. Michael Thomas is the Multi-Platform Lead for Google Workspace, and Thomas Steiner is a developer relations engineer at Google. They joined the podcast to tell the story of why and how Google Sheets ported its calculation worker from JavaScript to WasmGC.

[0:00:34] ANNOUNCER: This episode is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

[INTERVIEW]

[0:00:52] SF: Michael and Thomas, welcome to the show.

[0:00:54] TS: Thank you very much. Glad to be here.

[0:00:55] MT: Thanks very much.

[0:00:57] SF: Awesome. Yeah. Well, thanks for being here. I'm excited to talk to you both. I think about a really interesting subject around WebAssembly Garbage Collection, and so forth. We'll get into the details there, but I want to start by digging a little bit into your background experience. Starting with you, Michael, I know you're the multi-platform lead for Google Workspace. You've been at Google for quite a long time, 16 years. Can you give a little bit of insight into what your day-to-day look like? Also, I'm sure things have changed a lot in the 16 years that you've been at Google. If you have some interesting things to share there in terms of the changes that you've seen and evolution of Google, I would love to hear it.

[0:01:34] MT: Yeah, definitely. Well, I mean, to start, I think I'm here in New York City and the New York office. When I first joined, it was something like, one-tenth, or one-fifteenth the size that it currently is. I've watched the office grow up, I've watched the company grow up and lots and lots of things are very, very different. My day-to-day, we have a number of different projects going on in workspace around multi-platform code sharing. The WebAssembly stuff that we've done for Sheets was one of those projects. I'm running around, coordinating a bunch of stuff, sort of difficult to say what a typical day looks like.

[0:02:07] SF: Okay. Thomas, you also have been at Google for, I think, 16 years. I saw that your time there had overlapped with you doing a PhD in postdoc. I was curious, how did you navigate being, essentially, a student doing, presumably, some heavy stint into research while also working at Google?

[0:02:28] TS: Oh, that's an interesting story. Yeah. I've been with Google for a long time. I joined while I was still a student in 2005 as an intern. I did stuff on the AdWords API, that apparently was okay enough that they decided to hire me as a temp during my studies. I finished my, well, I'm pretty old. Nowadays, it would be a master's. Back then, it was called Diploma. I finished my diploma, which gave me the enter ticket to then join Google full-time in 2007.

Yeah. Then I worked a couple of years still in the broader ads teams, still working on AdWords API stuff. Then after a while, got a little bored maybe is a hard word, but I got interested in doing more. I was shopping around for PhDs and I found an advisor that was happy to work with me. Coincidentally, at that particular time, Google had engaged in EU research projects, but they failed to actually find people to work on those, which is absurd. The thing is, EU research projects tend to work for three years or so. Google planning is typically by quarter. Yeah, there was definitely some conflict with long-term versus short-term planning.

Long story short, I decided to work on these EU research projects doing my PhD on company time. Then eventually, after doing some more, after the PhD, after doing some more work in the mobile space, joined the Chrome team, which is where I work now on WebAssembly mostly. I'm also focused on some WebAI stuff that we work on heavily these days, very obviously, AI, there's no way around it these days.

[0:04:02] SF: Yeah, absolutely. How long have you been on the Chrome team?

[0:04:05] TS: I switched to the Chrome team, I think in 2018.

[0:04:09] SF: Okay. Yeah, I think one of the interesting things about working in a company like Google, so I spent four years there myself, is when I talked to people who've been at Google a long time, like over a decade, I would ask them, what keeps you here? I think one of the things that they talked about was that they could - if they want to, they can essentially start something, like net new, a new project, even switch from maybe software engineering to product and essentially, wear different hats within a large organization and work on substantially different projects that feel almost a new company, but you're still under the umbrella of Google to keep things fresh each year. I'm curious, as long-term Googlers, is that something that you've experienced yourself?

[0:04:49] MT: I think in my case, there's maybe more of a story arc to it, where I started out as a web developer. Then we were building - workspace has some of those complex web apps in the world, right? We kept hitting the limitations of the browser and then we got into a position where you had to do multiple platforms. That propelled me into the whole multi-platform space, and then all sorts of interesting opportunities have come from that, including collaborating with the Chrome team. For me, I would say, it's not so much that I get to wear lots of different hats. It's more that like, every time I took something as far as I felt I could take it, there was always another opportunity waiting in the wings.

[0:05:30] TS: When I wanted to join the Chrome team, there was no real headcount. Location was a big issue. These days, again, we started having hubs where you can get employed, and it's harder if you're not in one of those hubs. I was in a non-hub region. I essentially did a lot of work for the Chrome team, without being on the Chrome team. I put it a bit bluntly in a blockbuster road a couple of years ago, where I reflected on, I think, back then, it was 17 years at Google.

[0:05:59] SF: Yeah. I mean, it's probably part of the natural evolution of a really large organization. Google 16 years ago was just a completely different company from just sheer size. Even the four years that I went, was there, I think the company doubled in size during that time from 75,000 to 150,000 employees. Even that is a massive change in an organization. You have to essentially, grow up as a company and put certain constraints in place and there's pros and cons with that. I want to talk about this article that we been alluding to, where you wrote about porting Google Sheets calculation worker, from JavaScript to WebAssembly Garbage Collection. First of all, before we get into the details of that project, what is the calculation worker in Sheets?

[0:06:44] MT: The calculation worker, I mean, we call it a worker that refers to the worker thread that it uses on the web to be able to do calculations in the background, so you can keep typing while it's calculating. That essentially functions as a separate web app within a web app. It's an isolated part of Google Sheets, whose only job is to do calculation. In goes the contents of your cells, out comes the contents of your calculated cells. Yeah, does that answer the question?

[0:07:07] SF: Yeah, absolutely. Essentially, this is the execution of a formula, essentially, to update a cell, or something like that. It's a self-contained thing that's writing that up.

[0:07:15] MT: Precisely, precisely. One plus one equals two. Sorting in some cases, conditional formatting. There's a lot, a lot, a lot of stuff that goes into calculation.

[0:07:27] SF: Yeah, absolutely. Obviously, performance is a big factor of this, because you could have a really, really big sheet where every single cell is essentially running and executing a formula and all this stuff needs to be able to stay up to date, while I'm also editing, and I don't want to essentially impact the user experience of the editing process.

[0:07:42] MT: Indeed. It's one of those use cases where because the amount of computation is proportional to whatever their user is doing, you theoretically need an endless amount of performance.

[0:07:53] SF: My understanding of WebAssembly is that it allows me to do things, like port, a language of code written in maybe C, C++, Rust, essentially, these types of languages into a byte code format that I can run on the web, getting near native performance. Projects like Figma, Google Earth, a bunch of other games and things like that use this to, essentially, hit the performance that you might need beyond just a regular web application. Is that a fair understanding of WebAssembly itself?

[0:08:23] MT: I would say so, yes.

[0:08:26] SF: Then in terms of the WebAssembly GC, do you refer to that as WasmGC?

[0:08:31] MT: I mean, I think I actually pressed a bunch of people the other day like, what is the correct technical way to describe this? Is it WasmGC? Is it WasmSpaceGC, WebAssemblyGC? I think it's up in the air. I think if you and I come to an agreement now, we're going to call it WasmGC, maybe that'll stick.

[0:08:49] TS: On the deferral side, I can say very clearly, we have stuck with WasmNoSpaceGC, just because that's, I think, what the explainer uses. Yeah, it's always hard. At least in the article, we try to be in our publication in general, we try to be consistent. I think something that is more important is Wasm is not all uppercase. It's W is uppercase and everything else is lowercase, because it's not an acronym. It's the conjunction of WebAssembly. This is something that is more important for myself to get right as a writer.

[0:09:24] SF: Yeah. Can you describe, essentially, this extension, this WasmGC, in this relation to the original WebAssembly project?

[0:09:31] MT: Sure. To put a little bit of maybe larger context, the way that WebAssembly has been designed is with, I think, a big eye towards simplicity. The original specification for WebAssembly was like, it was it's just a number cruncher. If you can take C, C++, Rust, you can compile that to WebAssembly and you can run it. But anything, like threading has to go through JavaScript. Browser APIs, you have to go through JavaScript. It's really just a very small, very simple, very well-defined number cruncher.

WasmGC is, okay, we're going to take our number cruncher and we're going to give it specifically the capabilities it needs to handle compilation of garbage collected languages. Java's a good example, Dart's a good example, Kotlin's, a good example. Those are things like, well, the garbage collector itself, which I think most implementers are probably going to end up wiring it to their existing JavaScript garbage collectors. If I'm trying to compile a language like Java to WebAssembly and I don't have support natively for garbage collection, I have to emulate it. It's just never going to result in something very performant. It's really something that you need WebAssembly itself to support, to implement it well. That's really what it was, an extension to the WebAssembly specification to give you the instructions that you need to efficiently compile a garbage collected language WebAssembly.

[0:10:50] TS: Maybe as someone who has documented this and tried to document it for the mere models, and I myself, a mere model when it comes to WebAssembly, I think the core thing to understand is it's essentially just a lower-level thing in the sense of things that you need for implementing garbage collection. If you go to the explainer and actually to the repo where they introduced the proposal, garbage collection is not really mentioned in there in the actual spec. It's more like, yeah, it introduces structs and as I said, a lower level of things that you need to implement garbage collection, but not garbage collection itself.

In the article that I wrote for developers who have a web background, I explained it like that, that essentially, you have a language, like let's say, Dart, let's say Kotlin, that you want to compile to the web. Yeah, this language has, of course, code for how do loops work, how do conditionals work, how do whatever work, strings work? It also has code for how does garbage collection work? If you compile that entire language, you have to also compile the code that takes care of the garbage collection. In the browser, you already have garbage collection, as Michael said, from the JavaScript end.

If there were a way to just get away with using that, instead of the language provided one, you could just make the language a lot smaller. That's a simplistic way of explaining how this works. In the end, the actual spec is really just about lower-level concepts that you need for implementing garbage collection.

[0:12:16] SF: Right. Is it taking advantage of the JavaScript engines built in garbage collection, then? Is that the idea, versus actually trying to -

[0:12:24] MT: The specification doesn't say how you implement it, right? But if you're a browser vendor and you've already got a really, really tuned garbage collector for JavaScript, I think you're incentivized to reuse that for WebAssembly. But maybe in the future, maybe you would want to bifurcate them, I'm not sure. But the specification doesn't care how the browser implements it.

[0:12:44] TS: Yeah. I guess, if you have a Wasm runtime that is implemented in some language that already has garbage collection, you could well use that. If you think of maybe an embedded context, where you have an optimized runtime that is optimized for running on embedded devices, and this language happens to have garbage collection, you could also use that. It's completely distinct from how you actually implement it, versus how it's implemented on the web.

[0:13:11] SF: Okay.

[0:13:11] MT: Yeah. Maybe two interesting notes there. One is, like Thomas alludes to, garbage collectors are one of those things that require a lot of tuning, typically tuning for the platform that you're on. The way a garbage collector behaves on mobile might be different than one behaves, like if it knows that it's in a desktop situation. Another situation is that for the purposes of interoperation between WebAssembly and JavaScript, I think having them both be backed by the same garbage collector, maybe at some point makes that easier, or more efficient. But I'm drifting out of my lane a little bit with that. I'm not quite sure.

[0:13:45] SF: I see. What was the motivation around this project? Why make it so that languages that do use garbage collection can, essentially, take advantage of compiling into WebAssembly by code?

[0:13:58] MT: The answer is performance, right? The calculation engine has always been written in Java. The way that we run it as JavaScript is we have a Java to JavaScript transpiler. We spent a decade optimizing the JavaScript performance. We hit a ceiling a long time ago and we're looking at this and we're saying, where does the limitations of what JavaScript is capable of doing? We've known for at least a decade that JavaScript executes the calculation engine three times slower than, for example, the JVM can execute the calculation engine. We know there's a huge amount of headroom there, but we had no way to capture it, because JavaScript is holding us back.

WebAssembly, well, theoretically solved this problem, but initially, it only solved this problem for non-garbage collector languages. WasmGC, well, now we can just write a Java to WasmGC compiler and boom, JavaScript is out of the way, performance doubles overnight.

[0:14:52] SF: Is that an easier path than say, rewriting the calculator code into something like C++, where you could have taken advantage of WebAssembly without this additional compilation to support GC languages?

[0:15:04] MT: Yeah, definitely. I mean, so the history is interesting. We could have started out, how many years ago it was when the sheets code base was started. If we'd written in C++ from the beginning, we would have just used WebAssembly and we never thought about it. But because it was originally executed on the server and the servers at the time were all written in Java, the calculation engine was written in Java.

Now, rewriting a very large, very intricate, very performance sensitive, very correctness sensitive piece of code from Java to C++, where if you're going to go from one garbage collected language to another, you can maybe automate a bunch of that. If you're going from a garbage collected language to a non-garbage collected language, I think it's much more like almost rewriting from scratch. That would have taken a long time to do. It would have taken a long time to validate, and the, however many engineers you have working on it all have to be retrained now in C++. While this is all happening, all feature development needs to stop for the two or three years that you spend doing this.

Yeah. By comparison, WasmGC, we ported the thing to WasmGC maybe in six months or a year with only a handful of people, while the main team kept building features. There was no slowdown in the future velocity from the perspective of our users. Then you get the performance essentially for free. No one needs to be retrained. Nothing needs to be rewritten.

[0:16:30] TS: The other big customer inside of Google was the Flutter team. Flutter is Flutter apps are written in Dart. Before WasmGC, they compiled from Dart to JavaScript. By compiling to WasmGC now, they've unlocked massive performance as well. I guess, the Google Sheets team and the Flutter team were the big internal drivers for why we made this happen.

[0:16:52] SF: Okay. Yeah, that makes sense. You said that you knew even a decade ago that you were going to hit the limits in terms of what you could do from a JavaScript performance perspective. How does that manifest itself in terms of the user experience when you're starting to hit that limit?

[0:17:08] MT: I mean, when it comes to calculation, if you have a very large spreadsheet and you make a change and it causes a big recalculation, you can be waiting many, many seconds in the largest spreadsheets. I mean, it's plainly visible, just wall clock time you're just sitting there, waiting.

[0:17:23] SF: Okay. Yeah. You can actually see the delay apparent to the user. You mentioned that with WasmGC, you're not necessarily, you specifying how garbage collection happens. It's up to the person who's implementing it. How does it work in this project that you worked on? Is it taking advantage of the JavaScript garbage collection? Or did you do something else?

[0:17:45] MT: How the garbage collector is implemented is up to the browser vendor. In the case of Google Chrome, that's the V18. My understanding is that they're using the exact same garbage collector that they use for JavaScript. Again, slightly out of my lane, I would expect that all browser vendors would at least start by just reusing the same garbage collector that they already have, they've already tuned for the platform. I don't think there's anything in the specification that says, you have to do it that way. That's just the obvious way to do it.

[0:18:13] SF: Okay. In terms of this project, as you were building this out and you're doing this porting, what were some of the major technical hurdles that you ran into?

[0:18:21] MT: Oh, gosh. A lot. I mean, one of the things was initially, we had a way to measure performance of documents. But because of privacy concerns, we're not allowed to look at anyone's documents. We're taking all of the documents written by Googlers, for example, right? Well, we don't have permission to see that document and that document is slow. Well, we can't open up the document to find out why it's slow. We have to reach out to the person like, "Hey, fellow Googler, we're trying to optimize this and we found that your spreadsheet is slow." There were cases like that, where it was just a matter of understanding what was driving performance and getting a hold of good examples of them, that was a big problem.

The implementation, I mean, where to begin? Whenever you port something to run in a different way, a huge chunk of the code, it's just code, and so it ports over pretty quickly. But then there's lots of libraries, which are specialized in various ways and specialized for the previous platform, you have to go back and rewrite those libraries. One example that we ran into was data structures. In the JavaScript language, all objects are hash maps and arrays are hash maps. Therefore, all arrays can be treated randomly as a hash map if you want to. JavaScript engines have to be able to handle that performantly, because people tend to blur those lines. That's not true on, basically, any other platform. But we had data structures that had been optimized to take advantage of that.

Then when you port that over to WebAssembly and you start running it without JavaScript behavior, it's way, way slower and you don't understand why. There were also interesting things, like the regular expression stuff, I think, we mentioned in the article, where you realize that WebAssembly is faster than JavaScript, but WebAssembly is not faster than browser APIs written by the browser vendor, optimized in C++ and exposed to JavaScript, right? Regular expressions, we started out by just taking a regular expression library written in Java, compiling it to WebAssembly, and it was unbelievably slow. Then we realized like, oh, wow, the browser API, at least in Chrome, is unbelievably fast. It's a very, very impressive regular expression engine. And a hundred more things. I could talk for two hours about the challenges. It took a long time to build it.

[0:20:39] TS: Maybe one interesting ally could be the string graph thing built in strings, where you make use of the strings inside of JavaScript as implemented by JavaScript, which is something that you said is similar to regular expressions. I was interviewing Ryan Hunt from Mozilla yesterday, who is actually the champion of the built-in string proposal. One of the things that the built-in proposal has designed in, is that it can be extended. Regular expressions is one of these examples that they mentioned. Maybe, Michael, you want to talk about strings?

[0:21:08] MT: Yeah, strings is another interesting example. I think what drove it was the calculation engine, again, it lives inside of a worker. It takes in, hey, this is the state of the spreadsheet and these cells need to be recalculated and then it does its work and it spits out the calculation. All of that is serialized, going back and forth between the main thread and the worker thread. It's serialized, I think it was initially serialized to a string, not sure. That's one case. Another case where with regular expressions, well, regular expressions are expressed as strings that we've got to call out to JavaScript and we got to pass strings back and forth, there's another place we're putting a lot of pressure on strings.

Ultimately, we come up with the idea, well, okay, coincidentally, Java and JavaScript have the same string implementation under the covers. They're compatible with one another. If we just, instead of re-implementing strings and compiling them to WebAssembly, if we instead just reuse the string implementation in JavaScript, which is already optimized, then we can save ourselves all this marshalling back and forth between two different string implementations.

A couple of different approaches emerged. One with string references, the other is imported strings, and then some other hacks and stuff like this. We ultimately, we settled on the imported strings. I think the overall performance of the calculation engine was improved by something like 10%, I think just from this. It turned out that that was - that and regular expressions were both huge optimizations that made everything faster.

[0:22:42] SF: I mean, it sounds like, you're just comparing directly, like WebAssembly versus JavaScript. WebAssembly is going to be more performant, but there's certain things within JavaScript that had been really, really tuned over the years, like the use of hash maps, the regular expression engines and stuff like that, because of they're probably used a lot in JavaScript and it made sense to optimize them and then the connection to the browser executing some of that stuff. Going back to the hash map issue, how did you end up solving those performance issues for that?

[0:23:12] MT: Well, you just make a proper data structure. The whole thing in JavaScript, where everything is a hash map, I think that if the author of JavaScript were here with us, I think he would admit that that was maybe not the best design decision. It let JavaScript be implemented very quickly. There's a simplicity and an elegance to it. When you want to write really optimized data structures, it's a bit of a strange choice and it's a choice that I don't think any other performant language has ever made.

What you do is you look at your data structure, you realize that you're abusing the system in this way and you didn't notice, because JavaScript has to handle that well. Then you just define the data structure correctly. If you want a hash map, use a hash map. If you want it to behave like an array, use an array. If what you really need is a sparse array, a data structure that mixes the behaviors, well, write a data structure that does that. Then, also mentioning regular expressions and strings, I wouldn't say that JavaScript has really fast implementations. I would say, the browser has very fast implementations, and those implementations are currently only exposed via JavaScript. If you want access to the super-fast regular expression engine, you have to ask JavaScript for it.

Again, that comes from this idea that WebAssembly is just a dumb number cruncher, right? It's not the thing with a million connections to the outside world. It's a little bitty number cruncher that doesn't know about anything else. I hope that changes over time. It's a little bit awkward that you have this amazing number cruncher and it has to go and hand a JavaScript and ask permission to access the regular expression API.

[0:24:52] SF: Do you see a role for WebAssembly to play beyond just being this pure number cruncher? There's certain beauty and elegance in terms of really confining what it is designed for, but do you think that as web applications continue to get more and more complicated, there is a role for WebAssembly to play a bigger part?

[0:25:13] MT: Oh, definitely. I mean, I personally have very high ambitions here. The following is my opinion and not necessarily everyone will agree with me. First of all, I don't want to state it incorrectly, WebAssembly is designed to be a small number cruncher, because I think that that's the way that - it's very easy to get agreement. If we limit the scope of it and say, "No, no, no. Let's focus on this." Then I think it's easier for the specification to move forward.

Whereas, if you try to be all things to all people from the beginning, then there's a million different things to argue about and it's difficult to make progress. I don't think that WebAssembly is designed to always be this way, but it's definitely how the first couple of iterations have been. We'll see where it goes in the future. If WebAssembly all of a sudden is being used as much as JavaScript is being used, I think you would see the tune change there.

Now, what else can WebAssembly do besides crunching numbers? I think about WebAssembly as it opens up any language to work on the web. Up until WebAssembly came out, the only language that works on the web is JavaScript. If you go to any other platform, that's not the case, right? If I'm developing on iOS, I can use Objective C, I can use Swift, I can use C++, I can use C, I can use whatever language I need to get done what I'm trying to get done. Same for Android, where you can use Kotlin, or Java, or C. Same for Windows, where you can use any language imaginable. You have all of these different options. On the web, there was a one-size-fits-all situation. There was just JavaScript.

[0:26:43] TS: Let's not forget one thing. WebAssembly is not just web anymore. There's a lot of WebAssembly on the server as well. There's a lot of cloud startups that want to do WebAssembly stuff. They open up WebAssembly massively with WASI, there's a component model. I think coming from the original MVP, as they called it, implementation, we've really come a long way now where people use WebAssembly a lot more on the web.

Right now, I think, technically, a server might actually have outgrown the WebAssembly usage. I don't have any hard numbers, but just looking at recent conferences, there was a lot more server talks than there were web talks.

[0:27:22] MT: Right. On the web, I think that it's not just about it being a number cruncher. It's about letting the web platform grow up and have access to multiple languages to efficiently address multiple different use cases. For Google Workspace, we're not writing a web page. We're not writing some small web app. We're writing multi-million-line enterprise grade productivity applications. WebAssembly is - well, I'm sorry, we don't want to write in JavaScript. We've had to write in JavaScript. We will be very happy to switch to another language that can do all of the things that you need for those heavy-duty use cases. I think that's one big change.

Then also, there's what Thomas alluded to, right? WebAssembly, it's not just a number cruncher for the web. It's a specification for how to efficiently execute code in a performant and safe way. That's going to have applications potentially in a number of different areas. There are people that are very interested in, for example, running small little one-off functions as WebAssembly, because WebAssembly can be safely run. The startup times can be very, very fast. There are lots of different places where the technology, I think, will be useful. I'm less of an expert on those areas, but I think that's definitely going to be a big part of the WebAssembly story.

[0:28:38] SF: I think you raised a really interesting point around JavaScript being this one language, basically, since the dawn of the web as our main entry point for building applications. It's bonkers to think that. I think if you went back to probably, I would guess, we're all in a similar age bracket, to the beginnings of our careers and you thought like, okay, JavaScript's going to become the dominant language in the world, and we're going to be building these super complex applications written predominantly in millions of lines of JavaScript, that would be a crazy thing to think about. That's a world that we've gotten to.

At some point, it's a question around how sustainable is that? It's not necessarily a language that was designed to do that stuff. It was like, how do you add interactivity to a basic web page and it's grown and spiral from there?

[0:29:24] MT: Yeah, absolutely. I mentioned before, a big part of my arc at Google was I showed up. We were building Google Docs. We started doing things and Gmail before us as well. We started doing things with JavaScript that no one had ever really seen before. I think at the time, my mindset was like, "Wow, JavaScript is this super flexible language. It's the solution to this multi-platform problem. We can do anything with it." Then after maybe seven or eight years of building productivity applications using just JavaScript, I became intimately familiar with all of the downsides. Can you do it with just JavaScript? Yes, you can, but it's like fighting with one hand behind your back. There are languages like Java, languages like Kotlin, they really do provide things that make development a lot easier.

Then when you get to multi-platform, well, if I write in JavaScript and I want to run that on an Android phone, or an iOS phone, that's never going to be super performant, right? I graduated from viewing JavaScript as the solution to viewing JavaScript as the problem for these more intense use cases that have defined my career.

[0:30:33] SF: Thomas, did you have anything to add on?

[0:30:34] TS: I think this captures really well. I guess, part of the response is also, so often, industry response is also, TypeScript in Google, we have closure compiler for the longest time. I think it's just about this month or so, deprecated it. Essentially, the idea was, yeah, let's somehow fixed the bad things of JavaScript. Let's make sure that we can, I don't know, have proper modules before modules became native to a JavaScript. This was really, really early days when, yeah, as Mike was saying, Gmail really pushed the boundaries of what could be done with JavaScript. I guess, yeah. Moving to other languages, or at least moving to TypeScript or something is part of the industry response there.

[0:31:15] SF: Yeah, absolutely.

[0:31:17] MT: Yeah. TypeScript is a big part of the solution. TypeScript solves a lot of the, well, so first of all, Type Safety is obviously much better. IDE support is much better. But it doesn't solve the multi-platform problem. TypeScript adds basically nothing when it comes to performance. Because under the covers, you're still limited by what JavaScript can do. The other reason why we graduated from doing everything at JavaScript is when you get to other platforms, JavaScript's just not good enough. On the web, it's your only option. On other platforms, there's no way you'd want to deploy things with JavaScript.

[0:31:51] SF: I wonder if something like this does start to become more widely used. Because I wonder if it helps solve some of the problems that we see in the JavaScript web development world of like, essentially, if you go back 20 years, essentially, the way we built web applications is the front-end didn't do a lot, and everything was on the backend. Then at some point, we shifted dramatically to doing, like we had the single page app era where essentially, everything was happening on the front end. Then that became a problem where maybe mobile performance wasn't where you wanted.

Now we're seeing the shift back to people rediscovering the fact that, oh, we have these beefy servers that can actually do stuff, and they're moving more and more code to server. We ebbed and flow between front-end and backend to try to solve this problem. But maybe, fundamentally, the problem is more to do with the limitations of what you can essentially do on the front-end in a reasonable way.

[0:32:46] TS: I think an interesting story there is the hybrid model. Recently, I heard a podcast, Browser Tech Podcast, where they had a guest from Row Zero. They built Google Sheets competition. What they did is really a hybrid approach, where they would stream, essentially, everything's cells related from a server. Then they would run the UI locally in classic DOM. The stream stuff would be just rendered inside of it in a canvas.

I guess, yeah, that's an interesting side track here to also take, because yeah, we have mobile devices, we have entry-level Android phones. You still probably sometimes have this need to open a million rows spreadsheet on the go to just fix one line, one cell, whatever. I guess, that's an interesting in between development here that we have to.

[0:33:34] MT: I had a couple of thoughts for you. One is, we're talking about where is WebAssembly going to go in the future and how we see different use cases being addressed in different ways and different architectures. I think that you're what you're going to see is you're going to see probably toolkits and frameworks being developed to build bigger applications in other languages, being backed by WebAssembly. Again, instead of one language addressing every use case, you're going to see some chunks cut off of what JavaScript addresses as other languages on the web get better at addressing those use cases.

Then two, there's this concept of multi-platform, right? From our perspective, so workspace, we're not just deploying things to the web, right? We're deploying things to the web, to Android, to iOS. We tried deploying with JavaScript, and you can do that, but there are lots of downsides, especially if you really, really care about performance. WebAssembly to us represents, okay, we can now finally have a better build target for the web from our multi-platform footing, right? Because we were already on a multi-platform footing, it was pretty easy for us to switch from JavaScript. I mean, pretty easy, it still took years, but it was pretty easy for us to switch from JavaScript to WebAssembly.

If you have a big JavaScript application today, switching to WebAssembly is not trivial. Because the limitations are in the language. If you want to use WebAssembly, well, the first thing you've got to do is take all of your code and convert it from JavaScript to some other language, clean up all the issues with it, then you can compile to WebAssembly. It's very complicated, I would say.

[0:35:11] SF: You had the advantage, where you had built, essentially, a server-side component originally in Java, and then you built, if I remember correctly, a way to convert that into JavaScript that you could run on the front end. Essentially, you swapped out that compilation process from Java to JavaScript, to Java to WebAssembly.

[0:35:29] MT: Yeah. I feel like, at this point in my career, I've done every permutation of this. Google Docs was actually originally written in JavaScript. We converted the entire Google Docs code base from JavaScript to Java, okay. Google Sheets was originally written in Java, because the calculation engine written on the server. We then transpiled it from Java to JavaScript to run on a client using Google Web Toolkit. What we've learned in all of these different moves that we've made is if you get your code written in a good language that can be deployed in multiple locations, well, now you can support any application architecture. Any code you have, you can run it on your server, if that works better in certain situations. You can run it on the client, if that works better in certain situations. You are in a fully flexible footing to run any code in any way on any device, depending upon what's best.

For example, with docs we render the document on the client, right? There's a document rendering engine that runs in the browser. On slower devices, maybe, maybe the server can render the first page of the document faster than we can load the renderer on the client and render the page. Well, so that same rendering engine is written in Java. It can also run in our server. This repeats itself all over the place. That's a big, big, big lesson that we've learned is get yourself in a flexible situation. Then no matter what comes down the pipe, a new device comes along, a new form factor comes along, a new architecture comes along, you're positioned to do well.

[0:36:59] SF: Yeah, absolutely. I want to get back briefly to the project at hand, so this porting project. I guess, what's the state of the project today? Then also, what were some of the performance improvements that you saw once you got to a place where you could actually start to test things?

[0:37:14] MT: It is in 100% of production today. As far as I know, if you are running Google Chrome, you have the WebAssembly version of Sheets, all users everywhere. The day we got the WebAssembly version of the calculation engine working, we fired it up and we had maybe a dozen or so, test sheets that we do performance testing with. Fired it up, we run all those sheets, and it is exactly twice as slow as the JavaScript version, which is not bad, right? It was like, "Oh, wow. Okay." Then we did, I think we, we optimized for a solid year. Then by the end of that year, it's essentially straight up twice as fast. I think for in almost all cases, in any way that we would aggregate it anyways, it's just straight up twice as fast across the board.

[0:38:02] SF: When you saw that it was two times as slow as the original implementation on that first test, was that a surprising result? Were you expecting that from the get go that you would actually have achieved higher performance?

[0:38:14] MT: Not really. I've played this game before, where I'm porting things to other ways of executing. I've seen 10X slowdowns before. At 2X slowdown, I was like, "That's not bad."

[0:38:25] SF: Then, I guess, in terms of getting now 2X performance improvement over the original system, do you think that that is - have you hit the limit of performance with this approach? Or is there still places where you can continue to optimize?

[0:38:38] MT: We specifically think we have not hit the limit. We essentially optimized until we hit our target and then we launched. We would have liked to keep optimizing. We think that the low hanging fruit has been exhausted. If you think about it, so now, I think that we're - I forget what the percentile is, but we're within striking distance of executing Java code as fast as the JVM does, right? The JVM is the gold standard for executing Java. The open question is, can we reach, or even exceed the JVM's performance? Unclear. You have to remember, the JVM has been optimized for 30 years, something like this.

[0:39:18] SF: At least.

[0:39:19] MT: We've optimized for one, one and a half. But we also recognize that it's going to be very, very small improvements from here on out. There's other big features to add. For example, shared memory multi-threading is not something that works with WasmGC yet. I think that's going to be really helpful. There's other features that can be improved, but just for straight single-threaded performance, I expect to see it very slowly improve and probably, asymptotically approach JVM performance. That's roughly what I expect.

[0:39:51] SF: For people who are listening and are interested, what is the best way that they can potentially get involved, or even try some of the stuff out on their own, like in terms of WebAssembly?

[0:40:00] TS: We have documentation on vite.dev about WebAssemblyGC. I've written an article for developer.chrome.com on WasmGC. Essentially, it is something that very, very few people will actually do themselves. Compiler experts, language experts would port a language like, let's say, Dart. I think this is where the real scaling effects then come. Because then you can have people who write code in Dart and they can just hit this button that WasmGC enables and have their Dart code run performantly on the web.

If you really want to get started with WasmGC, I think that's not something that a lot of people would do. That's completely out of my comfort zone for myself as well. It's more like, we want to get those tool chains into a position where they can just do the job, compile those languages that are garbage collected, that are managed to WasmGC. Then as a user of those languages, I don't really have to care about like, how does it work under the hood? I think this is more where the actual scaling that happens.

[0:41:03] MT: Yeah. I would add to the list thing of things there. Kotlin also has WebAssembly compiler. It's not like an individual dev trying to make an individual website. Should probably jump on WasmGC. But keep a lookout for compilers coming available for other languages. If you don't want to learn JavaScript, well, your language of choice will probably be coming to the web in the relatively near future.

[0:41:28] SF: Absolutely. I mean, I think that makes sense. Not everybody's going to get into writing their own compiler. Although, for those people that are interested, it sounds like, there could be some opportunities to deport your obscure programming language over.

[0:41:38] MT: For sure. Just quick shout out, writing compilers is a lot of fun. I think people think it's scary. So much fun. Languages are a blast.

[0:41:47] SF: It's also a great way to, I think, really learn in depth how programming languages work is try writing your own compiler.

[0:41:55] MT: Absolutely. We talk about these, what optimizations do we have to make? It's like, well, if you think about how a language is structured, and then you're going line by line of that language and you have to interpret the line and then map that to WebAssembly instructions. Once you've gone to that process, you will understand whatever language it is better than anybody else you know. It's been a wonderful experience for me learning that stuff. I think it just gives you a better understanding of computer science in general. I recommend it to everybody.

[0:42:25] SF: Yeah, absolutely. As we start to wrap up, is there anything either of you would like to share?

[0:42:30] MT: I guess, yeah. Look at use cases that WasmGC unlocks. As mentioned before, Flutter makes use of WasmGC now. If you're ever considered writing a Flutter application and you wanted to bring it to the web, now might be a good time to try that again. I think that's probably a pretty exciting segue into also, then Kotlin. Kotlin allows you to some extent take Android applications and port them to the web. There's still a very long distance from actually just pressing a magic button and it working on the web if you have an existing Android app.

If you want to just start, run something relatively simple, I think now is a good time to get started. The JetBrains team, they're pretty eager in fulfilling this mission that, yeah, in the end, you have JetBrains multi-compose, where you can write your UI in a, I think, declarative way. Then your Kotlin code would do the wiring, so that the actual UI does something. There's a couple of very interesting, yeah, just examples out there, the Kotlin team have provided. This just uses WasmGC in the background. You don't really, really know that you're dealing with that.

I guess, as a regular developer who comes from a Kotlin, who comes from a Dart, Flutter, whatever background, I think this is where you can get in touch with WasmGC without really, really realizing.

[0:43:48] MT: I would echo that same sentiment. For me, personally, WasmGC is this final component that makes the web work way, way better in a multi-platform context. I do a lot of stuff with multi-platform. Google has both Flutter and we're supporting Kotlin multi-platform. Both of those give you a set of tools that allow you to develop for Android, iOS, and the web at the same time. WasmGC makes the web part of that so much easier to support, and so much more performant, and so much easier.

Before, we're compiling for Android, building for Android, building for iOS, or relatively straightforward, and the web has always been this special snowflake, because of the limitations of JavaScript. WebAssembly, specifically WasmGC is lifting that restriction. I think in the coming two, three years, you're really going to see a rise in popularity of these multi-platform ecosystems being used more regularly on the web, because the experience is just going to be way higher quality.

[0:44:55] SF: Well, Thomas and Michael, thank you so much for being here. I really enjoyed this. Thanks for that wonderful blog post that goes along with this conversation. I encourage anybody listening to check that out, and some of the other things that Thomas has written on the subject.

[0:45:08] TS: Thank you very much for having us.

[0:45:09] MT: Thanks very much for having us.

[0:45:11] SF: Cheers.

[END]