In this episode, Surma talks about the “GPU” in “WebGPU” and how this new web standard makes programming for the GPU more accessible. Jake talks about how different browsers approach standards and their perceived ideologies around what they prioritize.
Surma:Dude, we can technically... Well, we could swear now on OTMT. I think so far I have selected that
Surma:this podcast is clean. I don't know what the different guidelines are, so I feel like
Surma:I may have to revisit that choice.
Jake:Oh. I think we can stay... So here's the thing, like, in our previous podcast, for
Jake:the last few episodes, I was doing the edit, and I'm sure there was an easier way to do
Jake:it than I was doing it, but bleeping stuff out was a lot of effort. So that's why I didn't
Jake:swear. Because every time I, you know, if I was about to swear, if I felt like swearing
Jake:was justified, I would just feel like, no, this is effort if I do this, so I'm just going
Jake:to pick a different word. And then every time you swore, I was like, ugh, I rolled, because
Jake:ugh, I'm going to have to find that, I'm going to have to bleep that, thanks, I'm a great
Surma:Yeah, you know, I was... And I knew this. I was just going, you know what? Fuck you, Jake.
Jake:I don't care now, so fuck you too!
Jake:Yeah, we're back, after over a year. Hello, I'm Jake Archibald. This is where you come in, yeah. Yeah, and we are
Surma:Oh, this isn't... Yeah, sorry. I'm Surma. Well off the main thread.
Jake:no, no, we're not, we are off the main thread. Because Google wouldn't let us keep the name.
Surma:So good.
Jake:Right, yeah, it's a clever name, isn't it? Because it's, it's, it's a, because, because
Jake:of like workers, right, it's off the, you know, there's the main thread, and there's the,
Jake:the other, you know, it's very smart, but also, oh, we go off topic, we're off the main thread,
Surma:Yeah.
Jake:we're a bit zany, a bit mad, yeah, you know, whatever, okay, it's a new, it's the new name,
Jake:that's the name we picked. Okay, I really hate people who define themselves as quirky. Anyway,
Surma:So quacky.
Jake:let's not get sidetracked too early, because in this episode, we're going to talk about,
Surma:Yeah, well, it's... I feel like we've talked about this before,
Jake:we are going to be talking about web GPU APIs, is that right? Excellent.
Jake:Yes, it was a one we recorded late in the Google era, that never quite, never quite made it out.
Surma:but I also feel like that episode has never seen the light of day.
Jake:But also, later in the episode, I'm going to be talking about the differing ideologies of
Jake:the browser engines, and how that impacts the kinds of features that make it onto the web
Surma:I'm sure it's not going to be inflammatory at all.
Jake:platform. That's our intention, anyway, but, you know, I think, I think it's fair. But yeah,
Jake:we're not at Google anymore. So, I mean, not that we were ever singing from that particular
Jake:hymn sheet, I'm losing the metaphor. Do you know what, someone, someone at Shopify messaged me
Jake:last night, saying that, you know, we need to be careful with some messaging,
Surma:Ah, I like stirring the boat.
Jake:because we don't want to stir the boat. I like stirring the boat as well. So,
Jake:like, they did, they did acknowledge that it was 6am in their time zone. So,
Jake:I think you can forgive them. But I love that as a as a little mixed metaphor there.
Jake:Um, exactly. But I thought, like, you know, first episode, let's, let's get,
Surma:Yeah, you can just shave them all over one hat.
Jake:let's get straight into the tech stuff. So, shall we talk about the web? I do.
Surma:You want to talk about the web? All right.
Surma:All right, so web GPU. Actually, you know what? GPUs. And actually, you know what? Low-level stuff.
Surma:It's not everyone's cup of tea, but I've been thinking about this a bit, and I feel like
Jake:Hmm.
Surma:I've been starting to think about developers as bottom-up and top-down coders. You know, this
Surma:whole bottom-up versus top-down, I think it permeates all of software engineering.
Jake:Yeah, I do know what I completely agree with you and it's one of the things that I have
Surma:But I feel like before I use something, I want to understand it and kind of do a depth-first
Surma:search so I understand what is happening there and have an appreciation for it. And then there is...
Jake:going into a new company, because I am now also at Shopify, it's the thing I've struggled with.
Surma:Yeah, just lie to yourself.
Jake:I feel like I can't do anything until I know a certain percent of the thing.
Jake:I think it's mostly perceptual. I need to feel like I know 20% of it,
Jake:even though I probably will only know 5%, but until then I can't get anything done with it.
Jake:And yeah, well, but WebGL is one of the things that I never gained enough confidence in to be
Surma:Right?
Jake:able to do much. I built like two demos in it. I always wanted to do 2D stuff with it.
Jake:Although WebGL was never my cup of tea, as you put it,
Jake:I want WebGPU to be my cup of tea, even though I don't like tea.
Surma:And you know what? I think we can get there. But anyway, I kind of realized that... So I would say
Surma:that, you know, similar to you, we are kind of like the bottom-up. We like to understand the
Jake:Hmm. Ironically, the leaves are at the top of the tree, but whatever, we won't.
Surma:leaves and build stuff on top. And then there's the people who are... Yeah, in the good old days
Jake:Yeah. Yes.
Surma:when trees were growing from the top to the bottom. But then there's these top-down people who are
Surma:not only happy but also really good at using something without digging under the hood and
Surma:like somewhat frustrating you. Those are the people that get done. Those are the people that
Surma:finish projects. And I think everybody is somewhere on this spectrum and nowhere is really
Surma:at the extremes of it because, you know, otherwise you have to go full Carl Sagan to, like, to bake
Surma:an apple pie. You would have to invent the universe. And so, like, you know, I've done...
Surma:I've written assembly by hand because I like low-level stuff, but I do not know how a transistor
Surma:works, like, in detail, for example. So I think everybody has somewhere where they draw the line
Surma:of how deep they want to go. So I think it's similar to you. I want to make use of GPUs.
Surma:They're there in your device and they're, you know, kind of like a bit mystified but really
Surma:powerful. But then when you look at stuff like OpenGL or WebGL, like, it just didn't click for me.
Jake:Hmm.
Surma:And then I, in the periphery, kind of learned, you know, like these new next generation graphics
Surma:APIs are coming around, like Metal, DirectX 12, Vulkan, and they give you even more low-level access
Surma:to the GPU. You genuinely program them rather than drawing triangles, which was a bit the
Surma:perception I had beforehand. Yeah, I mean, shaders were a thing, but still they were very
Jake:Are you talking about like the existence of shaders? Is that when you say programming the GPU?
Jake:Hmm.
Surma:predefined slots, you know, like you had the vertex shader and the fragment shader,
Surma:one runs on vertices, the other on pixels. And if you weren't trying to use the GPU for something
Surma:that uses vertices or pixels, what do you do? And always felt a bit odd. And also,
Surma:I don't know, it just didn't really click. And then these new API, these new graphics APIs
Surma:were coming about and kind of people were saying, this is how you program on the GPU.
Jake:Hmm.
Surma:And I tried to look at them and it, like, went too far the other way. It was so low-level where
Surma:you're, like, genuinely, you know, do your own memory management on the GPU and you kind of have
Surma:to know what the GPU is like. But I never really understood what a GPU is like. And also, what
Surma:really personally frustrated me, and it's all platform-specific. So Metal is what you use when
Surma:you are on an Apple device. DirectX 12 is what you use when you have Windows running. And Vulkan
Surma:is technically, like, open, an open standard, but I'm not sure if you can write Vulkan on all
Jake:Hmm.
Surma:devices. It needs to be, like, a retranslation layer. And that kind of put me off. And
Jake:And that's where things like Unity come in, right? They're the ones that you let
Jake:you write once and it compiles to these various... Hmm.
Surma:yeah, but that's more like a game engine, right? You're not programming for the GPU,
Surma:you're building a game and you're still just writing shaders to an extent. And maybe I'm
Surma:wrong because I have, I should say, like, I'm not a game development expert. I'm not a GPU expert
Surma:or anything like that. But that was just how I perceived the state of GPU programming, I guess.
Jake:Hmm.
Surma:And it just always felt like a big barrier to entry. And then, I guess, a bit by coincidence,
Surma:like, I got wind of WebGPU and a couple of things just, like, immediately stood out. And the first
Surma:thing was that the WebGPU API, well, it's on the web, so that's good, you know. But it's not
Jake:Yeah.
Surma:coupled to Canvas. You obviously can because it's supposed to do the graphics thing. But you can just
Surma:use the GPU for stuff that doesn't have anything to do with graphics. You can just use it to...
Jake:All right, so because WebCL was the... I don't even know if it ever became a thing,
Jake:but WebCL was the kind of equivalent to WebGL. I think WebCL was going to be the WebGL where
Surma:I've never heard of that.
Jake:you didn't have to render it, right? Like it was the sort of compute layer, I think.
Surma:Ah, interesting. Yeah, I don't think that got anywhere.
Jake:Oh, god. Yeah, I'm losing confidence as I'm talking.
Surma:Google it right now.
Jake:Okay. Okay. Let's see. Let's play. Yeah.
Surma:It sounds like OpenCL because that's the, you know, the library language framework for which
Jake:Yeah, okay. Yeah, it's a Kronos thing. Yeah, and it is a JavaScript binding to OpenCL, as you say.
Surma:you write C and C++, I think, to run code on the GPU, but it has nothing to do with graphics
Surma:necessarily. So, the naming would make sense.
Jake:Like, you know, so it is akin to WebGL in that it's a sort of direct binding to
Jake:something from outside the lands of the web, JavaScript.
Jake:Yeah.
Surma:Right. So, you know, recently, using the GPUs for other stuff than graphics has
Surma:gotten increased attention. You know, the first era was, I guess, you know, crypto mining, which
Surma:is boom, go with that. But now we are more in the neural network machine learning era, where
Surma:running massive neural nets, which is just heaps and heaps of matrix multiplications,
Jake:Hmm.
Surma:which GPUs are really good at, people want to use those. And so, while it's possible with WebGL,
Surma:it's not necessarily easy or as performant. And so, I was interested. And the other thing that
Surma:stood out for me, it's just this WebGPU API is webby. Because if you look at WebGL and you've
Jake:Oh, and I have
Surma:ever and you have looked at OpenGL, you'll notice that WebGL is literally the C API just exposed
Surma:via JavaScript. A couple of minor like wrappers, because some things just don't map well, but it's
Jake:to...
Surma:pretty much one-to-one, which on the one hand is good. You know, if you learn one thing and you can
Surma:use it in both places, but it just doesn't feel like a good web citizen. And as a web developer,
Surma:it will not be intuitive for you. Right. Yeah, I had a similar feel with that. And what I noticed
Jake:No, and this was always the blocker for me in WebGL is I... It just didn't feel like the kind
Jake:of APIs I was used to. It didn't feel like a web API. So, I could never really get... I mean,
Jake:I don't have a lot of experience in C, so it was totally alien to me. And, yeah, I used it a couple
Jake:of times, but it was a lot of copy and pasting and not understanding a whole block of code.
Jake:Just to get to a bit, I did understand.
Surma:with WebGPU that the opposite is happening. So, WebGPU being standardized with, and I want to
Surma:point this out, with all three browsers actively participating in the design. So, while it's
Surma:currently only launched and stable in Chrome, I'm behind the flag in Firefox. I am actually fairly
Jake:So,
Surma:confident that Safari will also ship this. And that by itself is already quite exciting because
Surma:for years Safari was super behind on adopting the newer versions of WebGL.
Jake:weren't they wanting to bring metal to the web? Wasn't that part of their thing for a while?
Surma:Yes. And I'm not going to try and recite the, you know, GPU on the web drama on how it went. There
Surma:was lots of conspiracy theories, I think, and I don't care. I really like WebGPU and I'm hoping
Jake:Hmm.
Surma:that all the browsers ship it. And if that happens, I'll be happy. But yeah, what I meant to
Surma:say is that the opposite is happening in that the design that WebGPU has, which I think is quite
Surma:pleasant, we're going to talk a little bit about it, has now gone the other way where it's now
Surma:being adopted by native language ecosystems. So, there is Dawn, which is a C++ library written by
Jake:
Surma:the Chrome folks, which is what they use to basically expose WebGPU to a renderer, to a
Jake:Oh!
Surma:browser thread running. But it's effectively the WebGPU API in C++. So, if you learn WebGPU,
Surma:you can use it on the web. But if you're a C++ developer, you can also use it from C++ with
Surma:this library. And of course, the nice thing is that it abstracts away whether you're running
Surma:on Mac, Windows, or Vulkan or something. You just learn this one API and you get access to the GPU.
Surma:And there is a crate called WGPU, which does the same thing in Rust. And that really was...
Jake:So, I wonder if the C++ engineers and the Rust engineers hate this API as much as I hated the
Jake:WebGL one, you know, that was based... I don't know. That's a question for others.
Surma:I don't know. I would hope not, because I find it quite nice, both from using it from Rust as
Surma:well as using it from the web. But then again, I don't know. So, yeah, you learn this one API.
Surma:You can use it on the web. You can use it natively. It abstracts away which API is available
Surma:in the operating system. It seems like a really good bang for the buck. If you want to learn how
Surma:to program, if you want to use your GPU for something, this seems like a really good time
Surma:investment rather than learning every single platform API. I suppose there might still be
Surma:benefits if you need to squeeze the last bits of performance or something. I don't know,
Surma:because I'm not that deep. But I like being a web developer and building something that can run
Surma:on whatever device you have. And that this continues now with GPU coding gets me quite
Jake:Yeah, that's what I understood. It's like they're rubbish little cores, but there's many of them. So,
Surma:excited. The thing we should talk about a bit, because that's something I never understood
Surma:before this either, is what actually is a GPU? What is different about them? Because for me,
Surma:I always was like, it's just something with very many cores.
Jake:it could do lots of little bits of work.
Surma:Yeah, and I was like, why don't we just use that for our CPUs as well? I mean,
Surma:why don't our CPUs have like 1,500 cores? And I've learned more since then that they just have
Jake:Hmm.
Surma:a wildly different architecture because they have a different goal, a different thing that
Surma:they're optimized for, because GPUs are optimized for throughput at the cost of latency. And that
Surma:might sound like I got it backwards, because it's only thanks to GPUs that we managed to render
Jake:60 frames a second. Yeah. Yeah, sure.
Surma:an image at 4K at 120 frames a second, I would say. But it seems like, clearly, they're pretty
Jake:Yeah.
Surma:good at a latency game. And I won't and I can't go into full detail, because on the one hand,
Surma:it's all, there's lots of secrets and NDAs about the actual specific architectures of GPUs. But
Surma:there is a really great 13-part blog post series I'm going to link to if people want to dive into
Jake:Yeah.
Surma:this. I found it super interesting. Even though I think it's over 10 years old now, it's still
Surma:fairly valid. And I talked to a couple of the WebGPU folks who said, I don't know, this is
Jake:Yeah.
Surma:accurate in the concepts and everything, because nobody can really at least openly speak about the
Surma:actual details. So understand what this means to optimize for throughput over latency. We have to
Surma:talk a little bit about how these GPUs are designed. Intel actually has a fairly good
Surma:description of what the built-in GPUs work like. And so I guess the other GPUs are at least
Surma:conceptually similar. And the main thing that I take away is that they're built, the architecture
Jake:Mm hmm.
Surma:is hierarchical. So there's multiple layers of how cores are grouped. And at the lowest layer,
Surma:usually people talk about execution units. So you could think of it like a single core, that is an
Surma:execution, but not quite. So let's just, I'm going to stick to the terms that I've learned. So at the
Jake:Yes.
Surma:lowest level of this hierarchy, you have the execution unit, and that is a SIMT core. You may
Surma:have heard of SIMD, you know, single instruction, multiple data, which is what we have in the
Jake:Mm hmm.
Surma:CPUs. You have, usually it's a vector operation. So if you have, you know, two four-dimensional
Surma:vectors and you want to add them, you technically have to do four additions for each component in
Surma:that vector. With SIMD, that's a single instruction that is operating on multiple data, namely each
Surma:component of the vector. So you can do this addition in one, in O of one, basically. And I'm
Surma:going to say one cycle, because it's probably multiple cycles, but it's one instruction,
Surma:effectively. Multiple tech, actually, if I didn't know, I would believe you. It's single instruction,
Jake:Okay, so SIM T, so single instruction, multiple texels.
Surma:multiple threads, which is very confusing in a way, because we're just saying, wait, we're on a
Jake:Oh, of course. Oh, yeah.
Surma:single core. But this still means you have the single instructions and it's executed by multiple
Surma:threads, which are like kind of like sub-cores in this execution. But the difference here is that
Surma:each thread in this execution unit has its own set of registers and stack pointers. So all the
Jake:Mm hmm.
Surma:cores or all these threads in this execution unit are operating in lockstep. They have to execute
Surma:the same instruction, but have their own set of registers that can actually, you know, build up a
Surma:different calculation over time, as long as the execution, the instruction series remains the same.
Jake:Mm hmm.
Surma:And this is actually the reason why in many parts of the shader writing community and stuff
Surma:like that, people avoid if-elses or loops. Yeah.
Jake:Mm hmm.
Surma:Kind of. So it will have to execute both branches of an if-else,
Jake:Okay.
Surma:if there's two parts in the one execution that take different paths. If every single
Jake:I see.
Surma:thread in one execution takes the same branch, I think it can avoid executing the else.
Jake:Oh, interesting.
Surma:I don't know if it's working at this level. This is generally just making assumptions. But yeah,
Surma:basically the assumption is if you have an if-else or if you have a for loop and one thread has to
Surma:continue looping, the other ones have to loop with it and just discard the results. And they can do
Surma:that. They have the architecture to run code that isn't whether you just discard the results. But
Surma:obviously, that is wasteful. And this is all about throughput. So having a thread that does
Surma:pointless calculations is something where you could have had more throughput if you had done
Jake:Mm hmm.
Surma:better, you know. So that's one of those parts where you can already see the first manifestation
Surma:of how it's optimized for throughput. And the other part is, and this I think is really interesting,
Surma:that as on the CPU, also on the GPU, while it has very closely co-located memory to work with,
Surma:that is often faster than what we have for the CPU, it's still slower than the cores. So getting
Surma:data from memory takes time. And so when a core or a thread needs some data, it is often just not
Jake:Mm hmm.
Surma:available straight up. And so what these cores, these execution units are optimized for is that
Surma:they can really efficiently store the current state and switch to a different task or switch
Surma:to the next work item that is scheduled. So most of these execution units are heavily oversubscribed
Surma:on work. So whenever they have to wait for something, rather than waiting, they switch to
Surma:working on something else. And then when they have to idle again, they switch back. And this is where
Jake:Mm hmm.
Jake:Ooh.
Surma:I think the main part of the throughput versus latency trade-off comes in. Because as long as
Surma:all cores are busy doing valuable work all the time, throughput is high. Your megaflops or
Surma:teraflops, floating point operations per second, like you are doing work that is good. The scheduler
Surma:is doing its job right. But the individual work item may take longer because just because the
Jake:Mm hmm.
Surma:data has now arrived doesn't mean that the thread will immediately switch back to continuing
Surma:on that work item. It will just continue working on work items and still it has a reason to switch
Surma:back to something else. And so individual work items will take longer. Latency is increasing
Surma:on a per work item basis. But overall, throughput is maximized. Utilization is maximized, which means
Surma:throughput is high and the whole thing just gets work done more efficiently per second, I guess,
Jake:Yeah, it does, but it's got me thinking, like, computers are complicated, aren't they? I mean, wow.
Surma:or however you want to measure this. Does this make sense? They really are.
Surma:Again, this was just the base level of the hierarchy. Because now we go one level up,
Surma:where multiple of these execution units are grouped together in what at least Intel calls
Surma:a sub-slice. So this is a bunch of these execution units together and they have a tiny amount of
Jake:Mm hmm.
Surma:shared memory. We're talking like a couple of kilobytes. And that is mostly for synchronization
Surma:purposes. Because sometimes you have to coordinate that nobody overwrites the result of somebody
Surma:else. Of course, you want to avoid that because when you synchronize, you have to wait. And that
Surma:is bad in GPU land. But sometimes it's necessary. And so they have limited that only within one of
Surma:those sub-slices, you can wait for each other. And then the next level of hierarchy, at least
Jake:Mm hmm.
Surma:as described by Intel, would be a slice, which is a group of multiple sub-slices. And so this
Jake:Mm hmm.
Surma:I found really interesting because this is three levels. I wonder maybe if other manufacturers have
Surma:more hierarchy levels or not. And often when you hear cores, it gets quite interesting.
Jake:Mm hmm.
Surma:What I've seen as that's like an integrated Intel GPU ends up with a total of 170 to 700 cores.
Surma:Now, I actually am not sure what is a core because they talk about execution units,
Surma:sub-slices and slices. So is a core, I guess it's one of those execution units. But just to compare
Jake:Oh, okay.
Surma:like a desktop GPU can end up with 1500 cores nowadays quite easily. Or for example, the Apple
Surma:M1 GPU that is in the smallest version, the MacBook Air has seven or eight cores, where each
Jake:Yeah, yeah.
Surma:core has 16 execution units, where each execution has eight LAUs, algorithmic logical units.
Jake:Do the maths for me. How many is that?
Surma:And that's what I mean. It's really hard to compare. So what people usually do to compare
Jake:Hmm.
Surma:is they compare how many floating point operations or flops you can do on a GPU per second. So
Jake:Flops.
Surma:for example, as I said on my Apple M1, you get 2.6 teraflops, which that sounds pretty good.
Surma:And then I looked up the Pixel 8 Pro can do 3.2 teraflops.
Jake:Flops.
Surma:Yeah, what the fuck are they talking about? But yeah, so this is obviously, I guess the MacBook
Jake:Exactly.
Surma:Air M1 is more like a mobile device and a desktop device. So if we were to look, for example, at the
Surma:Apple M1 Max, we were at 10 teraflops. Or if you look at an RTX 4090 graphics card, 73 teraflops.
Surma:So I feel like it gives you roughly like a, where is the 10x factor coming in kind of like
Surma:roughly a comparison. But as I said, the actual specific architecture is not, you know, but
Jake:Hmm.
Surma:people always talk about the cores and you can just run, I don't know how many threads. And that's
Surma:kind of what I wanted to tap into. And of course, when you have this specific architecture, your
Surma:code that you run has to be in a way crafted to fit this architecture. Just like when you do
Surma:multi-threaded programming, you know, you have to think about data races and how to avoid them
Surma:using mutexes or something like that. So the same kind of goes when you're going to write your
Jake:Hmm.
Surma:shaders in Wixel or shaders in GLSO. So you have to think about those kinds of things. But I think
Surma:it's time that I actually start about like at least like a little bit of code. Like how do you
Surma:get started with WebGPU and you start. Yeah, maybe, maybe we need to cut this down. I don't
Jake:There's been a number of times during this talk where I've got, it's felt like, oh, he's done with the intro now. Here comes the main content.
Surma:know. So basically what has happened since WebGPU there is navigator.gpu. That's a thing.
Surma:It gives you a GPU. And what you can do from there is you can request an adapter. Now the adapter
Jake:Nice, decent name.
Surma:is basically you requesting access to a specific kind of GPU from the system, because some systems
Surma:have multiple GPUs. Like you remember the Surface book had like one integrated with the keyboard,
Surma:a high-performance one, an energy-saving one in the screen itself. And you can...
Jake:MacBooks were the same, right? Well, actually, I don't know if the M1 ones do, but all the MacBooks, yeah, they had the integrated and the discrete one. Yeah.
Surma:I don't know either.
Surma:And you can request, you know, you can add a preference whether you want high performance
Surma:or low power. I don't think there's much more choice right now. Some systems even offer software
Surma:rendering, which is obviously, you know, slow, but for backwards could be nice. And from this
Jake:Mm hmm.
Surma:adapter, you can request a logical device. So the device is logical. It's not an actual device
Surma:on the one hand, because if you have multiple tabs wanting access to the GPU, you don't want them to
Surma:be able to read their data by accident. So this logical device is kind of like your handle, your
Surma:personal handle to the GPU so that the browser underneath can do the multiplexing and make sure
Surma:state is saved and restored when context switching happens, which is in fact the same thing the
Jake:Of course.
Surma:operating system does with multiple apps using the GPU. Everybody feels like they have exclusive
Surma:access, but of course that's not actually the case. And this logical device, unless you specify
Surma:otherwise, is not going to represent the real capabilities of the GPU, but actually going to
Surma:represent a baseline device. So this is stuff like, you know, you can only upload textures up to 8K
Surma:by 8K, or you only have 64K for uniform variables or at most 256 megs of memory.
Jake:Mm hmm.
Surma:Those kind of things are limited. Like WebGPU will shout at you if you do more. The point being
Surma:that if you do, because it's so device specific, if your app or your stuff runs with this baseline
Surma:device, you can be fairly confident that it will run on all devices in circulation right now. So
Surma:that was how I think how this baseline device was chosen, or the specs were chosen by the WebGPU
Jake:Nice.
Surma:folks, so that if you just use that device and your thing runs, you can be fairly confident
Surma:that at least in terms of data and workloads, it can run. Of course, you could still not hit the
Surma:frame rate if the device is overloaded or just super slow, but I thought it was quite nice. It's
Surma:giving people... Exactly. It's a bit like... Yeah. It's a bit like what we always said,
Jake:Mm hmm.
Surma:people should have a Nokia 2 phone to test their web app, because if it runs there,
Surma:it's going to run everywhere. And of course, you can request increased limits, but then you're
Jake:Mm hmm.
Surma:opting in and you're knowing that you're leaving the well-tested battlegrounds. These are fairly
Surma:request user media. It's literally like functions on the Navigator GPU that take some options and
Surma:give you a promise and resolve to the thing if it has it and the user has given permission,
Surma:although I'm not sure if currently GPU is gated behind the permission.
Jake:Yeah.
Surma:Yeah.
Surma:Yeah. Which again, maybe the baseline device is a thing that you can get without permission,
Surma:and when you specify you want to get the name of the GPU, maybe that's where permissions come in.
Surma:Maybe they're keeping these options open for the future. I'm not sure, to be honest.
Surma:So, once you have your logical device, your exclusive access to the GPU, or so they would
Jake:Mm hmm.
Surma:like you to think, you can now start defining your pipeline. So, it's kind of exactly what
Surma:they sound like. You chain things together that consume and produce data, which are in this case
Surma:more often than not shaders. When you do graphics programming, one of these modules could be a
Surma:canvas, so you pipe your data from a shader into a canvas, but it could also just be shaders. Data
Jake:Mm hmm.
Surma:turning into data, turning into data, and you get the result back at the end. Shaders, by the way,
Jake:This sounds a lot like the Web Audio API. Like, you have that sort of inputs, filters, and then you're chaining it into an output.
Surma:it's not
Surma:not dissimilar. A lot more declarative in a way, because you have to declare how this data flows
Surma:up front. Well, I guess in web audio, it's also kind of up front. Anyway, I always thought that
Jake:Hmm.
Surma:shaders are a great name, which confused me for a long time, because they don't shade. Well,
Surma:they used to. It stems from the olden days, where GPUs were completely fixed. You basically were
Jake:Hmm.
Surma:told, upload the vertices of your mesh in this format into this memory bit here, and then the
Surma:graphics card does its thing. And the only really customization you had is a tiny bit of, I guess,
Surma:custom code, where you can affect how the lights in the scene affect how objects were, and say it
Surma:with me, shaded. And so these pieces of code running on the GPU were called shaders for that
Jake:Mm hmm.
Surma:reason. They've since then gone well beyond just shading and lighting, but the name just stuck
Surma:around. And so that's kind of what you do. You define your pipeline with a bunch of shading
Surma:modules, and then the output can be a canvas or back to memory, and you can handle that from
Surma:JavaScript. So I guess the last thing to kind of talk about there would be like, you know,
Jake:Mm hmm.
Surma:what does a piece of shading code look like? I said the code language is called
Surma:Wixel. It's a bit like Rust. And it has all these GPUs, especially that you might already know if
Surma:you've ever done any WebGL shading with GLSL. You have like the four-dimensional vectors and matrices.
Surma:But compared to GLSL, you can quite, at least quite obviously, do stuff like pointers and
Surma:proper structs, where you can define your own data structures that consist of two ints, a float, and
Jake:Hmm.
Surma:I don't know, an array of bits or something. Like all these things you can define and transfer back
Surma:and forth between JavaScript land and WebGL lands. Because previously in WebGL, unless it
Surma:fits into like, I guess, a matrix, you would have to start somehow encoding your custom data into a
Surma:texture and then sampling that texture from GLSL to read the data back, which of course gets
Jake:Mm hmm.
Jake:Slow.
Surma:really messy really quick. Yeah. So, you know, every shader has an entry function, and I'm going to
Jake:Read back so slow. Yep.
Surma:skip over a couple of details here, because it's just going to be too hard to actually explain well
Surma:while we are talking about, without actually seeing the code. But basically, each invocation
Surma:of your entry point function is going to get a number that tells you, you're the first invocation
Surma:of this. You are the second invocation. And that's how you distribute work across the data you have
Surma:uploaded. So, if I were to say, let's use a graphics example. If I were to upload my mesh,
Jake:Mm hmm.
Jake:Mm hmm.
Surma:and every mesh has a vertex, and I wanted to do some work on each vertex, I could use this,
Jake:Mm hmm.
Jake:Mm hmm.
Jake:Mm hmm.
Surma:basically the thread ID, to say, okay, the first thread processes the first vertex. The second thread
Surma:processes the second vertex. And so, you use that ID to access different parts of the data that you've
Jake:Mm hmm.
Jake:Mm hmm.
Surma:uploaded. And that's how you scale out your work over a huge amount of data that you have given
Surma:that piece. And it's usually, you know, like read-only data. So, there's not a risk of any
Surma:synchronization problems. And the same, probably, with the output that you specify. The first thread
Surma:puts their output here. The second thread puts their output here. So, that way, you don't need
Jake:Mm hmm.
Surma:to do any mutexing or locking and can avoid data races. But that is something that is on you to
Surma:design. And so, that's definitely something where you need to craft the problem that you're trying
Surma:to solve in a way that it fits the GPU architecture. And then, once, you know, that is all done, you can
Surma:eventually read the data back. But this is actually something that I say, kind of like,
Jake:Mm hmm.
Surma:you know, you just read the data back. It's actually not that simple. The problem being
Surma:that you have to find your pipeline. You can, you know, say, hey, GPU, execute this pipeline with
Surma:this data. Which, by the way, is one of the performance benefits WebGPU brings. That you
Surma:define this pipeline ahead of time. And WebGPU can validate it, that it's valid. In OpenGL times,
Surma:this validation had to happen every time you were spawning a new piece of work or adding a new buffer
Jake:Mm hmm.
Surma:with WebGPU. This can all be done at declaration time. And then, it allows it to skip this
Surma:validation work later on in the process. But as we know, and whoever has built, if you've ever
Surma:built your own computer, like, GPUs are cards. And they're often separate. Not like in the MacBooks
Surma:nowadays, where it's all on one chip. But they can also be, as they're called, discrete. A separate
Surma:device. Basically, a co-processor in your computer. And because GPUs work so differently
Surma:and have their own memory, it can't just be accessed by both CPU and GPU at all times.
Jake:Mm hmm.
Surma:So, to get data from your, you know, from JavaScript, effectively, or from your CPU memory
Surma:into the GPU memory, you often have to do what is called a staging buffer. But it is a small
Surma:piece of memory that can be accessed by both, but it can't be accessed fast, necessarily.
Jake:Mm hmm.
Surma:But you put all your data in there from the CPU, tell the GPU, hey, pick up your data and put it
Surma:in your internal memory, and then it copies it over to its own internal memory, which is then
Surma:fast and closely co-located. But this is kind of like a setup step you have to do for both
Surma:getting data to the GPU, but also you have to do that for getting data back from the GPU.
Surma:And these are all...
Jake:Mm hmm.
Surma:Yeah.
Jake:Mm hmm.
Jake:Mm hmm.
Jake:Mm hmm.
Jake:Mm hmm.
Jake:Mm hmm.
Jake:Mm hmm.
Jake:Mm hmm.
Jake:Mm hmm.
Surma:Oh, yeah, I could see that.
Jake:And I switched my implementation to having a sort of local, you know, set of states for where the settled blobs are, and it became fast again.
Jake:And it was just that.
Jake:So I was able to run the simulation on one side and then the rendering on another, and that meant I didn't need to do that readback every frame which...
Surma:It is, yeah, for sure. And I think that's the kind of thing where, by nature, this API has to be async.
Jake:And yeah, 60 frames a second came back. So I guess it's a similar sort of thing.
Surma:Because, you know, the GPU then goes off and does its work. And technically, you know, the CPU isn't
Surma:busy. You can do other stuff. The JavaScript, like, the API actually gives you a promise after you
Surma:kick off some work and say, like, execute my pipeline with this data. And you can just do
Surma:something else in the meantime. And you get a promise resolved once the pipeline is done.
Jake:...
Surma:And what it means is, you know, up to you and how you define that pipeline. It usually means the
Surma:output buffer has been filled with the results of whatever you've been doing or, you know, the
Surma:canvas has been drawn upon or something. But that's kind of how that will work. And so, in the
Surma:blog post, because I wasn't really interested in doing graphics rendering, I actually wanted to
Surma:learn more about, like, this capability of spawning, I don't know, 60,000 threads to do
Jake:Hm.
Surma:something. I built a physics simulation. And, of course, I visualized it with a canvas. But I made
Surma:a point to use Canvas 2D. So, all that I'm doing on the GPU is, like, I upload the coordinates
Jake:Oh!
Surma:and different, yeah, the position and the radii of different points to the GPU. And they all have a
Surma:velocity. And then the GPU does the calculation for each frame. Like, how much have they moved?
Surma:Have any balls collided? And then how would they change direction and velocity? And the result is
Jake:Hm.
Surma:the new position, the new buffer, basically, of the new positions, new velocities, and the radii,
Surma:obviously, the same. And so, the GPU does this every frame. And then I use Canvas 2D to draw
Surma:all the individual balls. And that was kind of cool because I basically spawned a thread for each
Surma:ball. And kind of having that power suddenly at my fingertips was cool. And, like, actually, Canvas
Surma:2D became my bottleneck. So, once I disabled just, like, the visualization, I could easily simulate
Jake:...
Surma:14,000 balls on my MacBook M1 MacBook Air, which on the CPU wouldn't even get close. But,
Jake:Heh heh heh.
Jake:...
Jake:No.
Surma:yeah. And I think what you were saying, I'm much more into it as well, not in the whole
Jake:...
Surma:3D stuff, but actually using it for 2D stuff. And, you know, you can do it straight to Canvas and do
Surma:texture sampling. But also, I like this approach where you could potentially, you could actually
Jake:...
Surma:use WebGPU to fill a buffer with RGBA data and just use it as, you know, an image data object.
Jake:...
Surma:So, rather than plugging the Canvas directly, you could just generate an RGBA buffer, which probably
Surma:is slower than rendering straight to a Canvas. But it feels more obvious to me what's happening.
Surma:It's all just, you know, computing happening in the end.
Jake:That's neat. Yes, because that is... I know when I want to do some filter work or if I want to, you know, multiply two pixels together or perform some maths operation on two pixels across a whole image.
Jake:You know, I know how to write that in Canvas 2D, but it's slow.
Jake:Yeah, and so I've done that with WebGL before, but never really felt like I was comfortable or knew what I was doing.
Surma:Yeah.
Jake:So I'm really excited to go and try this with WebGPU.
Surma:So, yeah. It's definitely, people say that, you know, the modern graphics API are more boilerplate
Jake:...
Surma:than OpenGL. And I can see why they say that. But then again, any OpenGL tutorial where you draw the
Surma:triangle, I don't think anybody can really say that it isn't boilerplate. And I find that,
Jake:Hm.
Jake:...
Surma:at least with WebGPU, it doesn't feel like it's more boilerplate. There's still some setup to
Surma:be done, but at least I get it, you know, like I understand what I am setting up and feel like I
Jake:...
Surma:have an intuition of where I can go in and change things or augment things. So, in that sense, I
Jake:...
Surma:do like this API a lot. Yeah. One thing I wanted to quickly bring up that we, you know, because I
Surma:was just looking at the new Apple M3s and stuff, how these new GPUs are all, these new chips have
Surma:CPU and GPU on the same chip with unified memory. They even now have, you know, the TPUs,
Surma:or the NPUs, the neural processing units, which is kind of actually the same thing as a GPU,
Jake:Hm.
Jake:...
Surma:obviously not quite, otherwise they wouldn't label differently. But these are, like GPUs,
Surma:many, many cores with limited instruction set. And the GPUs and NPUs, from what I understand,
Jake:...
Surma:are mostly different in that they have less precision. So, the NPUs are stuff, a core set
Jake:...
Surma:are optimized to work on 16-bit or even 8-bit floats and integers, because for the neural nets,
Surma:you often don't need the high precision. And so, that's just as a little pointer to what is going
Jake:Okay.
Jake:...
Surma:on different there. But yeah. So, I realized that I didn't really talk about much code apart from
Surma:how you get your logical device, but it's just not the kind of API, which literally talking
Jake:...
Surma:through makes a lot of sense, I think. But I hope that if people are interested by having this power
Jake:...
Surma:of just spawning a couple of hundreds of thousands of threads to do work, then that the blog post,
Surma:and actually even the spec is quite good. And I think MDN now has a section as well
Surma:on how to get started with WebGPU.
Jake:That sounds amazing. No, I'm going to take a look at that because, yeah, anything which makes WebGL-like things a little bit more web-like is...
Surma:It's a win.
Jake:Yeah, is a win. Absolutely.
Jake:So we should say, we should say that this podcast is sponsored by Shopify in as much as they are paying for the editing and hosting of it.
Surma:Yeah. And they have not, and I want to express how thankful I am, not demanded anything in return,
Jake:...
Surma:really. They said, you should do the thing. And that's all they said.
Jake:Yeah, I suppose it's very similar to the relationship we had with Google previously.
Jake:So, yeah, we are very thankful for the sponsorship, but also thankful that they're not asking us to talk about Shopify stuff.
Surma:I mean, we will, but not in a forced endorsed way. We are not trying to get people to sign up for a
Jake:Although I imagine we'll end up talking about stuff that we are working on internally because...
Jake:...
Surma:VPN service. I am on the literal edge of my seat, Jake.
Jake:Exactly. And to prove that our content isn't changing much, I have a conundrum that I would like to put to you.
Jake:And I want to know where I went wrong and what you would have done differently.
Jake:...
Jake:Excellent. So, well, strap in so you don't fall off the edge of your seat.
Jake:Anyway, I was in Manchester after a stag do or a bachelor party, as they call it in other parts of the world.
Jake:Everyone else had left because it was the, you know, yeah, the whole of Manchester.
Surma:Literally everyone, you were alone.
Jake:It was like 28 days later, but in Manchester.
Jake:So everyone else had gone and my train was a little bit later on, so I didn't have much to do.
Jake:But I realized I needed a poo.
Jake:And I've already checked out the hotel, like, you know, so there's my first mistake.
Surma:Classic.
Surma:Yep.
Jake:Tick. Okay.
Surma:Yeah.
Jake:So I'm like, hmm, yeah, it's not gonna... yeah, I need to do something about this.
Jake:And so I saw there's a pub that was open.
Jake:It's like 11 in the morning. So there's a pub that's open. That's good.
Jake:I'll go in there.
Jake:But as you know, it's not the done thing that one simply walks into a pub and goes to the toilet and leaves, right?
Jake:You know, that's not... that's rude.
Surma:Really, I just, I feel like I'm still not sure how it works because I feel like
Surma:if you take your jacket off and you walk with confidence, you're fine.
Jake:Hmm.
Jake:Okay. So your first... so I've already not followed your first piece of advice.
Jake:I went to the bar and bought a drink.
Jake:Yeah. And then I went and sat down.
Surma:Good citizen.
Jake:And then I realized, right, I need a poo and I've got a drink.
Surma:I came here for a purpose.
Jake:Yeah. What do I do?
Jake:So what would you have done at that point?
Jake:Like, I've put you in the situation of the mistakes I have made so far.
Jake:What's your solution?
Surma:I am struggling, Jake, to see the conundrum. You're in a pub. You have bought a drink.
Jake:Yeah.
Surma:They probably have a bathroom.
Jake:Yeah.
Jake:Right. What am I doing with the pint?
Surma:You leave it on the table as a sign of somebody sitting here and I will be back.
Surma:You could even leave your jacket.
Jake:Okay. I didn't do any of that. I didn't have a jacket.
Jake:It was in the summer. It was warm. Very warm.
Surma:Ah, then just take your trousers off.
Jake:I draped my trousers over the back of it.
Surma:Might as well prepare.
Jake:Yes, I suppose. No. So I decided to take my pint with me, didn't I?
Surma:The German in me wants to put a towel down, but I'm guessing you didn't have a towel either.
Jake:I did not have a towel.
Jake:Yeah. So I decided to take my pint with me.
Jake:And I sort of...
Jake:I sort of felt like I could get to the bathroom with my pint, but without also being seen.
Surma:I prefer my beer with sharticles.
Jake:I wasn't going to... anyway.
Jake:I walked through the corridor towards the toilet.
Jake:And then that's when I learned that this particular pub has a separate bar
Jake:that I opened the door into before the toilet.
Surma:In the bathroom?
Jake:Before the bathroom, you would sort of go through this door.
Jake:There's this other bar and the toilets are just on your left.
Surma:Oh, okay.
Surma:Because I think there's a market niche, man.
Jake:And there is four staff with nothing to do other than turn around and look at me
Jake:with my pint and as I walk into the toilet with it.
Surma:And judge you.
Jake:And let me tell you, like I said, this is the depths of summer.
Jake:It was boiling in that toilet.
Jake:So I emerged afterwards.
Surma:I mean, I, you know what? I think you get points for buying a drink.
Jake:Same set of staff now.
Jake:I mean, I'm sure they've been talking amongst themselves about what was going on.
Jake:And I walked back past them still with my pint.
Jake:And I did drink some of it because it felt like the thing I should do.
Jake:And just sweating. Profusely sweating.
Jake:How do you feel about my... score out of ten for my solution.
Jake:Thank you.
Surma:I don't think you have to.
Surma:And you get points for giving those staff people something to talk about at 11 in the morning.
Jake:Excellent. Yes, I'm sure there's a group of people in Manchester
Jake:who are still talking about the man who likes to drink his pint
Jake:from the safety of the toilet.
Jake:From the safety of the toilet.
Surma:He went in with a beer and he came out with a beer sweating.
Surma:Draw the rest of the owl.
Jake:Okay, let's...
Jake:Thank you.
Jake:Alright, okay.
Jake:Let's talk about the web.
Surma:Let's talk about the web.
Surma:Well, what you already said.
Surma:You want to talk about...
Surma:It had the word ideology in it, which I think this is gonna go down.
Surma:Is it the Tories?
Jake:No, no, no, but I do feel like browsers are like political parties.
Jake:And maybe I'm just thinking that because there's a lot of politics going on right now.
Surma:No, I have no choice, mate.
Jake:And it is maybe a bit of a clumsy metaphor, but hear me out.
Jake:Okay.
Jake:Users are the voters, right?
Jake:And you're sort of, by using a browser, you're sort of voting for it to a certain degree.
Jake:And just like the...
Surma:Do you think people think about it that way though?
Jake:I do think...
Surma:Web developers do, but people, not web developers.
Jake:I...
Jake:Oh, no, no, absolutely not.
Jake:Well, I think there are definitely people who will use Firefox due to their ideology.
Surma:Yeah.
Jake:And so they are using it in a voting way.
Jake:But as you say, I think normal people don't.
Jake:And I think that's interesting.
Jake:Because you can also question the fairness of the votes.
Jake:You know, are there people who...
Jake:So, Microsoft Edge, when you go and try and download Chrome in Microsoft Edge,
Jake:it displays something which really looks like they've injected content into the Chrome download page.
Jake:They literally haven't.
Jake:But it looks like they have.
Jake:And it's kind of telling you, are you sure?
Jake:Are you making a mistake?
Surma:Yeah.
Jake:So you could say, is that deceptive?
Jake:You have Chrome...
Jake:Like, if you go to a Google site and you're not using Chrome, it tells you.
Jake:It's like, what are you doing, mate?
Jake:You should be using Chrome.
Jake:It's better.
Jake:And so you could say, is that unfair campaigning?
Jake:And maybe that's when the votes of regular people are being taken in an unfair way.
Surma:All right.
Jake:Apple have made iOS a dictatorial state.
Surma:People can quote Jake now, Apple is North Korea.
Jake:Democracy has been outlawed on iOS.
Jake:You can only vote for Safari if you download...
Jake:You can download Chrome, but it's just a skin over Safari.
Jake:So yeah, democracy is dead there in this model.
Surma:I mean, to be clear, right?
Surma:Like Chrome on iOS can still sync your tabs, give you your bookmarks.
Jake:Yes.
Surma:It's the engine that is not Chrome's.
Jake:Exactly.
Jake:Exactly.
Jake:So it is...
Jake:Yeah, it isn't.
Jake:You are taking certain elements of googly things when you use Chrome on Safari,
Surma:Not the stuff that we care about.
Jake:but not Chromium, not the engine, not Blink.
Jake:Exactly.
Jake:But there are these smaller, powerful groups that browsers need to keep on side,
Jake:like their parent companies, Apple, Google, or powerful entities like Facebook.
Jake:In the same way political parties keep certain companies or the press on their side.
Surma:Or, you know, the law.
Jake:Well, you see, laws.
Jake:I think laws are more like the W3C,
Jake:and that's where the parties have to work together to come to a consensus to write laws,
Surma:Let's do it.
Jake:to adapt laws, that kind of thing.
Jake:And like political parties, I think the browsers have differing ideologies,
Jake:and that those ideologies shift over time.
Jake:And that's what I want to talk about.
Jake:I want to look at the ideologies of browsers from five, ten years ago,
Jake:and then look at how they're changing and where they might head in the future.
Jake:So let's talk about Chrome of Christmas past, or whatever.
Surma:Yeah.
Jake:Chrome dominant even then on platforms where voting is allowed,
Jake:where users can choose which browser to use.
Jake:But Chrome saw native apps as a threat.
Jake:And they saw a trend of people using the web less and native apps more.
Surma:Hmm.
Jake:So I think the Chrome ideology is close that gap to native by making the web more powerful.
Jake:And that sort of resulted in the Extensible Web Manifesto.
Surma:Oh, I haven't actually, like, read it in years.
Jake:Tell us about the Extensible Web Manifesto.
Surma:I think it's still online.
Surma:Is it like extensiblewebmanifesto.org or something?
Jake:Something like that. We can link to it.
Surma:It still exists.
Surma:I think I would summarize it as, and you can tell me whether I'm way off.
Surma:Like, for the web platform, what the standards bodies should focus on,
Surma:what should be added to the platform going forward are low-level primitives
Surma:that unlock new capabilities that were impossible to do before.
Jake:Yeah.
Surma:Let the ecosystem build stuff on top that combines those low-level primitives
Surma:into high-level features by combining them together.
Surma:And only if, like, these high-level features
Jake:Yeah.
Surma:prove over an extended period of time to be popular and useful and well done.
Surma:Only then should they get back into the platform,
Surma:provided there's enough benefit.
Surma:Let it be that, you know, there's less code that needs to be loaded
Surma:or maybe a native implementation directly in the browser could be faster.
Surma:But the focus should be unlock use cases
Surma:that previously were impossible or extremely hard.
Surma:Zed, would you agree?
Jake:Yeah.
Jake:Yeah, absolutely.
Jake:So there is a CSS property called WebKitBoxReflect,
Jake:which will give your element a reflection at the bottom.
Jake:In a very Apple way, because it was Apple that added this to the platform.
Surma:But only at the bottom.
Surma:You can't reflect on the side or top.
Jake:I don't think... I mean, maybe there's an option. I don't know or care.
Jake:But the...
Surma:There's probably, like, weird transform hacks you could do.
Jake:Oh, absolutely.
Jake:But the idea was like, we shouldn't be doing that.
Surma:Yeah.
Jake:We should have some kind of painting API where you can do that yourself.
Jake:Like, you can define that and lots of other stuff.
Jake:Like, give the developers freedom to do a lot more than just that one use case.
Jake:The downside is, you know, Chrome never really did the high level.
Jake:And so we got Service Worker. Good.
Jake:But we never... Well, we didn't get static routes for a very, very long time,
Jake:even though it was pretty much agreed at the start that they were needed for performance.
Surma:Yeah.
Jake:And then we saw a lot of sites use Service Worker and then go, well, this is slow.
Jake:The higher level work to make it faster via declarative routes was not done.
Jake:It is now finally being done, but we're talking about five, ten years ago.
Jake:Things like page transitions, which again, we're getting now.
Jake:But both of us were pushing for that five, ten years ago.
Jake:Like, this is what developers want.
Surma:Yeah.
Jake:But it was like, no, that's too high level.
Jake:We will figure out some way of doing something similar or whatever.
Surma:And to be fair, I think that was one of those situations
Surma:where the extensible web manifesto did us an injustice.
Jake:Yeah.
Surma:Because I do remember at least some people were arguing it's already possible.
Surma:Like, you can build a page transition because people have.
Jake:Right.
Surma:But my god, is it hard and it's even harder to get it right.
Surma:Once you want to think about transitioning from one page to another
Surma:and they're both on different scroll positions, it just gets bonkers.
Surma:And you have to go, like, you know, into what they used to call an HTML5 routine
Surma:with, like, push state and all that jazz.
Surma:And it's so, so hard to get it right across different devices and everything.
Surma:And the browser has all this data, like, all the layers and the positioning
Jake:Exactly. Exactly.
Surma:and the scroll position already tracked.
Surma:It's like, why am I ripping all that out and reinventing it
Surma:when you could just give it to me?
Jake:And even some of the low level parts feel like they didn't do the job.
Surma:Yeah.
Jake:Like, you still can't do WebKit Box Reflect with the CSS Paint API.
Jake:Because you can't paint outside the elements and you can't take parts of the elements
Jake:and copy it in order to do the reflection.
Jake:So it's sort of, I don't know.
Jake:I think it was a really good idea.
Jake:But there's a lot of places where it fell short.
Jake:Some places where it was great.
Jake:Like, I'm glad we got the Intersection Observer API before the lazy attribute on images.
Surma:Yeah.
Jake:I'm glad you could use them in multiple ways.
Jake:But yeah, it feels like it didn't really work out.
Jake:The other part of closing the gap to native is access to device features.
Jake:Device features, Bluetooth MIDI, USB serial camera, push messages.
Jake:But I think Chrome was over-influenced by large partners.
Surma:I was just gonna say, because I feel like some of these things were
Surma:not gonna say rushed, but at least were launched.
Surma:And I did feel for some of them, like, are developers asking?
Surma:Or, you know, are big businesses asking?
Surma:I guess I have to, you know, my personal angle is always a bit more
Surma:on the one person in the developer than, I don't know,
Jake:Yeah, so this is one of my big frustrations working at Chrome.
Surma:Sony's trying to launch something on their website.
Surma:You know, maybe, you know, businesses work differently.
Surma:And obviously, in terms of revenue, get more focus.
Surma:But I was just like, the thing that I'm building,
Surma:do I want to be able to receive SMS verification messages?
Surma:You know, like...
Jake:Is that I always felt like project managers were very powerful.
Jake:If they came into a room and said, look, Facebook has asked for this.
Jake:And they'll be like, yeah, okay.
Jake:We'll ship that.
Jake:No questions asked.
Surma:Yeah.
Jake:Let's go.
Jake:And I didn't feel very powerful walking to a room saying, look, developers keep telling me they want page transitions.
Surma:Oh, spicy.
Jake:And, you know, that wasn't listened to.
Jake:So, yeah, I think there was an over-influence by large partners.
Surma:Yeah.
Jake:Including internal ones like AMP where, well, you know, Chrome and Google just hemorrhaged trust and, yeah, and goodwill with stuff like that.
Surma:Yeah.
Surma:Yeah.
Surma:Yeah.
Surma:Yeah.
Jake:So whatever.
Jake:In terms of web standards, I think Chrome was getting better.
Jake:Like they saw vendor prefixes were a bad idea.
Jake:But when they got opposition to things like Bluetooth, USB, they were like, their position was largely we don't want other browsers holding, you know, having the ability to hold the platform back in this way.
Jake:And kind of just sort of shipped it anyway.
Jake:But there were specs for these features.
Jake:Whether those specs were good or not, I don't know.
Jake:But there were specs for these features.
Surma:Yeah.
Jake:All right.
Jake:Firefox.
Jake:Now, when I'm talking about Firefox and Safari, like I have internal knowledge from Chrome.
Surma:Yeah.
Surma:Yeah.
Jake:I don't with Firefox and Safari.
Jake:So, you know, it's more based on experience and to some degree rumor.
Surma:Yeah.
Surma:And especially with Safari, like, it's...
Surma:You know, with the Firefox people,
Surma:when I was attending the CSS working group at the time,
Surma:they are quite happy to chat
Surma:and even share knowledge
Surma:and what they're planning and working on and how it works.
Surma:Obviously less on the political side,
Surma:but just, like, how it works from...
Surma:The Safari folks are just not allowed
Surma:to talk about that kind of stuff.
Jake:Exactly.
Surma:to talk about that kind of stuff.
Jake:But with Firefox, like I feel in political terms, not a lot of votes, not a lot of power.
Surma:to talk about that kind of stuff.
Surma:to talk about that kind of stuff.
Surma:Mm.
Jake:They always felt like the minor part of a coalition.
Surma:Mm.
Jake:And back then they were a huge Chrome ally.
Surma:Mm.
Surma:Mm.
Jake:They agreed with the extensible web.
Surma:Mm.
Jake:They agreed about device features.
Surma:Mm.
Jake:And this was driven by Firefox OS.
Surma:Mm.
Jake:Because they had a big stake in the mobile space.
Surma:Mm.
Surma:Mm.
Jake:A whole operating system based on the web.
Surma:Mm.
Surma:They wanted the web to become capable
Surma:as, like, all the apps on your phone
Surma:should just be written as web apps.
Jake:Exactly.
Jake:Because they didn't want to write a special Firefox API to give you access to the file system on the device.
Surma:And so they needed those capabilities.
Jake:They wanted to use a web standard.
Jake:And that fit with Chrome's position.
Jake:So, they worked really well together.
Jake:But what I will say about Firefox is they were so strong on web standards.
Jake:If you built something and it was different in Chrome to Firefox, it would often be Firefox that was doing it right according to the standard.
Surma:Yeah.
Jake:Unfortunately, a lot of people would assume that Firefox was wrong.
Surma:Yeah.
Jake:Because it's a smaller browser.
Jake:But, yeah, that wasn't often the case.
Jake:Safari, back in the day, I'm going to say the word stagnant.
Jake:We had things like index DB bugs that were there for five plus years.
Jake:We had the 300 millisecond tap delay that was there for years.
Surma:Yeah.
Jake:Hacky internal scrolling on overflow scroll elements.
Jake:And maybe this was them suffering after the engines were forked, after Chrome forked WebKit to work on their own thing.
Surma:You say they were suffering,
Surma:but maybe it was just, you know,
Surma:I guess they didn't get
Surma:the free work from Chrome, almost.
Surma:At least they couldn't pull it back at some point
Surma:as... I guess fresh
Surma:after the fork, they probably could for a while
Surma:pull things back in because Chrome
Surma:or Blink remained open source, right?
Jake:Oh, exactly.
Surma:But I guess over time,
Surma:you can't just apply the same patch
Jake:Yeah, and my sympathy is sort of limited because this is one of the richest companies in the world, right?
Surma:to the WebKit base anymore.
Jake:Like, you know, they should be able to catch up pretty quickly on this.
Jake:But I think that might explain some of it.
Jake:Yeah, they weren't keen on the extensible web, it seemed.
Jake:Because what I heard being said a lot when we were working on Service Worker was, like, won't developers do bad things with this?
Surma:Yeah.
Jake:And my position was always, like, well, as long as they're only making their thing bad, it should be fine.
Surma:Yeah.
Jake:But it was kind of like, no, it was a feeling of almost a distrust of developers.
Surma:Yeah.
Surma:That's something I had as well
Surma:at the time when I was on the CSS working group,
Surma:mostly trying to look
Surma:after Houdini, where, you know,
Surma:the paint worklet and the animation worklet
Surma:and the layout worklet, all these, like,
Surma:kind of cool and exciting things at the time.
Surma:And I do remember
Surma:there was always pushback from...
Surma:Not pushback from Safari
Surma:as in, we don't want this,
Surma:but actually more like, we would much
Jake:Yeah.
Surma:prefer if this was declarative
Surma:than, you know, like an imperative
Surma:JavaScript API. And whenever
Surma:we tried to dig into that, they were like,
Surma:well, we would like to be able to
Surma:pre-calculate this and
Surma:know that only certain things
Surma:are possible and that we don't have
Surma:to accommodate for all weird
Surma:developer eventualities because it could just
Surma:give a really bad experience. And I was like,
Surma:yes,
Surma:I get that,
Surma:but it's a bit like a parent
Surma:who doesn't want their kid to run with scissors,
Jake:Yeah.
Surma:which, with a kid, you know, I get it.
Surma:But with developers, I usually
Surma:let them run with scissors because you can
Surma:already do really
Surma:bad stuff, even with just
Surma:CSS, like, let alone with JavaScript.
Jake:Yeah, and with JavaScript, how bad is it compared to while true?
Surma:So...
Surma:Yeah.
Jake:You know, and if it's no worse than that, if it's not, like, if it's only breaking the experience of that website, then I'm like, fine, whatever.
Jake:In terms of web standards, not good.
Jake:Like, new iPhones would come out with features, and they were just thrown onto the platform without any standardization.
Jake:Like, even as far back as touch events, you know, device pixel ratio, forced touch, you know, lots more vendor-prefixed CSS.
Jake:And there was, like, an Apple Pay API, which I think was the worst.
Surma:Hmm.
Jake:Because, yeah, it wasn't even a specific – like, there was never an API anyone else was going to implement.
Jake:It was just an Apple thing thrown straight on the platform without any standardization.
Jake:But I think things started to change, like, pretty early on with Safari, and this is when the privacy thing really came in.
Jake:And this was a company-level thing.
Jake:A lot of it was a way of attacking Google that it saw was, you know, a lot of Google's profits came from things that it felt were not good in terms of privacy.
Surma:Hmm.
Jake:But I think in terms of the web, it was a good shift.
Jake:It was used as a reason to push back on device APIs for fingerprinting, particularly.
Jake:And then there was, like, the third-party cookie blocking – well, third-party storage in general.
Jake:But again, no standardization.
Jake:You know, request storage access sort of appeared loosely described in the blog posts.
Jake:Yeah, I would say at least, you know, Google wasn't great in standardization at this time, but they did at least write specs.
Jake:But, yeah, there you go.
Surma:Yeah.
Jake:So that was then.
Jake:Where are we at now?
Jake:And have things changed?
Jake:Firefox.
Jake:Firefox OS dead.
Jake:That's gone.
Jake:Bye-bye.
Surma:Yeah.
Surma:I was excited, though, at the time.
Jake:Same.
Surma:Like, it was... I liked
Surma:the vision.
Jake:Oh, absolutely.
Jake:I had a Firefox OS device.
Jake:Yeah, it showed promise.
Jake:But, yeah, they couldn't make it work.
Jake:And as such, they really sort of just abandoned mobile.
Jake:I mean, you still get Firefox for Android.
Surma:Yeah.
Jake:I use it occasionally.
Jake:But it's – yeah, I think it's kind of a project of passion.
Jake:I don't think it's really, like, their core belief.
Jake:And with this, this was a huge swing for them in terms of ideology, because they were less a Chrome ally and more of a Safari ally, because they kind of really sort of – they took on the privacy thing.
Jake:That was something – you know, that was a strong bit of ideology for them as well.
Jake:But, I don't know.
Jake:Firefox is smaller still.
Surma:Yeah.
Jake:It hasn't – yeah, so.
Jake:But I will say, I mean, they do amazing work.
Jake:Working with them on web standard stuff was always amazing.
Jake:But a lot of their engineers have gone now to Chrome or Safari.
Surma:And not
Surma:necessarily by choice.
Jake:No, no, yeah, it was – you know, downsizing was some of it.
Jake:But in some cases, it was just the work they wanted to do or, you know.
Surma:True.
Jake:Safari.
Jake:Safari, I think, is ideologically – if I – I'll try and – no, I'm going to leave it at that.
Surma:True.
Jake:I'm not going to rerecord that.
Jake:Just leave it at that.
Jake:I think they're the least changed.
Jake:And I think that's because the privacy stuff was already happening – you know, the change was happening earlier.
Surma:At the same time,
Surma:they deserve a bit of credit for
Surma:giving Safari or WebKit
Surma:more love. They have... I'm not saying
Jake:Oh, yeah.
Surma:they have, you know, been...
Surma:They're now up to speed, necessarily,
Surma:or gone about it a great way, necessarily,
Surma:but they have definitely
Jake:Yeah.
Surma:fixed a lot of things,
Surma:added a lot of APIs that were missing,
Surma:and have become a much
Surma:more capable and
Surma:likable web engine
Jake:Yeah, a lot of those annoying bugs I mentioned have been fixed.
Surma:in my books.
Jake:The team grew.
Jake:They took on a lot of strong standards advocates from Firefox or independents.
Surma:True.
Jake:And they had an active dev rel for the first time, it seemed.
Jake:And, you know, by which I mean Jen Simmons, who I've clashed with on a number of things,
Surma:True.
Jake:but I cannot fault her community engagement and, you know, actually listening to developers.
Jake:And it's not just – it doesn't feel like fake listening.
Surma:Not true.
Jake:Like, it feels like the listening has happened and change has happened as a result.
Jake:Yeah, but I also feel it has been a shift towards Chrome's position.
Jake:Like, we – you know, we got push messages recently.
Jake:Background fetches behind the flag.
Surma:Yeah.
Jake:There's, you know, custom element, more custom element stuff, more engagement on the standards there.
Jake:The paint API is behind the flag.
Jake:But, you know, there's been development effort in these lower-level things.
Jake:But still a strong lean towards the high-level stuff.
Jake:Lots of – you look at their release notes, like the CSS stuff is often the biggest section in terms of features.
Jake:They're pursuing things like the model elements rather than WebXR.
Surma:Yeah.
Surma:But then again, I feel like,
Surma:in general, the
Surma:last couple of years,
Surma:CSS in general has gotten a lot of
Surma:focus, a lot of love, from
Surma:Chrome and Safari.
Jake:Well, let's – well, just to finish the loop on Safari, I would say, yeah, web standards, they've got a lot better at –
Surma:You just almost
Surma:said close the loop, didn't you?
Jake:close the loop.
Jake:Yeah.
Jake:Sorry.
Jake:But what you say is right.
Jake:Like, we have seen, like, from Chrome, pretty big ideological changes.
Jake:Not as much as Firefox, but more than Safari.
Surma:Yeah.
Jake:And, yes, it is that shift away from the extensible web to heavy investment in CSS.
Jake:And that's reflected in DevRel as well.
Jake:Like, you've got Yuna, Adam, Bramus.
Jake:Like, they're heavily focused on CSS.
Jake:Whereas before them three, like, it was just, you know, people like me and you sort of making it up.
Surma:One of these things is not like
Surma:the other.
Jake:Exactly.
Jake:So, specialists in CSS, which we never were.
Surma:Yeah.
Jake:And, yeah, Chrome, you know, we got Scroll Snap.
Jake:We started to get a few transitions.
Jake:We got Scroll Timeline rather than Animation Worklet.
Jake:Like, you know, these are higher level visions that were, you know, not allowed a few years ago.
Surma:Yeah.
Jake:Static Roots and Service Workers, they're coming.
Jake:There is definitely some shift towards listening to developers more and DevRel through them.
Jake:That you get, like, the surveys being used to justify work.
Surma:Yeah.
Jake:I do still think there's too much project manager influence compared to DevRel.
Jake:But, you know, whatever.
Surma:Yeah.
Jake:I think things are getting better there.
Jake:And, again, web standards have got better.
Jake:Probably due to, you know, more of a focus on the kinds of things that Safari like.
Jake:So, there's less to clash on.
Jake:But there is also the interop efforts, which, you know, brought the browsers together on some features.
Jake:So, I think it's a good initiative.
Jake:So, that brings us to the future.
Surma:Yeah.
Jake:And kind of what would we like to see?
Surma:The web is dead. Move on.
Jake:Ah, well.
Jake:Well, Chrome.
Jake:What would I like to see from Chrome?
Jake:My experience working on Chrome was there was three kinds of Chrome employee.
Jake:There were web people who, like, acted like they worked for the web but were paid by Google.
Jake:Like, they were sponsored by Google to do it.
Jake:There were Google people who were, you know, signed up members of Google and were interested in doing whatever.
Surma:Right.
Jake:Made Google good.
Jake:And then the third kind was people who were just there to do a job.
Jake:And didn't really care either way.
Jake:Which is fine, right?
Jake:You know, that's a total fine.
Jake:That's a fine way to have a job.
Jake:But I just hope the web people stay strong.
Jake:You know, don't, you know, make sure the job being done is good.
Jake:Make sure it's good for the future of the web.
Jake:And especially when that clashes with what Google might want.
Jake:You know, stick to what is good for the web.
Surma:Yeah.
Jake:Listen to developers.
Jake:And via their dev rel.
Jake:Yeah, question whether these things are the features being asked for.
Jake:Is it just the thing that Airbnb wants or Facebook wants?
Jake:Or is it actually useful to the developer community at large?
Jake:But I would like to see a little bit of a look back at the extensible web for, like, you know, I want platform physics.
Surma:Yeah.
Jake:Like, if I'm developing my own pinch zoom component, I want to be able to use platform physics in a way that, you know, is going to feel like the Maps app on the platform.
Surma:Yeah.
Jake:Like, if I do a pinch zoom, you know, and the user lets go, is it going to move a bit?
Jake:And is it going to feel like iOS?
Jake:Is it going to feel like Android?
Jake:Or, you know.
Surma:And I think I agree with that.
Surma:One artifact that I liked in terms
Surma:of addressing
Surma:developer pain points, and I guess in a way
Surma:you could even say tech debt,
Surma:as much as that can be used in a
Jake:Thank you.
Surma:standard space.
Surma:Like, for example, the new navigation API.
Surma:I was like, yes.
Surma:Because this is, in that sense, not
Surma:really a new capability,
Surma:but my god does it make
Surma:my life easier having
Surma:this more holistic API
Surma:to actually handle navigation and
Surma:routing at the spot where it makes
Surma:sense and not like shorn on. And I still
Surma:think there is
Surma:a lot of stuff that could be
Surma:learned from how app development
Surma:on native platforms work
Jake:Okay.
Surma:in terms of, for example,
Surma:views. I still think
Surma:it doesn't
Surma:feel super intuitive thinking
Surma:in views
Surma:when you do web development where you have
Surma:something that fills the screen
Surma:and you want to put multiple scrolling
Surma:elements in there or a sidebar.
Surma:There's still a bit of
Jake:Yes, absolutely.
Surma:legacy from the document
Surma:web that kind of interferes. And I know
Surma:the web is different with backwards compatibility,
Surma:but I liked that with
Surma:the navigation API. You know what?
Surma:That is a pain point. We're going to sit down and design
Surma:something that actually slots into
Surma:the browser where this
Surma:should happen. I'm kind of hoping
Surma:that that is a trend that will
Surma:continue.
Jake:And yeah, one of the features of that is, yeah, your inner scroller elements behave differently to the top level one, even if one fills the screen.
Surma:Yeah, exactly.
Jake:So, yeah, having some way to, you know, change what is considered the main scroller, I think would help a lot there.
Jake:But, yeah.
Surma:Yeah.
Jake:So, yeah, poke at that sort of stuff.
Jake:For Safari, I like keep doing the privacy thing.
Jake:It's important to have this, you know, at least this two-party system.
Jake:Keep listening to developers.
Jake:Keep that trend up and keep the trend of investment.
Surma:Yeah.
Jake:I hope Apple keeps up this trend of investing more in WebKit.
Jake:And I know some of that is driven by, like, the legal stuff, you know, the question around, like, you know, is it fair that they keep themselves the only browser on iOS?
Surma:Yeah.
Jake:But, hey, look, if that's the thing that drives them, then fine.
Surma:The other thing I would love
Surma:to see from them, less
Surma:political, is
Surma:on the one hand that
Jake:Oh.
Surma:filing an issue on WebKit
Surma:would feel a bit less like shouting into the
Surma:void because they have a copy of their
Jake:Radar.
Surma:own internal issue tracker so that you don't actually
Surma:know whether the thing is
Surma:getting addressed or not.
Surma:And in general, just
Surma:have a higher
Surma:release cycle. Don't make
Jake:Oh, yes.
Jake:We did a whole episode on is Safari the new IE.
Surma:us wait.
Jake:And, you know, in some ways, yes, in some ways, no.
Jake:But one of the ways, yes, is the release cycle.
Jake:That is getting better and better.
Jake:So I would say, you know, keep that trend going.
Jake:Ideally catch up to Firefox and Chrome on that would be great.
Surma:Yeah.
Jake:But, yeah, trust developers as well.
Jake:Like, trust them with lower-level APIs as long as they're only breaking their own thing.
Surma:Yeah.
Jake:Yeah.
Jake:Do allow developers to be creative with this low-level stuff.
Jake:And consider more platform capabilities as well.
Jake:Can you do the Bluetooth thing in a privacy way?
Jake:Can you do the Web USB thing?
Jake:I love on Chrome that, like, when Stadia was abandoned, it was really nice that you could go to a website, plug in the Stadia controller, and it would flash it so it could be a generic controller now.
Surma:Yeah.
Surma:That's cool.
Jake:And, yeah.
Surma:I didn't know that. That's a really cool story.
Jake:Exactly.
Jake:So you didn't have the, you know, it was no long ‑‑ it meant it wasn't just a piece of tech trash.
Jake:It was usable now.
Surma:Yeah.
Jake:But also that they, you know, you didn't have to make a special Linux app, a special Mac OS app, a special Windows app to make that happen.
Jake:It was just done on the web.
Jake:And I think that was ‑‑ in terms of privacy, it's better to be doing that in a browser than a native app which has way more ‑‑ can abuse privacy.
Surma:True.
Jake:Yeah.
Jake:If you push people into a native app, they're losing the privacy game more.
Jake:And my advice to ‑‑ or what I want from Firefox is just stay alive.
Jake:Like, please.
Jake:You know?
Jake:And if you can't keep the engine running, if you can't keep Gecko up, then please be WebKit.
Jake:I think I would ‑‑ you know, if they have to abandon Gecko, and I hope they don't, I really hope they don't, but I hope they become the Windows WebKit instead.
Surma:What I was just saying,
Surma:for a first episode, we're
Surma:coming back,
Jake:Well, this has been a long record.
Surma:burning through all of the material
Surma:so we can immediately not do a new
Surma:episode for two or three months.
Surma:Yeah.
Jake:I hope we can edit this down from ‑‑ well, we'll let people know we've been recording for an hour and a half now.
Surma:Yeah.
Jake:So it's probably going to be a long episode, but I think there's bits we can cut out to make it a little bit more manageable.
Surma:Yeah.
Surma:Yeah, just cut my bit.
Jake:Absolutely not.
Jake:Absolutely not.
Jake:Well, should we ‑‑ should we stop?
Jake:I mean, the longer we're going on now, the more we have to cut.
Jake:So, yeah, I suppose we should go away.
Surma:Yeah.
Jake:So how are we going to do this?
Jake:We used to have a catchphrase.
Jake:We used to say, happy next time, which is ‑‑ is it?
Surma:Yeah, we need a new one because
Surma:the old one is copyrighted still, right?
Jake:Oh.
Surma:It's not our intellectual
Jake:Okay.
Surma:property, I suppose. We need to ask
Surma:Mariko to come up with a new phrase because
Jake:She did.
Surma:she came up with the old phrase, so now she's
Surma:on the hook for the new one.
Jake:So we could just do ‑‑ we could just do an Irish exit.
Jake:Okay.
Jake:Are you aware of the term to do an Irish exit?
Surma:I have been introduced to the
Surma:term by, ironically,
Surma:Paul Irish.
Jake:Me, too.
Jake:Yes, okay.
Jake:So for anyone who doesn't know, Irish exit is when you just disappear.
Surma:Yeah.
Jake:So, you know, at a party and you just kind of, like, sneak out.
Jake:I think it's a good ‑‑ you know, I've used it before.
Jake:It means you don't have that, oh, stay for another drink.
Jake:You just ‑‑ oh, exactly.
Surma:Or if you feel
Surma:obliged, just go to everyone and
Surma:give a hug, shake their hand,
Surma:I don't know, just say goodbye to
Surma:everyone individually so nobody feels neglected. This way,
Surma:everybody feels equally neglected.
Jake:Exactly.
Jake:And I ‑‑ same as you, like, Paul Irish does this.
Jake:And that's how, you know, Paul ‑‑ I think I was at a party or something,
Jake:and I was like, oh, has Paul gone?
Surma:Yeah.
Jake:Oh, yeah, he's done the Irish exit.
Jake:And I thought that they were naming it after Paul Irish.
Surma:I thought that as well.
Jake:Brilliant.
Jake:Because from then on, like, I heard the term again in other circles,
Jake:but it just coincidentally, it seemed to be from someone who has a,
Jake:you know, would know Paul Irish.
Surma:Like,
Surma:six degrees of bacon, but with
Jake:Yeah, exactly.
Surma:Paul Irish.
Jake:So they'd say, oh, he's doing an Irish exit, and I'd be like, oh, yeah,
Jake:Paul, yeah.
Jake:But then I heard it from someone else, like, outside of tech,
Surma:Yeah.
Jake:and they were like, oh, yeah, well, I might just do an Irish exit.
Jake:Oh, you know Paul Irish.
Jake:They're like, what are you on about?
Jake:I don't know.
Surma:Yeah.
Jake:I need to have this conversation, because that's when I started to realize,
Jake:you know, the whole thing is nothing to do with Paul Irish.
Jake:It's a big coincidence, and, yeah, I felt like a fool.
Jake:But, yeah, should we just do an Irish exit?
Surma:So, we'll be then,
Surma:we'll just stop.
Jake:Go for it.
Surma:Yeah.
Surma:I do like this API a lot.
Surma:Oh, one thing I wanted to,
Surma:oh,
Surma:I'm going to quickly go to the door, I guess.