WebGPU and Browser Ideologies

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.


  1. Surma:Dude, we can technically... Well, we could swear now on OTMT. I think so far I have selected that
  2. Surma:this podcast is clean. I don't know what the different guidelines are, so I feel like
  3. Surma:I may have to revisit that choice.
  4. Jake:Oh. I think we can stay... So here's the thing, like, in our previous podcast, for
  5. Jake:the last few episodes, I was doing the edit, and I'm sure there was an easier way to do
  6. Jake:it than I was doing it, but bleeping stuff out was a lot of effort. So that's why I didn't
  7. Jake:swear. Because every time I, you know, if I was about to swear, if I felt like swearing
  8. Jake:was justified, I would just feel like, no, this is effort if I do this, so I'm just going
  9. Jake:to pick a different word. And then every time you swore, I was like, ugh, I rolled, because
  10. Jake:ugh, I'm going to have to find that, I'm going to have to bleep that, thanks, I'm a great
  11. Surma:Yeah, you know, I was... And I knew this. I was just going, you know what? Fuck you, Jake.
  12. Jake:I don't care now, so fuck you too!
  13. 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
  14. Surma:Oh, this isn't... Yeah, sorry. I'm Surma. Well off the main thread.
  15. Jake:no, no, we're not, we are off the main thread. Because Google wouldn't let us keep the name.
  16. Surma:So good.
  17. Jake:Right, yeah, it's a clever name, isn't it? Because it's, it's, it's a, because, because
  18. Jake:of like workers, right, it's off the, you know, there's the main thread, and there's the,
  19. Jake:the other, you know, it's very smart, but also, oh, we go off topic, we're off the main thread,
  20. Surma:Yeah.
  21. Jake:we're a bit zany, a bit mad, yeah, you know, whatever, okay, it's a new, it's the new name,
  22. Jake:that's the name we picked. Okay, I really hate people who define themselves as quirky. Anyway,
  23. Surma:So quacky.
  24. Jake:let's not get sidetracked too early, because in this episode, we're going to talk about,
  25. Surma:Yeah, well, it's... I feel like we've talked about this before,
  26. Jake:we are going to be talking about web GPU APIs, is that right? Excellent.
  27. Jake:Yes, it was a one we recorded late in the Google era, that never quite, never quite made it out.
  28. Surma:but I also feel like that episode has never seen the light of day.
  29. Jake:But also, later in the episode, I'm going to be talking about the differing ideologies of
  30. Jake:the browser engines, and how that impacts the kinds of features that make it onto the web
  31. Surma:I'm sure it's not going to be inflammatory at all.
  32. Jake:platform. That's our intention, anyway, but, you know, I think, I think it's fair. But yeah,
  33. Jake:we're not at Google anymore. So, I mean, not that we were ever singing from that particular
  34. Jake:hymn sheet, I'm losing the metaphor. Do you know what, someone, someone at Shopify messaged me
  35. Jake:last night, saying that, you know, we need to be careful with some messaging,
  36. Surma:Ah, I like stirring the boat.
  37. Jake:because we don't want to stir the boat. I like stirring the boat as well. So,
  38. Jake:like, they did, they did acknowledge that it was 6am in their time zone. So,
  39. Jake:I think you can forgive them. But I love that as a as a little mixed metaphor there.
  40. Jake:Um, exactly. But I thought, like, you know, first episode, let's, let's get,
  41. Surma:Yeah, you can just shave them all over one hat.
  42. Jake:let's get straight into the tech stuff. So, shall we talk about the web? I do.
  43. Surma:You want to talk about the web? All right.
  44. Surma:All right, so web GPU. Actually, you know what? GPUs. And actually, you know what? Low-level stuff.
  45. Surma:It's not everyone's cup of tea, but I've been thinking about this a bit, and I feel like
  46. Jake:Hmm.
  47. Surma:I've been starting to think about developers as bottom-up and top-down coders. You know, this
  48. Surma:whole bottom-up versus top-down, I think it permeates all of software engineering.
  49. Jake:Yeah, I do know what I completely agree with you and it's one of the things that I have
  50. Surma:But I feel like before I use something, I want to understand it and kind of do a depth-first
  51. Surma:search so I understand what is happening there and have an appreciation for it. And then there is...
  52. Jake:going into a new company, because I am now also at Shopify, it's the thing I've struggled with.
  53. Surma:Yeah, just lie to yourself.
  54. Jake:I feel like I can't do anything until I know a certain percent of the thing.
  55. Jake:I think it's mostly perceptual. I need to feel like I know 20% of it,
  56. Jake:even though I probably will only know 5%, but until then I can't get anything done with it.
  57. Jake:And yeah, well, but WebGL is one of the things that I never gained enough confidence in to be
  58. Surma:Right?
  59. Jake:able to do much. I built like two demos in it. I always wanted to do 2D stuff with it.
  60. Jake:Although WebGL was never my cup of tea, as you put it,
  61. Jake:I want WebGPU to be my cup of tea, even though I don't like tea.
  62. Surma:And you know what? I think we can get there. But anyway, I kind of realized that... So I would say
  63. Surma:that, you know, similar to you, we are kind of like the bottom-up. We like to understand the
  64. Jake:Hmm. Ironically, the leaves are at the top of the tree, but whatever, we won't.
  65. Surma:leaves and build stuff on top. And then there's the people who are... Yeah, in the good old days
  66. Jake:Yeah. Yes.
  67. Surma:when trees were growing from the top to the bottom. But then there's these top-down people who are
  68. Surma:not only happy but also really good at using something without digging under the hood and
  69. Surma:like somewhat frustrating you. Those are the people that get done. Those are the people that
  70. Surma:finish projects. And I think everybody is somewhere on this spectrum and nowhere is really
  71. Surma:at the extremes of it because, you know, otherwise you have to go full Carl Sagan to, like, to bake
  72. Surma:an apple pie. You would have to invent the universe. And so, like, you know, I've done...
  73. Surma:I've written assembly by hand because I like low-level stuff, but I do not know how a transistor
  74. Surma:works, like, in detail, for example. So I think everybody has somewhere where they draw the line
  75. Surma:of how deep they want to go. So I think it's similar to you. I want to make use of GPUs.
  76. Surma:They're there in your device and they're, you know, kind of like a bit mystified but really
  77. Surma:powerful. But then when you look at stuff like OpenGL or WebGL, like, it just didn't click for me.
  78. Jake:Hmm.
  79. Surma:And then I, in the periphery, kind of learned, you know, like these new next generation graphics
  80. Surma:APIs are coming around, like Metal, DirectX 12, Vulkan, and they give you even more low-level access
  81. Surma:to the GPU. You genuinely program them rather than drawing triangles, which was a bit the
  82. Surma:perception I had beforehand. Yeah, I mean, shaders were a thing, but still they were very
  83. Jake:Are you talking about like the existence of shaders? Is that when you say programming the GPU?
  84. Jake:Hmm.
  85. Surma:predefined slots, you know, like you had the vertex shader and the fragment shader,
  86. Surma:one runs on vertices, the other on pixels. And if you weren't trying to use the GPU for something
  87. Surma:that uses vertices or pixels, what do you do? And always felt a bit odd. And also,
  88. Surma:I don't know, it just didn't really click. And then these new API, these new graphics APIs
  89. Surma:were coming about and kind of people were saying, this is how you program on the GPU.
  90. Jake:Hmm.
  91. Surma:And I tried to look at them and it, like, went too far the other way. It was so low-level where
  92. Surma:you're, like, genuinely, you know, do your own memory management on the GPU and you kind of have
  93. Surma:to know what the GPU is like. But I never really understood what a GPU is like. And also, what
  94. Surma:really personally frustrated me, and it's all platform-specific. So Metal is what you use when
  95. Surma:you are on an Apple device. DirectX 12 is what you use when you have Windows running. And Vulkan
  96. Surma:is technically, like, open, an open standard, but I'm not sure if you can write Vulkan on all
  97. Jake:Hmm.
  98. Surma:devices. It needs to be, like, a retranslation layer. And that kind of put me off. And
  99. Jake:And that's where things like Unity come in, right? They're the ones that you let
  100. Jake:you write once and it compiles to these various... Hmm.
  101. Surma:yeah, but that's more like a game engine, right? You're not programming for the GPU,
  102. Surma:you're building a game and you're still just writing shaders to an extent. And maybe I'm
  103. Surma:wrong because I have, I should say, like, I'm not a game development expert. I'm not a GPU expert
  104. Surma:or anything like that. But that was just how I perceived the state of GPU programming, I guess.
  105. Jake:Hmm.
  106. Surma:And it just always felt like a big barrier to entry. And then, I guess, a bit by coincidence,
  107. Surma:like, I got wind of WebGPU and a couple of things just, like, immediately stood out. And the first
  108. Surma:thing was that the WebGPU API, well, it's on the web, so that's good, you know. But it's not
  109. Jake:Yeah.
  110. Surma:coupled to Canvas. You obviously can because it's supposed to do the graphics thing. But you can just
  111. Surma:use the GPU for stuff that doesn't have anything to do with graphics. You can just use it to...
  112. Jake:All right, so because WebCL was the... I don't even know if it ever became a thing,
  113. Jake:but WebCL was the kind of equivalent to WebGL. I think WebCL was going to be the WebGL where
  114. Surma:I've never heard of that.
  115. Jake:you didn't have to render it, right? Like it was the sort of compute layer, I think.
  116. Surma:Ah, interesting. Yeah, I don't think that got anywhere.
  117. Jake:Oh, god. Yeah, I'm losing confidence as I'm talking.
  118. Surma:Google it right now.
  119. Jake:Okay. Okay. Let's see. Let's play. Yeah.
  120. Surma:It sounds like OpenCL because that's the, you know, the library language framework for which
  121. Jake:Yeah, okay. Yeah, it's a Kronos thing. Yeah, and it is a JavaScript binding to OpenCL, as you say.
  122. Surma:you write C and C++, I think, to run code on the GPU, but it has nothing to do with graphics
  123. Surma:necessarily. So, the naming would make sense.
  124. Jake:Like, you know, so it is akin to WebGL in that it's a sort of direct binding to
  125. Jake:something from outside the lands of the web, JavaScript.
  126. Jake:Yeah.
  127. Surma:Right. So, you know, recently, using the GPUs for other stuff than graphics has
  128. Surma:gotten increased attention. You know, the first era was, I guess, you know, crypto mining, which
  129. Surma:is boom, go with that. But now we are more in the neural network machine learning era, where
  130. Surma:running massive neural nets, which is just heaps and heaps of matrix multiplications,
  131. Jake:Hmm.
  132. Surma:which GPUs are really good at, people want to use those. And so, while it's possible with WebGL,
  133. Surma:it's not necessarily easy or as performant. And so, I was interested. And the other thing that
  134. Surma:stood out for me, it's just this WebGPU API is webby. Because if you look at WebGL and you've
  135. Jake:Oh, and I have
  136. Surma:ever and you have looked at OpenGL, you'll notice that WebGL is literally the C API just exposed
  137. Surma:via JavaScript. A couple of minor like wrappers, because some things just don't map well, but it's
  138. Jake:to...
  139. Surma:pretty much one-to-one, which on the one hand is good. You know, if you learn one thing and you can
  140. Surma:use it in both places, but it just doesn't feel like a good web citizen. And as a web developer,
  141. Surma:it will not be intuitive for you. Right. Yeah, I had a similar feel with that. And what I noticed
  142. Jake:No, and this was always the blocker for me in WebGL is I... It just didn't feel like the kind
  143. Jake:of APIs I was used to. It didn't feel like a web API. So, I could never really get... I mean,
  144. 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
  145. Jake:of times, but it was a lot of copy and pasting and not understanding a whole block of code.
  146. Jake:Just to get to a bit, I did understand.
  147. Surma:with WebGPU that the opposite is happening. So, WebGPU being standardized with, and I want to
  148. Surma:point this out, with all three browsers actively participating in the design. So, while it's
  149. Surma:currently only launched and stable in Chrome, I'm behind the flag in Firefox. I am actually fairly
  150. Jake:So,
  151. Surma:confident that Safari will also ship this. And that by itself is already quite exciting because
  152. Surma:for years Safari was super behind on adopting the newer versions of WebGL.
  153. Jake:weren't they wanting to bring metal to the web? Wasn't that part of their thing for a while?
  154. Surma:Yes. And I'm not going to try and recite the, you know, GPU on the web drama on how it went. There
  155. Surma:was lots of conspiracy theories, I think, and I don't care. I really like WebGPU and I'm hoping
  156. Jake:Hmm.
  157. Surma:that all the browsers ship it. And if that happens, I'll be happy. But yeah, what I meant to
  158. Surma:say is that the opposite is happening in that the design that WebGPU has, which I think is quite
  159. Surma:pleasant, we're going to talk a little bit about it, has now gone the other way where it's now
  160. Surma:being adopted by native language ecosystems. So, there is Dawn, which is a C++ library written by
  161. Jake:
  162. Surma:the Chrome folks, which is what they use to basically expose WebGPU to a renderer, to a
  163. Jake:Oh!
  164. Surma:browser thread running. But it's effectively the WebGPU API in C++. So, if you learn WebGPU,
  165. Surma:you can use it on the web. But if you're a C++ developer, you can also use it from C++ with
  166. Surma:this library. And of course, the nice thing is that it abstracts away whether you're running
  167. Surma:on Mac, Windows, or Vulkan or something. You just learn this one API and you get access to the GPU.
  168. Surma:And there is a crate called WGPU, which does the same thing in Rust. And that really was...
  169. Jake:So, I wonder if the C++ engineers and the Rust engineers hate this API as much as I hated the
  170. Jake:WebGL one, you know, that was based... I don't know. That's a question for others.
  171. Surma:I don't know. I would hope not, because I find it quite nice, both from using it from Rust as
  172. Surma:well as using it from the web. But then again, I don't know. So, yeah, you learn this one API.
  173. Surma:You can use it on the web. You can use it natively. It abstracts away which API is available
  174. Surma:in the operating system. It seems like a really good bang for the buck. If you want to learn how
  175. Surma:to program, if you want to use your GPU for something, this seems like a really good time
  176. Surma:investment rather than learning every single platform API. I suppose there might still be
  177. Surma:benefits if you need to squeeze the last bits of performance or something. I don't know,
  178. Surma:because I'm not that deep. But I like being a web developer and building something that can run
  179. Surma:on whatever device you have. And that this continues now with GPU coding gets me quite
  180. Jake:Yeah, that's what I understood. It's like they're rubbish little cores, but there's many of them. So,
  181. Surma:excited. The thing we should talk about a bit, because that's something I never understood
  182. Surma:before this either, is what actually is a GPU? What is different about them? Because for me,
  183. Surma:I always was like, it's just something with very many cores.
  184. Jake:it could do lots of little bits of work.
  185. Surma:Yeah, and I was like, why don't we just use that for our CPUs as well? I mean,
  186. Surma:why don't our CPUs have like 1,500 cores? And I've learned more since then that they just have
  187. Jake:Hmm.
  188. Surma:a wildly different architecture because they have a different goal, a different thing that
  189. Surma:they're optimized for, because GPUs are optimized for throughput at the cost of latency. And that
  190. Surma:might sound like I got it backwards, because it's only thanks to GPUs that we managed to render
  191. Jake:60 frames a second. Yeah. Yeah, sure.
  192. Surma:an image at 4K at 120 frames a second, I would say. But it seems like, clearly, they're pretty
  193. Jake:Yeah.
  194. Surma:good at a latency game. And I won't and I can't go into full detail, because on the one hand,
  195. Surma:it's all, there's lots of secrets and NDAs about the actual specific architectures of GPUs. But
  196. Surma:there is a really great 13-part blog post series I'm going to link to if people want to dive into
  197. Jake:Yeah.
  198. Surma:this. I found it super interesting. Even though I think it's over 10 years old now, it's still
  199. Surma:fairly valid. And I talked to a couple of the WebGPU folks who said, I don't know, this is
  200. Jake:Yeah.
  201. Surma:accurate in the concepts and everything, because nobody can really at least openly speak about the
  202. Surma:actual details. So understand what this means to optimize for throughput over latency. We have to
  203. Surma:talk a little bit about how these GPUs are designed. Intel actually has a fairly good
  204. Surma:description of what the built-in GPUs work like. And so I guess the other GPUs are at least
  205. Surma:conceptually similar. And the main thing that I take away is that they're built, the architecture
  206. Jake:Mm hmm.
  207. Surma:is hierarchical. So there's multiple layers of how cores are grouped. And at the lowest layer,
  208. Surma:usually people talk about execution units. So you could think of it like a single core, that is an
  209. Surma:execution, but not quite. So let's just, I'm going to stick to the terms that I've learned. So at the
  210. Jake:Yes.
  211. Surma:lowest level of this hierarchy, you have the execution unit, and that is a SIMT core. You may
  212. Surma:have heard of SIMD, you know, single instruction, multiple data, which is what we have in the
  213. Jake:Mm hmm.
  214. Surma:CPUs. You have, usually it's a vector operation. So if you have, you know, two four-dimensional
  215. Surma:vectors and you want to add them, you technically have to do four additions for each component in
  216. Surma:that vector. With SIMD, that's a single instruction that is operating on multiple data, namely each
  217. Surma:component of the vector. So you can do this addition in one, in O of one, basically. And I'm
  218. Surma:going to say one cycle, because it's probably multiple cycles, but it's one instruction,
  219. Surma:effectively. Multiple tech, actually, if I didn't know, I would believe you. It's single instruction,
  220. Jake:Okay, so SIM T, so single instruction, multiple texels.
  221. Surma:multiple threads, which is very confusing in a way, because we're just saying, wait, we're on a
  222. Jake:Oh, of course. Oh, yeah.
  223. Surma:single core. But this still means you have the single instructions and it's executed by multiple
  224. Surma:threads, which are like kind of like sub-cores in this execution. But the difference here is that
  225. Surma:each thread in this execution unit has its own set of registers and stack pointers. So all the
  226. Jake:Mm hmm.
  227. Surma:cores or all these threads in this execution unit are operating in lockstep. They have to execute
  228. Surma:the same instruction, but have their own set of registers that can actually, you know, build up a
  229. Surma:different calculation over time, as long as the execution, the instruction series remains the same.
  230. Jake:Mm hmm.
  231. Surma:And this is actually the reason why in many parts of the shader writing community and stuff
  232. Surma:like that, people avoid if-elses or loops. Yeah.
  233. Jake:Mm hmm.
  234. Surma:Kind of. So it will have to execute both branches of an if-else,
  235. Jake:Okay.
  236. Surma:if there's two parts in the one execution that take different paths. If every single
  237. Jake:I see.
  238. Surma:thread in one execution takes the same branch, I think it can avoid executing the else.
  239. Jake:Oh, interesting.
  240. Surma:I don't know if it's working at this level. This is generally just making assumptions. But yeah,
  241. Surma:basically the assumption is if you have an if-else or if you have a for loop and one thread has to
  242. Surma:continue looping, the other ones have to loop with it and just discard the results. And they can do
  243. Surma:that. They have the architecture to run code that isn't whether you just discard the results. But
  244. Surma:obviously, that is wasteful. And this is all about throughput. So having a thread that does
  245. Surma:pointless calculations is something where you could have had more throughput if you had done
  246. Jake:Mm hmm.
  247. Surma:better, you know. So that's one of those parts where you can already see the first manifestation
  248. Surma:of how it's optimized for throughput. And the other part is, and this I think is really interesting,
  249. Surma:that as on the CPU, also on the GPU, while it has very closely co-located memory to work with,
  250. Surma:that is often faster than what we have for the CPU, it's still slower than the cores. So getting
  251. Surma:data from memory takes time. And so when a core or a thread needs some data, it is often just not
  252. Jake:Mm hmm.
  253. Surma:available straight up. And so what these cores, these execution units are optimized for is that
  254. Surma:they can really efficiently store the current state and switch to a different task or switch
  255. Surma:to the next work item that is scheduled. So most of these execution units are heavily oversubscribed
  256. Surma:on work. So whenever they have to wait for something, rather than waiting, they switch to
  257. Surma:working on something else. And then when they have to idle again, they switch back. And this is where
  258. Jake:Mm hmm.
  259. Jake:Ooh.
  260. Surma:I think the main part of the throughput versus latency trade-off comes in. Because as long as
  261. Surma:all cores are busy doing valuable work all the time, throughput is high. Your megaflops or
  262. Surma:teraflops, floating point operations per second, like you are doing work that is good. The scheduler
  263. Surma:is doing its job right. But the individual work item may take longer because just because the
  264. Jake:Mm hmm.
  265. Surma:data has now arrived doesn't mean that the thread will immediately switch back to continuing
  266. Surma:on that work item. It will just continue working on work items and still it has a reason to switch
  267. Surma:back to something else. And so individual work items will take longer. Latency is increasing
  268. Surma:on a per work item basis. But overall, throughput is maximized. Utilization is maximized, which means
  269. Surma:throughput is high and the whole thing just gets work done more efficiently per second, I guess,
  270. Jake:Yeah, it does, but it's got me thinking, like, computers are complicated, aren't they? I mean, wow.
  271. Surma:or however you want to measure this. Does this make sense? They really are.
  272. Surma:Again, this was just the base level of the hierarchy. Because now we go one level up,
  273. Surma:where multiple of these execution units are grouped together in what at least Intel calls
  274. Surma:a sub-slice. So this is a bunch of these execution units together and they have a tiny amount of
  275. Jake:Mm hmm.
  276. Surma:shared memory. We're talking like a couple of kilobytes. And that is mostly for synchronization
  277. Surma:purposes. Because sometimes you have to coordinate that nobody overwrites the result of somebody
  278. Surma:else. Of course, you want to avoid that because when you synchronize, you have to wait. And that
  279. Surma:is bad in GPU land. But sometimes it's necessary. And so they have limited that only within one of
  280. Surma:those sub-slices, you can wait for each other. And then the next level of hierarchy, at least
  281. Jake:Mm hmm.
  282. Surma:as described by Intel, would be a slice, which is a group of multiple sub-slices. And so this
  283. Jake:Mm hmm.
  284. Surma:I found really interesting because this is three levels. I wonder maybe if other manufacturers have
  285. Surma:more hierarchy levels or not. And often when you hear cores, it gets quite interesting.
  286. Jake:Mm hmm.
  287. Surma:What I've seen as that's like an integrated Intel GPU ends up with a total of 170 to 700 cores.
  288. Surma:Now, I actually am not sure what is a core because they talk about execution units,
  289. Surma:sub-slices and slices. So is a core, I guess it's one of those execution units. But just to compare
  290. Jake:Oh, okay.
  291. Surma:like a desktop GPU can end up with 1500 cores nowadays quite easily. Or for example, the Apple
  292. Surma:M1 GPU that is in the smallest version, the MacBook Air has seven or eight cores, where each
  293. Jake:Yeah, yeah.
  294. Surma:core has 16 execution units, where each execution has eight LAUs, algorithmic logical units.
  295. Jake:Do the maths for me. How many is that?
  296. Surma:And that's what I mean. It's really hard to compare. So what people usually do to compare
  297. Jake:Hmm.
  298. Surma:is they compare how many floating point operations or flops you can do on a GPU per second. So
  299. Jake:Flops.
  300. Surma:for example, as I said on my Apple M1, you get 2.6 teraflops, which that sounds pretty good.
  301. Surma:And then I looked up the Pixel 8 Pro can do 3.2 teraflops.
  302. Jake:Flops.
  303. Surma:Yeah, what the fuck are they talking about? But yeah, so this is obviously, I guess the MacBook
  304. Jake:Exactly.
  305. Surma:Air M1 is more like a mobile device and a desktop device. So if we were to look, for example, at the
  306. Surma:Apple M1 Max, we were at 10 teraflops. Or if you look at an RTX 4090 graphics card, 73 teraflops.
  307. Surma:So I feel like it gives you roughly like a, where is the 10x factor coming in kind of like
  308. Surma:roughly a comparison. But as I said, the actual specific architecture is not, you know, but
  309. Jake:Hmm.
  310. Surma:people always talk about the cores and you can just run, I don't know how many threads. And that's
  311. Surma:kind of what I wanted to tap into. And of course, when you have this specific architecture, your
  312. Surma:code that you run has to be in a way crafted to fit this architecture. Just like when you do
  313. Surma:multi-threaded programming, you know, you have to think about data races and how to avoid them
  314. Surma:using mutexes or something like that. So the same kind of goes when you're going to write your
  315. Jake:Hmm.
  316. Surma:shaders in Wixel or shaders in GLSO. So you have to think about those kinds of things. But I think
  317. Surma:it's time that I actually start about like at least like a little bit of code. Like how do you
  318. Surma:get started with WebGPU and you start. Yeah, maybe, maybe we need to cut this down. I don't
  319. 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.
  320. Surma:know. So basically what has happened since WebGPU there is navigator.gpu. That's a thing.
  321. Surma:It gives you a GPU. And what you can do from there is you can request an adapter. Now the adapter
  322. Jake:Nice, decent name.
  323. Surma:is basically you requesting access to a specific kind of GPU from the system, because some systems
  324. Surma:have multiple GPUs. Like you remember the Surface book had like one integrated with the keyboard,
  325. Surma:a high-performance one, an energy-saving one in the screen itself. And you can...
  326. 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.
  327. Surma:I don't know either.
  328. Surma:And you can request, you know, you can add a preference whether you want high performance
  329. Surma:or low power. I don't think there's much more choice right now. Some systems even offer software
  330. Surma:rendering, which is obviously, you know, slow, but for backwards could be nice. And from this
  331. Jake:Mm hmm.
  332. Surma:adapter, you can request a logical device. So the device is logical. It's not an actual device
  333. Surma:on the one hand, because if you have multiple tabs wanting access to the GPU, you don't want them to
  334. Surma:be able to read their data by accident. So this logical device is kind of like your handle, your
  335. Surma:personal handle to the GPU so that the browser underneath can do the multiplexing and make sure
  336. Surma:state is saved and restored when context switching happens, which is in fact the same thing the
  337. Jake:Of course.
  338. Surma:operating system does with multiple apps using the GPU. Everybody feels like they have exclusive
  339. Surma:access, but of course that's not actually the case. And this logical device, unless you specify
  340. Surma:otherwise, is not going to represent the real capabilities of the GPU, but actually going to
  341. Surma:represent a baseline device. So this is stuff like, you know, you can only upload textures up to 8K
  342. Surma:by 8K, or you only have 64K for uniform variables or at most 256 megs of memory.
  343. Jake:Mm hmm.
  344. Surma:Those kind of things are limited. Like WebGPU will shout at you if you do more. The point being
  345. Surma:that if you do, because it's so device specific, if your app or your stuff runs with this baseline
  346. Surma:device, you can be fairly confident that it will run on all devices in circulation right now. So
  347. Surma:that was how I think how this baseline device was chosen, or the specs were chosen by the WebGPU
  348. Jake:Nice.
  349. Surma:folks, so that if you just use that device and your thing runs, you can be fairly confident
  350. Surma:that at least in terms of data and workloads, it can run. Of course, you could still not hit the
  351. Surma:frame rate if the device is overloaded or just super slow, but I thought it was quite nice. It's
  352. Surma:giving people... Exactly. It's a bit like... Yeah. It's a bit like what we always said,
  353. Jake:Mm hmm.
  354. Surma:people should have a Nokia 2 phone to test their web app, because if it runs there,
  355. Surma:it's going to run everywhere. And of course, you can request increased limits, but then you're
  356. Jake:Mm hmm.
  357. Surma:opting in and you're knowing that you're leaving the well-tested battlegrounds. These are fairly
  358. Surma:request user media. It's literally like functions on the Navigator GPU that take some options and
  359. Surma:give you a promise and resolve to the thing if it has it and the user has given permission,
  360. Surma:although I'm not sure if currently GPU is gated behind the permission.
  361. Jake:Yeah.
  362. Surma:Yeah.
  363. Surma:Yeah. Which again, maybe the baseline device is a thing that you can get without permission,
  364. Surma:and when you specify you want to get the name of the GPU, maybe that's where permissions come in.
  365. Surma:Maybe they're keeping these options open for the future. I'm not sure, to be honest.
  366. Surma:So, once you have your logical device, your exclusive access to the GPU, or so they would
  367. Jake:Mm hmm.
  368. Surma:like you to think, you can now start defining your pipeline. So, it's kind of exactly what
  369. Surma:they sound like. You chain things together that consume and produce data, which are in this case
  370. Surma:more often than not shaders. When you do graphics programming, one of these modules could be a
  371. Surma:canvas, so you pipe your data from a shader into a canvas, but it could also just be shaders. Data
  372. Jake:Mm hmm.
  373. Surma:turning into data, turning into data, and you get the result back at the end. Shaders, by the way,
  374. 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.
  375. Surma:it's not
  376. Surma:not dissimilar. A lot more declarative in a way, because you have to declare how this data flows
  377. Surma:up front. Well, I guess in web audio, it's also kind of up front. Anyway, I always thought that
  378. Jake:Hmm.
  379. Surma:shaders are a great name, which confused me for a long time, because they don't shade. Well,
  380. Surma:they used to. It stems from the olden days, where GPUs were completely fixed. You basically were
  381. Jake:Hmm.
  382. Surma:told, upload the vertices of your mesh in this format into this memory bit here, and then the
  383. Surma:graphics card does its thing. And the only really customization you had is a tiny bit of, I guess,
  384. Surma:custom code, where you can affect how the lights in the scene affect how objects were, and say it
  385. Surma:with me, shaded. And so these pieces of code running on the GPU were called shaders for that
  386. Jake:Mm hmm.
  387. Surma:reason. They've since then gone well beyond just shading and lighting, but the name just stuck
  388. Surma:around. And so that's kind of what you do. You define your pipeline with a bunch of shading
  389. Surma:modules, and then the output can be a canvas or back to memory, and you can handle that from
  390. Surma:JavaScript. So I guess the last thing to kind of talk about there would be like, you know,
  391. Jake:Mm hmm.
  392. Surma:what does a piece of shading code look like? I said the code language is called
  393. Surma:Wixel. It's a bit like Rust. And it has all these GPUs, especially that you might already know if
  394. Surma:you've ever done any WebGL shading with GLSL. You have like the four-dimensional vectors and matrices.
  395. Surma:But compared to GLSL, you can quite, at least quite obviously, do stuff like pointers and
  396. Surma:proper structs, where you can define your own data structures that consist of two ints, a float, and
  397. Jake:Hmm.
  398. Surma:I don't know, an array of bits or something. Like all these things you can define and transfer back
  399. Surma:and forth between JavaScript land and WebGL lands. Because previously in WebGL, unless it
  400. Surma:fits into like, I guess, a matrix, you would have to start somehow encoding your custom data into a
  401. Surma:texture and then sampling that texture from GLSL to read the data back, which of course gets
  402. Jake:Mm hmm.
  403. Jake:Slow.
  404. Surma:really messy really quick. Yeah. So, you know, every shader has an entry function, and I'm going to
  405. Jake:Read back so slow. Yep.
  406. Surma:skip over a couple of details here, because it's just going to be too hard to actually explain well
  407. Surma:while we are talking about, without actually seeing the code. But basically, each invocation
  408. Surma:of your entry point function is going to get a number that tells you, you're the first invocation
  409. Surma:of this. You are the second invocation. And that's how you distribute work across the data you have
  410. Surma:uploaded. So, if I were to say, let's use a graphics example. If I were to upload my mesh,
  411. Jake:Mm hmm.
  412. Jake:Mm hmm.
  413. Surma:and every mesh has a vertex, and I wanted to do some work on each vertex, I could use this,
  414. Jake:Mm hmm.
  415. Jake:Mm hmm.
  416. Jake:Mm hmm.
  417. Surma:basically the thread ID, to say, okay, the first thread processes the first vertex. The second thread
  418. Surma:processes the second vertex. And so, you use that ID to access different parts of the data that you've
  419. Jake:Mm hmm.
  420. Jake:Mm hmm.
  421. Surma:uploaded. And that's how you scale out your work over a huge amount of data that you have given
  422. Surma:that piece. And it's usually, you know, like read-only data. So, there's not a risk of any
  423. Surma:synchronization problems. And the same, probably, with the output that you specify. The first thread
  424. Surma:puts their output here. The second thread puts their output here. So, that way, you don't need
  425. Jake:Mm hmm.
  426. Surma:to do any mutexing or locking and can avoid data races. But that is something that is on you to
  427. Surma:design. And so, that's definitely something where you need to craft the problem that you're trying
  428. Surma:to solve in a way that it fits the GPU architecture. And then, once, you know, that is all done, you can
  429. Surma:eventually read the data back. But this is actually something that I say, kind of like,
  430. Jake:Mm hmm.
  431. Surma:you know, you just read the data back. It's actually not that simple. The problem being
  432. Surma:that you have to find your pipeline. You can, you know, say, hey, GPU, execute this pipeline with
  433. Surma:this data. Which, by the way, is one of the performance benefits WebGPU brings. That you
  434. Surma:define this pipeline ahead of time. And WebGPU can validate it, that it's valid. In OpenGL times,
  435. Surma:this validation had to happen every time you were spawning a new piece of work or adding a new buffer
  436. Jake:Mm hmm.
  437. Surma:with WebGPU. This can all be done at declaration time. And then, it allows it to skip this
  438. Surma:validation work later on in the process. But as we know, and whoever has built, if you've ever
  439. Surma:built your own computer, like, GPUs are cards. And they're often separate. Not like in the MacBooks
  440. Surma:nowadays, where it's all on one chip. But they can also be, as they're called, discrete. A separate
  441. Surma:device. Basically, a co-processor in your computer. And because GPUs work so differently
  442. Surma:and have their own memory, it can't just be accessed by both CPU and GPU at all times.
  443. Jake:Mm hmm.
  444. Surma:So, to get data from your, you know, from JavaScript, effectively, or from your CPU memory
  445. Surma:into the GPU memory, you often have to do what is called a staging buffer. But it is a small
  446. Surma:piece of memory that can be accessed by both, but it can't be accessed fast, necessarily.
  447. Jake:Mm hmm.
  448. Surma:But you put all your data in there from the CPU, tell the GPU, hey, pick up your data and put it
  449. Surma:in your internal memory, and then it copies it over to its own internal memory, which is then
  450. Surma:fast and closely co-located. But this is kind of like a setup step you have to do for both
  451. Surma:getting data to the GPU, but also you have to do that for getting data back from the GPU.
  452. Surma:And these are all...
  453. Jake:Mm hmm.
  454. Surma:Yeah.
  455. Jake:Mm hmm.
  456. Jake:Mm hmm.
  457. Jake:Mm hmm.
  458. Jake:Mm hmm.
  459. Jake:Mm hmm.
  460. Jake:Mm hmm.
  461. Jake:Mm hmm.
  462. Jake:Mm hmm.
  463. Surma:Oh, yeah, I could see that.
  464. 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.
  465. Jake:And it was just that.
  466. 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...
  467. Surma:It is, yeah, for sure. And I think that's the kind of thing where, by nature, this API has to be async.
  468. Jake:And yeah, 60 frames a second came back. So I guess it's a similar sort of thing.
  469. Surma:Because, you know, the GPU then goes off and does its work. And technically, you know, the CPU isn't
  470. Surma:busy. You can do other stuff. The JavaScript, like, the API actually gives you a promise after you
  471. Surma:kick off some work and say, like, execute my pipeline with this data. And you can just do
  472. Surma:something else in the meantime. And you get a promise resolved once the pipeline is done.
  473. Jake:...
  474. Surma:And what it means is, you know, up to you and how you define that pipeline. It usually means the
  475. Surma:output buffer has been filled with the results of whatever you've been doing or, you know, the
  476. Surma:canvas has been drawn upon or something. But that's kind of how that will work. And so, in the
  477. Surma:blog post, because I wasn't really interested in doing graphics rendering, I actually wanted to
  478. Surma:learn more about, like, this capability of spawning, I don't know, 60,000 threads to do
  479. Jake:Hm.
  480. Surma:something. I built a physics simulation. And, of course, I visualized it with a canvas. But I made
  481. Surma:a point to use Canvas 2D. So, all that I'm doing on the GPU is, like, I upload the coordinates
  482. Jake:Oh!
  483. Surma:and different, yeah, the position and the radii of different points to the GPU. And they all have a
  484. Surma:velocity. And then the GPU does the calculation for each frame. Like, how much have they moved?
  485. Surma:Have any balls collided? And then how would they change direction and velocity? And the result is
  486. Jake:Hm.
  487. Surma:the new position, the new buffer, basically, of the new positions, new velocities, and the radii,
  488. Surma:obviously, the same. And so, the GPU does this every frame. And then I use Canvas 2D to draw
  489. Surma:all the individual balls. And that was kind of cool because I basically spawned a thread for each
  490. Surma:ball. And kind of having that power suddenly at my fingertips was cool. And, like, actually, Canvas
  491. Surma:2D became my bottleneck. So, once I disabled just, like, the visualization, I could easily simulate
  492. Jake:...
  493. Surma:14,000 balls on my MacBook M1 MacBook Air, which on the CPU wouldn't even get close. But,
  494. Jake:Heh heh heh.
  495. Jake:...
  496. Jake:No.
  497. Surma:yeah. And I think what you were saying, I'm much more into it as well, not in the whole
  498. Jake:...
  499. Surma:3D stuff, but actually using it for 2D stuff. And, you know, you can do it straight to Canvas and do
  500. Surma:texture sampling. But also, I like this approach where you could potentially, you could actually
  501. Jake:...
  502. Surma:use WebGPU to fill a buffer with RGBA data and just use it as, you know, an image data object.
  503. Jake:...
  504. Surma:So, rather than plugging the Canvas directly, you could just generate an RGBA buffer, which probably
  505. Surma:is slower than rendering straight to a Canvas. But it feels more obvious to me what's happening.
  506. Surma:It's all just, you know, computing happening in the end.
  507. 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.
  508. Jake:You know, I know how to write that in Canvas 2D, but it's slow.
  509. 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.
  510. Surma:Yeah.
  511. Jake:So I'm really excited to go and try this with WebGPU.
  512. Surma:So, yeah. It's definitely, people say that, you know, the modern graphics API are more boilerplate
  513. Jake:...
  514. Surma:than OpenGL. And I can see why they say that. But then again, any OpenGL tutorial where you draw the
  515. Surma:triangle, I don't think anybody can really say that it isn't boilerplate. And I find that,
  516. Jake:Hm.
  517. Jake:...
  518. Surma:at least with WebGPU, it doesn't feel like it's more boilerplate. There's still some setup to
  519. Surma:be done, but at least I get it, you know, like I understand what I am setting up and feel like I
  520. Jake:...
  521. Surma:have an intuition of where I can go in and change things or augment things. So, in that sense, I
  522. Jake:...
  523. Surma:do like this API a lot. Yeah. One thing I wanted to quickly bring up that we, you know, because I
  524. Surma:was just looking at the new Apple M3s and stuff, how these new GPUs are all, these new chips have
  525. Surma:CPU and GPU on the same chip with unified memory. They even now have, you know, the TPUs,
  526. Surma:or the NPUs, the neural processing units, which is kind of actually the same thing as a GPU,
  527. Jake:Hm.
  528. Jake:...
  529. Surma:obviously not quite, otherwise they wouldn't label differently. But these are, like GPUs,
  530. Surma:many, many cores with limited instruction set. And the GPUs and NPUs, from what I understand,
  531. Jake:...
  532. Surma:are mostly different in that they have less precision. So, the NPUs are stuff, a core set
  533. Jake:...
  534. Surma:are optimized to work on 16-bit or even 8-bit floats and integers, because for the neural nets,
  535. Surma:you often don't need the high precision. And so, that's just as a little pointer to what is going
  536. Jake:Okay.
  537. Jake:...
  538. Surma:on different there. But yeah. So, I realized that I didn't really talk about much code apart from
  539. Surma:how you get your logical device, but it's just not the kind of API, which literally talking
  540. Jake:...
  541. Surma:through makes a lot of sense, I think. But I hope that if people are interested by having this power
  542. Jake:...
  543. Surma:of just spawning a couple of hundreds of thousands of threads to do work, then that the blog post,
  544. Surma:and actually even the spec is quite good. And I think MDN now has a section as well
  545. Surma:on how to get started with WebGPU.
  546. 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...
  547. Surma:It's a win.
  548. Jake:Yeah, is a win. Absolutely.
  549. 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.
  550. Surma:Yeah. And they have not, and I want to express how thankful I am, not demanded anything in return,
  551. Jake:...
  552. Surma:really. They said, you should do the thing. And that's all they said.
  553. Jake:Yeah, I suppose it's very similar to the relationship we had with Google previously.
  554. Jake:So, yeah, we are very thankful for the sponsorship, but also thankful that they're not asking us to talk about Shopify stuff.
  555. Surma:I mean, we will, but not in a forced endorsed way. We are not trying to get people to sign up for a
  556. Jake:Although I imagine we'll end up talking about stuff that we are working on internally because...
  557. Jake:...
  558. Surma:VPN service. I am on the literal edge of my seat, Jake.
  559. Jake:Exactly. And to prove that our content isn't changing much, I have a conundrum that I would like to put to you.
  560. Jake:And I want to know where I went wrong and what you would have done differently.
  561. Jake:...
  562. Jake:Excellent. So, well, strap in so you don't fall off the edge of your seat.
  563. Jake:Anyway, I was in Manchester after a stag do or a bachelor party, as they call it in other parts of the world.
  564. Jake:Everyone else had left because it was the, you know, yeah, the whole of Manchester.
  565. Surma:Literally everyone, you were alone.
  566. Jake:It was like 28 days later, but in Manchester.
  567. Jake:So everyone else had gone and my train was a little bit later on, so I didn't have much to do.
  568. Jake:But I realized I needed a poo.
  569. Jake:And I've already checked out the hotel, like, you know, so there's my first mistake.
  570. Surma:Classic.
  571. Surma:Yep.
  572. Jake:Tick. Okay.
  573. Surma:Yeah.
  574. Jake:So I'm like, hmm, yeah, it's not gonna... yeah, I need to do something about this.
  575. Jake:And so I saw there's a pub that was open.
  576. Jake:It's like 11 in the morning. So there's a pub that's open. That's good.
  577. Jake:I'll go in there.
  578. 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?
  579. Jake:You know, that's not... that's rude.
  580. Surma:Really, I just, I feel like I'm still not sure how it works because I feel like
  581. Surma:if you take your jacket off and you walk with confidence, you're fine.
  582. Jake:Hmm.
  583. Jake:Okay. So your first... so I've already not followed your first piece of advice.
  584. Jake:I went to the bar and bought a drink.
  585. Jake:Yeah. And then I went and sat down.
  586. Surma:Good citizen.
  587. Jake:And then I realized, right, I need a poo and I've got a drink.
  588. Surma:I came here for a purpose.
  589. Jake:Yeah. What do I do?
  590. Jake:So what would you have done at that point?
  591. Jake:Like, I've put you in the situation of the mistakes I have made so far.
  592. Jake:What's your solution?
  593. Surma:I am struggling, Jake, to see the conundrum. You're in a pub. You have bought a drink.
  594. Jake:Yeah.
  595. Surma:They probably have a bathroom.
  596. Jake:Yeah.
  597. Jake:Right. What am I doing with the pint?
  598. Surma:You leave it on the table as a sign of somebody sitting here and I will be back.
  599. Surma:You could even leave your jacket.
  600. Jake:Okay. I didn't do any of that. I didn't have a jacket.
  601. Jake:It was in the summer. It was warm. Very warm.
  602. Surma:Ah, then just take your trousers off.
  603. Jake:I draped my trousers over the back of it.
  604. Surma:Might as well prepare.
  605. Jake:Yes, I suppose. No. So I decided to take my pint with me, didn't I?
  606. Surma:The German in me wants to put a towel down, but I'm guessing you didn't have a towel either.
  607. Jake:I did not have a towel.
  608. Jake:Yeah. So I decided to take my pint with me.
  609. Jake:And I sort of...
  610. Jake:I sort of felt like I could get to the bathroom with my pint, but without also being seen.
  611. Surma:I prefer my beer with sharticles.
  612. Jake:I wasn't going to... anyway.
  613. Jake:I walked through the corridor towards the toilet.
  614. Jake:And then that's when I learned that this particular pub has a separate bar
  615. Jake:that I opened the door into before the toilet.
  616. Surma:In the bathroom?
  617. Jake:Before the bathroom, you would sort of go through this door.
  618. Jake:There's this other bar and the toilets are just on your left.
  619. Surma:Oh, okay.
  620. Surma:Because I think there's a market niche, man.
  621. Jake:And there is four staff with nothing to do other than turn around and look at me
  622. Jake:with my pint and as I walk into the toilet with it.
  623. Surma:And judge you.
  624. Jake:And let me tell you, like I said, this is the depths of summer.
  625. Jake:It was boiling in that toilet.
  626. Jake:So I emerged afterwards.
  627. Surma:I mean, I, you know what? I think you get points for buying a drink.
  628. Jake:Same set of staff now.
  629. Jake:I mean, I'm sure they've been talking amongst themselves about what was going on.
  630. Jake:And I walked back past them still with my pint.
  631. Jake:And I did drink some of it because it felt like the thing I should do.
  632. Jake:And just sweating. Profusely sweating.
  633. Jake:How do you feel about my... score out of ten for my solution.
  634. Jake:Thank you.
  635. Surma:I don't think you have to.
  636. Surma:And you get points for giving those staff people something to talk about at 11 in the morning.
  637. Jake:Excellent. Yes, I'm sure there's a group of people in Manchester
  638. Jake:who are still talking about the man who likes to drink his pint
  639. Jake:from the safety of the toilet.
  640. Jake:From the safety of the toilet.
  641. Surma:He went in with a beer and he came out with a beer sweating.
  642. Surma:Draw the rest of the owl.
  643. Jake:Okay, let's...
  644. Jake:Thank you.
  645. Jake:Alright, okay.
  646. Jake:Let's talk about the web.
  647. Surma:Let's talk about the web.
  648. Surma:Well, what you already said.
  649. Surma:You want to talk about...
  650. Surma:It had the word ideology in it, which I think this is gonna go down.
  651. Surma:Is it the Tories?
  652. Jake:No, no, no, but I do feel like browsers are like political parties.
  653. Jake:And maybe I'm just thinking that because there's a lot of politics going on right now.
  654. Surma:No, I have no choice, mate.
  655. Jake:And it is maybe a bit of a clumsy metaphor, but hear me out.
  656. Jake:Okay.
  657. Jake:Users are the voters, right?
  658. Jake:And you're sort of, by using a browser, you're sort of voting for it to a certain degree.
  659. Jake:And just like the...
  660. Surma:Do you think people think about it that way though?
  661. Jake:I do think...
  662. Surma:Web developers do, but people, not web developers.
  663. Jake:I...
  664. Jake:Oh, no, no, absolutely not.
  665. Jake:Well, I think there are definitely people who will use Firefox due to their ideology.
  666. Surma:Yeah.
  667. Jake:And so they are using it in a voting way.
  668. Jake:But as you say, I think normal people don't.
  669. Jake:And I think that's interesting.
  670. Jake:Because you can also question the fairness of the votes.
  671. Jake:You know, are there people who...
  672. Jake:So, Microsoft Edge, when you go and try and download Chrome in Microsoft Edge,
  673. Jake:it displays something which really looks like they've injected content into the Chrome download page.
  674. Jake:They literally haven't.
  675. Jake:But it looks like they have.
  676. Jake:And it's kind of telling you, are you sure?
  677. Jake:Are you making a mistake?
  678. Surma:Yeah.
  679. Jake:So you could say, is that deceptive?
  680. Jake:You have Chrome...
  681. Jake:Like, if you go to a Google site and you're not using Chrome, it tells you.
  682. Jake:It's like, what are you doing, mate?
  683. Jake:You should be using Chrome.
  684. Jake:It's better.
  685. Jake:And so you could say, is that unfair campaigning?
  686. Jake:And maybe that's when the votes of regular people are being taken in an unfair way.
  687. Surma:All right.
  688. Jake:Apple have made iOS a dictatorial state.
  689. Surma:People can quote Jake now, Apple is North Korea.
  690. Jake:Democracy has been outlawed on iOS.
  691. Jake:You can only vote for Safari if you download...
  692. Jake:You can download Chrome, but it's just a skin over Safari.
  693. Jake:So yeah, democracy is dead there in this model.
  694. Surma:I mean, to be clear, right?
  695. Surma:Like Chrome on iOS can still sync your tabs, give you your bookmarks.
  696. Jake:Yes.
  697. Surma:It's the engine that is not Chrome's.
  698. Jake:Exactly.
  699. Jake:Exactly.
  700. Jake:So it is...
  701. Jake:Yeah, it isn't.
  702. Jake:You are taking certain elements of googly things when you use Chrome on Safari,
  703. Surma:Not the stuff that we care about.
  704. Jake:but not Chromium, not the engine, not Blink.
  705. Jake:Exactly.
  706. Jake:But there are these smaller, powerful groups that browsers need to keep on side,
  707. Jake:like their parent companies, Apple, Google, or powerful entities like Facebook.
  708. Jake:In the same way political parties keep certain companies or the press on their side.
  709. Surma:Or, you know, the law.
  710. Jake:Well, you see, laws.
  711. Jake:I think laws are more like the W3C,
  712. Jake:and that's where the parties have to work together to come to a consensus to write laws,
  713. Surma:Let's do it.
  714. Jake:to adapt laws, that kind of thing.
  715. Jake:And like political parties, I think the browsers have differing ideologies,
  716. Jake:and that those ideologies shift over time.
  717. Jake:And that's what I want to talk about.
  718. Jake:I want to look at the ideologies of browsers from five, ten years ago,
  719. Jake:and then look at how they're changing and where they might head in the future.
  720. Jake:So let's talk about Chrome of Christmas past, or whatever.
  721. Surma:Yeah.
  722. Jake:Chrome dominant even then on platforms where voting is allowed,
  723. Jake:where users can choose which browser to use.
  724. Jake:But Chrome saw native apps as a threat.
  725. Jake:And they saw a trend of people using the web less and native apps more.
  726. Surma:Hmm.
  727. Jake:So I think the Chrome ideology is close that gap to native by making the web more powerful.
  728. Jake:And that sort of resulted in the Extensible Web Manifesto.
  729. Surma:Oh, I haven't actually, like, read it in years.
  730. Jake:Tell us about the Extensible Web Manifesto.
  731. Surma:I think it's still online.
  732. Surma:Is it like extensiblewebmanifesto.org or something?
  733. Jake:Something like that. We can link to it.
  734. Surma:It still exists.
  735. Surma:I think I would summarize it as, and you can tell me whether I'm way off.
  736. Surma:Like, for the web platform, what the standards bodies should focus on,
  737. Surma:what should be added to the platform going forward are low-level primitives
  738. Surma:that unlock new capabilities that were impossible to do before.
  739. Jake:Yeah.
  740. Surma:Let the ecosystem build stuff on top that combines those low-level primitives
  741. Surma:into high-level features by combining them together.
  742. Surma:And only if, like, these high-level features
  743. Jake:Yeah.
  744. Surma:prove over an extended period of time to be popular and useful and well done.
  745. Surma:Only then should they get back into the platform,
  746. Surma:provided there's enough benefit.
  747. Surma:Let it be that, you know, there's less code that needs to be loaded
  748. Surma:or maybe a native implementation directly in the browser could be faster.
  749. Surma:But the focus should be unlock use cases
  750. Surma:that previously were impossible or extremely hard.
  751. Surma:Zed, would you agree?
  752. Jake:Yeah.
  753. Jake:Yeah, absolutely.
  754. Jake:So there is a CSS property called WebKitBoxReflect,
  755. Jake:which will give your element a reflection at the bottom.
  756. Jake:In a very Apple way, because it was Apple that added this to the platform.
  757. Surma:But only at the bottom.
  758. Surma:You can't reflect on the side or top.
  759. Jake:I don't think... I mean, maybe there's an option. I don't know or care.
  760. Jake:But the...
  761. Surma:There's probably, like, weird transform hacks you could do.
  762. Jake:Oh, absolutely.
  763. Jake:But the idea was like, we shouldn't be doing that.
  764. Surma:Yeah.
  765. Jake:We should have some kind of painting API where you can do that yourself.
  766. Jake:Like, you can define that and lots of other stuff.
  767. Jake:Like, give the developers freedom to do a lot more than just that one use case.
  768. Jake:The downside is, you know, Chrome never really did the high level.
  769. Jake:And so we got Service Worker. Good.
  770. Jake:But we never... Well, we didn't get static routes for a very, very long time,
  771. Jake:even though it was pretty much agreed at the start that they were needed for performance.
  772. Surma:Yeah.
  773. Jake:And then we saw a lot of sites use Service Worker and then go, well, this is slow.
  774. Jake:The higher level work to make it faster via declarative routes was not done.
  775. Jake:It is now finally being done, but we're talking about five, ten years ago.
  776. Jake:Things like page transitions, which again, we're getting now.
  777. Jake:But both of us were pushing for that five, ten years ago.
  778. Jake:Like, this is what developers want.
  779. Surma:Yeah.
  780. Jake:But it was like, no, that's too high level.
  781. Jake:We will figure out some way of doing something similar or whatever.
  782. Surma:And to be fair, I think that was one of those situations
  783. Surma:where the extensible web manifesto did us an injustice.
  784. Jake:Yeah.
  785. Surma:Because I do remember at least some people were arguing it's already possible.
  786. Surma:Like, you can build a page transition because people have.
  787. Jake:Right.
  788. Surma:But my god, is it hard and it's even harder to get it right.
  789. Surma:Once you want to think about transitioning from one page to another
  790. Surma:and they're both on different scroll positions, it just gets bonkers.
  791. Surma:And you have to go, like, you know, into what they used to call an HTML5 routine
  792. Surma:with, like, push state and all that jazz.
  793. Surma:And it's so, so hard to get it right across different devices and everything.
  794. Surma:And the browser has all this data, like, all the layers and the positioning
  795. Jake:Exactly. Exactly.
  796. Surma:and the scroll position already tracked.
  797. Surma:It's like, why am I ripping all that out and reinventing it
  798. Surma:when you could just give it to me?
  799. Jake:And even some of the low level parts feel like they didn't do the job.
  800. Surma:Yeah.
  801. Jake:Like, you still can't do WebKit Box Reflect with the CSS Paint API.
  802. Jake:Because you can't paint outside the elements and you can't take parts of the elements
  803. Jake:and copy it in order to do the reflection.
  804. Jake:So it's sort of, I don't know.
  805. Jake:I think it was a really good idea.
  806. Jake:But there's a lot of places where it fell short.
  807. Jake:Some places where it was great.
  808. Jake:Like, I'm glad we got the Intersection Observer API before the lazy attribute on images.
  809. Surma:Yeah.
  810. Jake:I'm glad you could use them in multiple ways.
  811. Jake:But yeah, it feels like it didn't really work out.
  812. Jake:The other part of closing the gap to native is access to device features.
  813. Jake:Device features, Bluetooth MIDI, USB serial camera, push messages.
  814. Jake:But I think Chrome was over-influenced by large partners.
  815. Surma:I was just gonna say, because I feel like some of these things were
  816. Surma:not gonna say rushed, but at least were launched.
  817. Surma:And I did feel for some of them, like, are developers asking?
  818. Surma:Or, you know, are big businesses asking?
  819. Surma:I guess I have to, you know, my personal angle is always a bit more
  820. Surma:on the one person in the developer than, I don't know,
  821. Jake:Yeah, so this is one of my big frustrations working at Chrome.
  822. Surma:Sony's trying to launch something on their website.
  823. Surma:You know, maybe, you know, businesses work differently.
  824. Surma:And obviously, in terms of revenue, get more focus.
  825. Surma:But I was just like, the thing that I'm building,
  826. Surma:do I want to be able to receive SMS verification messages?
  827. Surma:You know, like...
  828. Jake:Is that I always felt like project managers were very powerful.
  829. Jake:If they came into a room and said, look, Facebook has asked for this.
  830. Jake:And they'll be like, yeah, okay.
  831. Jake:We'll ship that.
  832. Jake:No questions asked.
  833. Surma:Yeah.
  834. Jake:Let's go.
  835. Jake:And I didn't feel very powerful walking to a room saying, look, developers keep telling me they want page transitions.
  836. Surma:Oh, spicy.
  837. Jake:And, you know, that wasn't listened to.
  838. Jake:So, yeah, I think there was an over-influence by large partners.
  839. Surma:Yeah.
  840. Jake:Including internal ones like AMP where, well, you know, Chrome and Google just hemorrhaged trust and, yeah, and goodwill with stuff like that.
  841. Surma:Yeah.
  842. Surma:Yeah.
  843. Surma:Yeah.
  844. Surma:Yeah.
  845. Jake:So whatever.
  846. Jake:In terms of web standards, I think Chrome was getting better.
  847. Jake:Like they saw vendor prefixes were a bad idea.
  848. 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.
  849. Jake:And kind of just sort of shipped it anyway.
  850. Jake:But there were specs for these features.
  851. Jake:Whether those specs were good or not, I don't know.
  852. Jake:But there were specs for these features.
  853. Surma:Yeah.
  854. Jake:All right.
  855. Jake:Firefox.
  856. Jake:Now, when I'm talking about Firefox and Safari, like I have internal knowledge from Chrome.
  857. Surma:Yeah.
  858. Surma:Yeah.
  859. Jake:I don't with Firefox and Safari.
  860. Jake:So, you know, it's more based on experience and to some degree rumor.
  861. Surma:Yeah.
  862. Surma:And especially with Safari, like, it's...
  863. Surma:You know, with the Firefox people,
  864. Surma:when I was attending the CSS working group at the time,
  865. Surma:they are quite happy to chat
  866. Surma:and even share knowledge
  867. Surma:and what they're planning and working on and how it works.
  868. Surma:Obviously less on the political side,
  869. Surma:but just, like, how it works from...
  870. Surma:The Safari folks are just not allowed
  871. Surma:to talk about that kind of stuff.
  872. Jake:Exactly.
  873. Surma:to talk about that kind of stuff.
  874. Jake:But with Firefox, like I feel in political terms, not a lot of votes, not a lot of power.
  875. Surma:to talk about that kind of stuff.
  876. Surma:to talk about that kind of stuff.
  877. Surma:Mm.
  878. Jake:They always felt like the minor part of a coalition.
  879. Surma:Mm.
  880. Jake:And back then they were a huge Chrome ally.
  881. Surma:Mm.
  882. Surma:Mm.
  883. Jake:They agreed with the extensible web.
  884. Surma:Mm.
  885. Jake:They agreed about device features.
  886. Surma:Mm.
  887. Jake:And this was driven by Firefox OS.
  888. Surma:Mm.
  889. Jake:Because they had a big stake in the mobile space.
  890. Surma:Mm.
  891. Surma:Mm.
  892. Jake:A whole operating system based on the web.
  893. Surma:Mm.
  894. Surma:They wanted the web to become capable
  895. Surma:as, like, all the apps on your phone
  896. Surma:should just be written as web apps.
  897. Jake:Exactly.
  898. Jake:Because they didn't want to write a special Firefox API to give you access to the file system on the device.
  899. Surma:And so they needed those capabilities.
  900. Jake:They wanted to use a web standard.
  901. Jake:And that fit with Chrome's position.
  902. Jake:So, they worked really well together.
  903. Jake:But what I will say about Firefox is they were so strong on web standards.
  904. 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.
  905. Surma:Yeah.
  906. Jake:Unfortunately, a lot of people would assume that Firefox was wrong.
  907. Surma:Yeah.
  908. Jake:Because it's a smaller browser.
  909. Jake:But, yeah, that wasn't often the case.
  910. Jake:Safari, back in the day, I'm going to say the word stagnant.
  911. Jake:We had things like index DB bugs that were there for five plus years.
  912. Jake:We had the 300 millisecond tap delay that was there for years.
  913. Surma:Yeah.
  914. Jake:Hacky internal scrolling on overflow scroll elements.
  915. Jake:And maybe this was them suffering after the engines were forked, after Chrome forked WebKit to work on their own thing.
  916. Surma:You say they were suffering,
  917. Surma:but maybe it was just, you know,
  918. Surma:I guess they didn't get
  919. Surma:the free work from Chrome, almost.
  920. Surma:At least they couldn't pull it back at some point
  921. Surma:as... I guess fresh
  922. Surma:after the fork, they probably could for a while
  923. Surma:pull things back in because Chrome
  924. Surma:or Blink remained open source, right?
  925. Jake:Oh, exactly.
  926. Surma:But I guess over time,
  927. Surma:you can't just apply the same patch
  928. Jake:Yeah, and my sympathy is sort of limited because this is one of the richest companies in the world, right?
  929. Surma:to the WebKit base anymore.
  930. Jake:Like, you know, they should be able to catch up pretty quickly on this.
  931. Jake:But I think that might explain some of it.
  932. Jake:Yeah, they weren't keen on the extensible web, it seemed.
  933. 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?
  934. Surma:Yeah.
  935. Jake:And my position was always, like, well, as long as they're only making their thing bad, it should be fine.
  936. Surma:Yeah.
  937. Jake:But it was kind of like, no, it was a feeling of almost a distrust of developers.
  938. Surma:Yeah.
  939. Surma:That's something I had as well
  940. Surma:at the time when I was on the CSS working group,
  941. Surma:mostly trying to look
  942. Surma:after Houdini, where, you know,
  943. Surma:the paint worklet and the animation worklet
  944. Surma:and the layout worklet, all these, like,
  945. Surma:kind of cool and exciting things at the time.
  946. Surma:And I do remember
  947. Surma:there was always pushback from...
  948. Surma:Not pushback from Safari
  949. Surma:as in, we don't want this,
  950. Surma:but actually more like, we would much
  951. Jake:Yeah.
  952. Surma:prefer if this was declarative
  953. Surma:than, you know, like an imperative
  954. Surma:JavaScript API. And whenever
  955. Surma:we tried to dig into that, they were like,
  956. Surma:well, we would like to be able to
  957. Surma:pre-calculate this and
  958. Surma:know that only certain things
  959. Surma:are possible and that we don't have
  960. Surma:to accommodate for all weird
  961. Surma:developer eventualities because it could just
  962. Surma:give a really bad experience. And I was like,
  963. Surma:yes,
  964. Surma:I get that,
  965. Surma:but it's a bit like a parent
  966. Surma:who doesn't want their kid to run with scissors,
  967. Jake:Yeah.
  968. Surma:which, with a kid, you know, I get it.
  969. Surma:But with developers, I usually
  970. Surma:let them run with scissors because you can
  971. Surma:already do really
  972. Surma:bad stuff, even with just
  973. Surma:CSS, like, let alone with JavaScript.
  974. Jake:Yeah, and with JavaScript, how bad is it compared to while true?
  975. Surma:So...
  976. Surma:Yeah.
  977. 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.
  978. Jake:In terms of web standards, not good.
  979. Jake:Like, new iPhones would come out with features, and they were just thrown onto the platform without any standardization.
  980. Jake:Like, even as far back as touch events, you know, device pixel ratio, forced touch, you know, lots more vendor-prefixed CSS.
  981. Jake:And there was, like, an Apple Pay API, which I think was the worst.
  982. Surma:Hmm.
  983. Jake:Because, yeah, it wasn't even a specific – like, there was never an API anyone else was going to implement.
  984. Jake:It was just an Apple thing thrown straight on the platform without any standardization.
  985. Jake:But I think things started to change, like, pretty early on with Safari, and this is when the privacy thing really came in.
  986. Jake:And this was a company-level thing.
  987. 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.
  988. Surma:Hmm.
  989. Jake:But I think in terms of the web, it was a good shift.
  990. Jake:It was used as a reason to push back on device APIs for fingerprinting, particularly.
  991. Jake:And then there was, like, the third-party cookie blocking – well, third-party storage in general.
  992. Jake:But again, no standardization.
  993. Jake:You know, request storage access sort of appeared loosely described in the blog posts.
  994. 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.
  995. Jake:But, yeah, there you go.
  996. Surma:Yeah.
  997. Jake:So that was then.
  998. Jake:Where are we at now?
  999. Jake:And have things changed?
  1000. Jake:Firefox.
  1001. Jake:Firefox OS dead.
  1002. Jake:That's gone.
  1003. Jake:Bye-bye.
  1004. Surma:Yeah.
  1005. Surma:I was excited, though, at the time.
  1006. Jake:Same.
  1007. Surma:Like, it was... I liked
  1008. Surma:the vision.
  1009. Jake:Oh, absolutely.
  1010. Jake:I had a Firefox OS device.
  1011. Jake:Yeah, it showed promise.
  1012. Jake:But, yeah, they couldn't make it work.
  1013. Jake:And as such, they really sort of just abandoned mobile.
  1014. Jake:I mean, you still get Firefox for Android.
  1015. Surma:Yeah.
  1016. Jake:I use it occasionally.
  1017. Jake:But it's – yeah, I think it's kind of a project of passion.
  1018. Jake:I don't think it's really, like, their core belief.
  1019. 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.
  1020. Jake:That was something – you know, that was a strong bit of ideology for them as well.
  1021. Jake:But, I don't know.
  1022. Jake:Firefox is smaller still.
  1023. Surma:Yeah.
  1024. Jake:It hasn't – yeah, so.
  1025. Jake:But I will say, I mean, they do amazing work.
  1026. Jake:Working with them on web standard stuff was always amazing.
  1027. Jake:But a lot of their engineers have gone now to Chrome or Safari.
  1028. Surma:And not
  1029. Surma:necessarily by choice.
  1030. Jake:No, no, yeah, it was – you know, downsizing was some of it.
  1031. Jake:But in some cases, it was just the work they wanted to do or, you know.
  1032. Surma:True.
  1033. Jake:Safari.
  1034. Jake:Safari, I think, is ideologically – if I – I'll try and – no, I'm going to leave it at that.
  1035. Surma:True.
  1036. Jake:I'm not going to rerecord that.
  1037. Jake:Just leave it at that.
  1038. Jake:I think they're the least changed.
  1039. Jake:And I think that's because the privacy stuff was already happening – you know, the change was happening earlier.
  1040. Surma:At the same time,
  1041. Surma:they deserve a bit of credit for
  1042. Surma:giving Safari or WebKit
  1043. Surma:more love. They have... I'm not saying
  1044. Jake:Oh, yeah.
  1045. Surma:they have, you know, been...
  1046. Surma:They're now up to speed, necessarily,
  1047. Surma:or gone about it a great way, necessarily,
  1048. Surma:but they have definitely
  1049. Jake:Yeah.
  1050. Surma:fixed a lot of things,
  1051. Surma:added a lot of APIs that were missing,
  1052. Surma:and have become a much
  1053. Surma:more capable and
  1054. Surma:likable web engine
  1055. Jake:Yeah, a lot of those annoying bugs I mentioned have been fixed.
  1056. Surma:in my books.
  1057. Jake:The team grew.
  1058. Jake:They took on a lot of strong standards advocates from Firefox or independents.
  1059. Surma:True.
  1060. Jake:And they had an active dev rel for the first time, it seemed.
  1061. Jake:And, you know, by which I mean Jen Simmons, who I've clashed with on a number of things,
  1062. Surma:True.
  1063. Jake:but I cannot fault her community engagement and, you know, actually listening to developers.
  1064. Jake:And it's not just – it doesn't feel like fake listening.
  1065. Surma:Not true.
  1066. Jake:Like, it feels like the listening has happened and change has happened as a result.
  1067. Jake:Yeah, but I also feel it has been a shift towards Chrome's position.
  1068. Jake:Like, we – you know, we got push messages recently.
  1069. Jake:Background fetches behind the flag.
  1070. Surma:Yeah.
  1071. Jake:There's, you know, custom element, more custom element stuff, more engagement on the standards there.
  1072. Jake:The paint API is behind the flag.
  1073. Jake:But, you know, there's been development effort in these lower-level things.
  1074. Jake:But still a strong lean towards the high-level stuff.
  1075. Jake:Lots of – you look at their release notes, like the CSS stuff is often the biggest section in terms of features.
  1076. Jake:They're pursuing things like the model elements rather than WebXR.
  1077. Surma:Yeah.
  1078. Surma:But then again, I feel like,
  1079. Surma:in general, the
  1080. Surma:last couple of years,
  1081. Surma:CSS in general has gotten a lot of
  1082. Surma:focus, a lot of love, from
  1083. Surma:Chrome and Safari.
  1084. 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 –
  1085. Surma:You just almost
  1086. Surma:said close the loop, didn't you?
  1087. Jake:close the loop.
  1088. Jake:Yeah.
  1089. Jake:Sorry.
  1090. Jake:But what you say is right.
  1091. Jake:Like, we have seen, like, from Chrome, pretty big ideological changes.
  1092. Jake:Not as much as Firefox, but more than Safari.
  1093. Surma:Yeah.
  1094. Jake:And, yes, it is that shift away from the extensible web to heavy investment in CSS.
  1095. Jake:And that's reflected in DevRel as well.
  1096. Jake:Like, you've got Yuna, Adam, Bramus.
  1097. Jake:Like, they're heavily focused on CSS.
  1098. Jake:Whereas before them three, like, it was just, you know, people like me and you sort of making it up.
  1099. Surma:One of these things is not like
  1100. Surma:the other.
  1101. Jake:Exactly.
  1102. Jake:So, specialists in CSS, which we never were.
  1103. Surma:Yeah.
  1104. Jake:And, yeah, Chrome, you know, we got Scroll Snap.
  1105. Jake:We started to get a few transitions.
  1106. Jake:We got Scroll Timeline rather than Animation Worklet.
  1107. Jake:Like, you know, these are higher level visions that were, you know, not allowed a few years ago.
  1108. Surma:Yeah.
  1109. Jake:Static Roots and Service Workers, they're coming.
  1110. Jake:There is definitely some shift towards listening to developers more and DevRel through them.
  1111. Jake:That you get, like, the surveys being used to justify work.
  1112. Surma:Yeah.
  1113. Jake:I do still think there's too much project manager influence compared to DevRel.
  1114. Jake:But, you know, whatever.
  1115. Surma:Yeah.
  1116. Jake:I think things are getting better there.
  1117. Jake:And, again, web standards have got better.
  1118. Jake:Probably due to, you know, more of a focus on the kinds of things that Safari like.
  1119. Jake:So, there's less to clash on.
  1120. Jake:But there is also the interop efforts, which, you know, brought the browsers together on some features.
  1121. Jake:So, I think it's a good initiative.
  1122. Jake:So, that brings us to the future.
  1123. Surma:Yeah.
  1124. Jake:And kind of what would we like to see?
  1125. Surma:The web is dead. Move on.
  1126. Jake:Ah, well.
  1127. Jake:Well, Chrome.
  1128. Jake:What would I like to see from Chrome?
  1129. Jake:My experience working on Chrome was there was three kinds of Chrome employee.
  1130. Jake:There were web people who, like, acted like they worked for the web but were paid by Google.
  1131. Jake:Like, they were sponsored by Google to do it.
  1132. Jake:There were Google people who were, you know, signed up members of Google and were interested in doing whatever.
  1133. Surma:Right.
  1134. Jake:Made Google good.
  1135. Jake:And then the third kind was people who were just there to do a job.
  1136. Jake:And didn't really care either way.
  1137. Jake:Which is fine, right?
  1138. Jake:You know, that's a total fine.
  1139. Jake:That's a fine way to have a job.
  1140. Jake:But I just hope the web people stay strong.
  1141. Jake:You know, don't, you know, make sure the job being done is good.
  1142. Jake:Make sure it's good for the future of the web.
  1143. Jake:And especially when that clashes with what Google might want.
  1144. Jake:You know, stick to what is good for the web.
  1145. Surma:Yeah.
  1146. Jake:Listen to developers.
  1147. Jake:And via their dev rel.
  1148. Jake:Yeah, question whether these things are the features being asked for.
  1149. Jake:Is it just the thing that Airbnb wants or Facebook wants?
  1150. Jake:Or is it actually useful to the developer community at large?
  1151. 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.
  1152. Surma:Yeah.
  1153. 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.
  1154. Surma:Yeah.
  1155. Jake:Like, if I do a pinch zoom, you know, and the user lets go, is it going to move a bit?
  1156. Jake:And is it going to feel like iOS?
  1157. Jake:Is it going to feel like Android?
  1158. Jake:Or, you know.
  1159. Surma:And I think I agree with that.
  1160. Surma:One artifact that I liked in terms
  1161. Surma:of addressing
  1162. Surma:developer pain points, and I guess in a way
  1163. Surma:you could even say tech debt,
  1164. Surma:as much as that can be used in a
  1165. Jake:Thank you.
  1166. Surma:standard space.
  1167. Surma:Like, for example, the new navigation API.
  1168. Surma:I was like, yes.
  1169. Surma:Because this is, in that sense, not
  1170. Surma:really a new capability,
  1171. Surma:but my god does it make
  1172. Surma:my life easier having
  1173. Surma:this more holistic API
  1174. Surma:to actually handle navigation and
  1175. Surma:routing at the spot where it makes
  1176. Surma:sense and not like shorn on. And I still
  1177. Surma:think there is
  1178. Surma:a lot of stuff that could be
  1179. Surma:learned from how app development
  1180. Surma:on native platforms work
  1181. Jake:Okay.
  1182. Surma:in terms of, for example,
  1183. Surma:views. I still think
  1184. Surma:it doesn't
  1185. Surma:feel super intuitive thinking
  1186. Surma:in views
  1187. Surma:when you do web development where you have
  1188. Surma:something that fills the screen
  1189. Surma:and you want to put multiple scrolling
  1190. Surma:elements in there or a sidebar.
  1191. Surma:There's still a bit of
  1192. Jake:Yes, absolutely.
  1193. Surma:legacy from the document
  1194. Surma:web that kind of interferes. And I know
  1195. Surma:the web is different with backwards compatibility,
  1196. Surma:but I liked that with
  1197. Surma:the navigation API. You know what?
  1198. Surma:That is a pain point. We're going to sit down and design
  1199. Surma:something that actually slots into
  1200. Surma:the browser where this
  1201. Surma:should happen. I'm kind of hoping
  1202. Surma:that that is a trend that will
  1203. Surma:continue.
  1204. 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.
  1205. Surma:Yeah, exactly.
  1206. Jake:So, yeah, having some way to, you know, change what is considered the main scroller, I think would help a lot there.
  1207. Jake:But, yeah.
  1208. Surma:Yeah.
  1209. Jake:So, yeah, poke at that sort of stuff.
  1210. Jake:For Safari, I like keep doing the privacy thing.
  1211. Jake:It's important to have this, you know, at least this two-party system.
  1212. Jake:Keep listening to developers.
  1213. Jake:Keep that trend up and keep the trend of investment.
  1214. Surma:Yeah.
  1215. Jake:I hope Apple keeps up this trend of investing more in WebKit.
  1216. 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?
  1217. Surma:Yeah.
  1218. Jake:But, hey, look, if that's the thing that drives them, then fine.
  1219. Surma:The other thing I would love
  1220. Surma:to see from them, less
  1221. Surma:political, is
  1222. Surma:on the one hand that
  1223. Jake:Oh.
  1224. Surma:filing an issue on WebKit
  1225. Surma:would feel a bit less like shouting into the
  1226. Surma:void because they have a copy of their
  1227. Jake:Radar.
  1228. Surma:own internal issue tracker so that you don't actually
  1229. Surma:know whether the thing is
  1230. Surma:getting addressed or not.
  1231. Surma:And in general, just
  1232. Surma:have a higher
  1233. Surma:release cycle. Don't make
  1234. Jake:Oh, yes.
  1235. Jake:We did a whole episode on is Safari the new IE.
  1236. Surma:us wait.
  1237. Jake:And, you know, in some ways, yes, in some ways, no.
  1238. Jake:But one of the ways, yes, is the release cycle.
  1239. Jake:That is getting better and better.
  1240. Jake:So I would say, you know, keep that trend going.
  1241. Jake:Ideally catch up to Firefox and Chrome on that would be great.
  1242. Surma:Yeah.
  1243. Jake:But, yeah, trust developers as well.
  1244. Jake:Like, trust them with lower-level APIs as long as they're only breaking their own thing.
  1245. Surma:Yeah.
  1246. Jake:Yeah.
  1247. Jake:Do allow developers to be creative with this low-level stuff.
  1248. Jake:And consider more platform capabilities as well.
  1249. Jake:Can you do the Bluetooth thing in a privacy way?
  1250. Jake:Can you do the Web USB thing?
  1251. 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.
  1252. Surma:Yeah.
  1253. Surma:That's cool.
  1254. Jake:And, yeah.
  1255. Surma:I didn't know that. That's a really cool story.
  1256. Jake:Exactly.
  1257. Jake:So you didn't have the, you know, it was no long ‑‑ it meant it wasn't just a piece of tech trash.
  1258. Jake:It was usable now.
  1259. Surma:Yeah.
  1260. 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.
  1261. Jake:It was just done on the web.
  1262. 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.
  1263. Surma:True.
  1264. Jake:Yeah.
  1265. Jake:If you push people into a native app, they're losing the privacy game more.
  1266. Jake:And my advice to ‑‑ or what I want from Firefox is just stay alive.
  1267. Jake:Like, please.
  1268. Jake:You know?
  1269. Jake:And if you can't keep the engine running, if you can't keep Gecko up, then please be WebKit.
  1270. 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.
  1271. Surma:What I was just saying,
  1272. Surma:for a first episode, we're
  1273. Surma:coming back,
  1274. Jake:Well, this has been a long record.
  1275. Surma:burning through all of the material
  1276. Surma:so we can immediately not do a new
  1277. Surma:episode for two or three months.
  1278. Surma:Yeah.
  1279. 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.
  1280. Surma:Yeah.
  1281. 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.
  1282. Surma:Yeah.
  1283. Surma:Yeah, just cut my bit.
  1284. Jake:Absolutely not.
  1285. Jake:Absolutely not.
  1286. Jake:Well, should we ‑‑ should we stop?
  1287. Jake:I mean, the longer we're going on now, the more we have to cut.
  1288. Jake:So, yeah, I suppose we should go away.
  1289. Surma:Yeah.
  1290. Jake:So how are we going to do this?
  1291. Jake:We used to have a catchphrase.
  1292. Jake:We used to say, happy next time, which is ‑‑ is it?
  1293. Surma:Yeah, we need a new one because
  1294. Surma:the old one is copyrighted still, right?
  1295. Jake:Oh.
  1296. Surma:It's not our intellectual
  1297. Jake:Okay.
  1298. Surma:property, I suppose. We need to ask
  1299. Surma:Mariko to come up with a new phrase because
  1300. Jake:She did.
  1301. Surma:she came up with the old phrase, so now she's
  1302. Surma:on the hook for the new one.
  1303. Jake:So we could just do ‑‑ we could just do an Irish exit.
  1304. Jake:Okay.
  1305. Jake:Are you aware of the term to do an Irish exit?
  1306. Surma:I have been introduced to the
  1307. Surma:term by, ironically,
  1308. Surma:Paul Irish.
  1309. Jake:Me, too.
  1310. Jake:Yes, okay.
  1311. Jake:So for anyone who doesn't know, Irish exit is when you just disappear.
  1312. Surma:Yeah.
  1313. Jake:So, you know, at a party and you just kind of, like, sneak out.
  1314. Jake:I think it's a good ‑‑ you know, I've used it before.
  1315. Jake:It means you don't have that, oh, stay for another drink.
  1316. Jake:You just ‑‑ oh, exactly.
  1317. Surma:Or if you feel
  1318. Surma:obliged, just go to everyone and
  1319. Surma:give a hug, shake their hand,
  1320. Surma:I don't know, just say goodbye to
  1321. Surma:everyone individually so nobody feels neglected. This way,
  1322. Surma:everybody feels equally neglected.
  1323. Jake:Exactly.
  1324. Jake:And I ‑‑ same as you, like, Paul Irish does this.
  1325. Jake:And that's how, you know, Paul ‑‑ I think I was at a party or something,
  1326. Jake:and I was like, oh, has Paul gone?
  1327. Surma:Yeah.
  1328. Jake:Oh, yeah, he's done the Irish exit.
  1329. Jake:And I thought that they were naming it after Paul Irish.
  1330. Surma:I thought that as well.
  1331. Jake:Brilliant.
  1332. Jake:Because from then on, like, I heard the term again in other circles,
  1333. Jake:but it just coincidentally, it seemed to be from someone who has a,
  1334. Jake:you know, would know Paul Irish.
  1335. Surma:Like,
  1336. Surma:six degrees of bacon, but with
  1337. Jake:Yeah, exactly.
  1338. Surma:Paul Irish.
  1339. Jake:So they'd say, oh, he's doing an Irish exit, and I'd be like, oh, yeah,
  1340. Jake:Paul, yeah.
  1341. Jake:But then I heard it from someone else, like, outside of tech,
  1342. Surma:Yeah.
  1343. Jake:and they were like, oh, yeah, well, I might just do an Irish exit.
  1344. Jake:Oh, you know Paul Irish.
  1345. Jake:They're like, what are you on about?
  1346. Jake:I don't know.
  1347. Surma:Yeah.
  1348. Jake:I need to have this conversation, because that's when I started to realize,
  1349. Jake:you know, the whole thing is nothing to do with Paul Irish.
  1350. Jake:It's a big coincidence, and, yeah, I felt like a fool.
  1351. Jake:But, yeah, should we just do an Irish exit?
  1352. Surma:So, we'll be then,
  1353. Surma:we'll just stop.
  1354. Jake:Go for it.
  1355. Surma:Yeah.
  1356. Surma:I do like this API a lot.
  1357. Surma:Oh, one thing I wanted to,
  1358. Surma:oh,
  1359. Surma:I'm going to quickly go to the door, I guess.
  1360. Surma:I'll be right back.
  1361. Jake:Woof, woof, woof, woof, woof.
  1362. Surma:Did we get Watson on the recording?
  1363. Jake:Absolutely.
  1364. Surma:Nice.
  1365. Surma:Nice.
  1366. Surma:Nice.