Brian Kardell: Hi, I am Brian Kardell, I am a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also a developer advocate at Igalia.
Brian Kardell: And today we have two special guests. Do you want to introduce yourselves?
Jake Archibald: Go on, Surma, you go first.
Surma: I go first? Okay, hi.
Jake Archibald: Yeah.
Surma: I'm Surma. I'm an engineer at Shopify.
Jake Archibald: I'm Jake Archibald, also an engineer at Shopify, but folks might have known me and probably Surma as well for the time we did as developer advocates on Chrome. But that time has passed.
Brian Kardell: I think, I don't know that I have ever acknowledged this very publicly, but I almost certainly would not be a developer advocate if it were not for Jake.
Jake Archibald: Oh. Thank you.
Brian Kardell: So Jake actually.
Surma: Hey, didn't say it was a compliment.
Jake Archibald: [Laughing] Or commiserations
Brian Kardell: Even when I switched, on my first day, Jake had a one-on-one call with me to just help me out, was really super gracious about it. But yeah, anyway, even the very first time I spoke, I was super, super nervous and Jake was there, and he and Paul Irish totally got me through that.
Jake Archibald: And you were great as well.
Surma: That's some strong mentors to have.
Brian Kardell: One of the things that you both did there was HTTP 203, which is my favorite podcast. I loved about it a lot of the things that are hard to put into words, I know that I was listening to it before Surma was there, when it was Paul Lewis and.
Jake Archibald: Oh yeah, that guy.
Brian Kardell: I will admit, Surma, that I was a little bit like they switched Darrens on Bewitched or something. I was like, 'What are you doing?' But no, I came to really like having Surma on there. Now, you two are a little bit, I was trying to think before this about who I should choose out of all the, but it's a little bit like Matt Damon and Ben Affleck where you're in one hit and now you leave and go somewhere else and you're in another hit so you start a new podcast.
Jake Archibald: Yeah, that's it. And if Surma leaves Shopify, then I'll just follow him around. Picking where to work is, oh, it's too much effort so I'll just do what Surma does. I mean, he picks good places, so I'll just keep doing that.
Eric Meyer: Hey, if you've got a system that works.
Jake Archibald: Exactly.
Surma: I will say that the podcast is one of those things which I think Jake and I will be doing even if there was no one listening, because it's genuinely fun. It was one of the few things where there was almost no alternative motivation or incentive was needed for us to keep doing it, and that's really nice.
Jake Archibald: It's two white guys in the pub having a chat.
Surma: Yeah.
Jake Archibald: And do you know what? It's wasted that no one else is listening to this.
Brian Kardell: I said that actually on Twitter a few times that I used to save your podcast for Saturday when I could just go out on my deck and get a beer and listen to it because it felt like that. It felt like.
Surma: Man, you make our podcast sound really good.
Brian Kardell: It's pretty cool. There are very few podcasts where you get a lot of good technical stuff, but also just a lot of fun banter and stories about Jake's cats or looking desperately for a bathroom or something like that. Good stuff.
Surma: It's a staple, household staple.
Jake Archibald: A whole meme throughout the series. But yeah, well, we left Google, they wouldn't let us keep the name, which is whatever. So we basically started the same thing again, but called it Off The Main Thread.
Brian Kardell: I was hoping you would do 302 because it made sense, right?
Jake Archibald: Right.
Surma: We did discuss multiple status codes, but it turns out that Google has a lot of money, and a lot of really good lawyers, and it just wasn't worth the risk.
Jake Archibald: They're bigger than us.
Brian Kardell: You've done two episodes that I've heard now. Well, I guess there's three because there's a secret third episode that wasn't the launching one. Changing jobs, Deno, and optimizing animations. Yeah.
Surma: Yeah, that's the one.
Brian Kardell: So yeah, it's Off The Main Thread, also OTMT. I was wondering which one I should look for, but I guess Off The Main Thread is what you look for in the podcasting services.
Jake Archibald: Yeah, we maybe need to think about our SEO there. We hadn't even thought about that.
Brian Kardell: The first episode you did is two major parts, and the second part you did this thing that was browsers are like political parties. Users are like voters. You got into a talk about what are those ideologies? They have ideologies and then they change over time. The origin window shifts around. It was really, really good. And do you want somebody to try to briefly sum up the premise, the high points?
Jake Archibald: Yeah, I can take it. I mean it was a slightly wonky metaphor, but I don't know, it fits in some ways. The idea is that the browsers are political parties and users are voters, and the more users a browser has, the more power it can wield in other areas. You can equally question whether the way they get their votes is fair, or are they doing it the right way? I think the comparison I made is, well, everywhere you go on Google, if you're not using Chrome, it tells you to use Chrome. If you're using iOS, you are a Safari voter whether you like it or not. You appear on all of the stats as a Safari user because you have literally no other choice in terms of browser engine. So a little bit similar to political parties, you can question their ethics in terms of getting votes. But yeah, you have places like the W3C where the laws are passed and the parties have to work together, but also their ideologies are different and change over time. And that was the premise of the section of looking back at when Chrome was heavily pursuing low-level stuff, Safari less so. Firefox pursuing low-level stuff because of Firefox OS and over time resource Safari start to pick up more of the low-level stuff. Chrome start to pick up a lot more of the high-level CSS stuff, and Firefox becoming less of a Chrome ally, which it was in the past and more of a Safari ally due to the privacy focus and the focus away from Firefox OS. That's the very quick story, but I think the part of it that you're particularly interested in was the Extensible Web Manifesto, which is something a lot of browser engineers at the time agreed with, that there should be more of an effort to look at lower level parts like building blocks that we can give developers. So to admit that, hey, browser engineers are not web developers, so rather than try and create pre-baked solutions to do one specific thing, there should be tools which allow you to create things that the creator of the standard didn't possibly dream of. It's a whole creativity that is released out there rather than just having a CSS property to create a reflection. You'll have the tools to create your own reflection, but also other kinds of reflections and other kinds of graphics work, that kind of thing, and how we hear less and less about that these days, but also how it maybe wasn't quite capitalized on back in the day.
Brian Kardell: I like the thing about the votes, and all analogies are leaky abstractions.
Jake Archibald: Oh, absolutely.
Brian Kardell: So I don't want to go too deep into that I guess. But it's that and also, you can compare it to anything else where there's a few major players and you have here Firefox being more like the kingmaker than an actual, right? They're never going to be the king, but they're the ones that have the little bit extra room to throw around. And I think the point that you made is then they had a little bit more weight than now, but it's still really relevant. I also was thinking after this that I think Surma raised the question, it was like, do real people choose the browser? Are they really voting?
Jake Archibald: Well, absolutely, and I guess in some ways I would say in that way the metaphor holds in the same way a political party will say is you should not vote for them because they're evil and you should vote for us. We're going to make everything better. And largely, that isn't always true. In fact, sometimes the party that is more successful at persuasion is the one that is maybe playing a little bit loose with the truth. I don't know. In the same way you could say, are people really voting for the parties for the right reason? But yes, they'll see when they go on Google search, 'Hey, you should be using Chrome.' Or if they're in Edge and they go to download Chrome, there'll be a banner across the top saying, 'Hey, do you really want to do this?' So yeah, they're persuading you to become a voter. You might not really realize what you're letting yourself involve.
Surma: But it is an interesting thought that the WebKit engineers are going to claim WebKit has this many million users per day, for example. Because on iOS, even if you install Chrome, it's WebKit, while Chrome at the same time will claim to have this many million users per day. And for them, the same users probably count into their stats as well because it's a very technical, niche difference that to the outside is probably indistinguishable. And I'm not sure that just having a user base is enough to claim ownership of the web platform. But it's just interesting to think about that these stats that are probably going to be thrown around, and I don't know, maybe in advertising, it could convince a non-technical user to switch from one browser to the other, I don't know. But there's probably effects to being able to inflate your user base and use that publicly.
Jake Archibald: These stats can be twisted as well. So when of course Internet Explorer, I'm going to say 9 came out, they had a great SVG implementation, and so they would build a lot of demos around performance that involved a lot of SVG because the engines in the other browsers were less good at SVG. But what we saw is one particular benchmark, I think it was even the big one that they were pushing forward where Edge was so much better than the other browsers, what they'd done is they'd added in a blur 0.001 pixel filter and that threw every other browser onto this excruciatingly slow path but not them, it wasn't needed for the visual output, but why did it make the stats look good for IE? And political parties do this stuff as well.
Eric Meyer: And it's not the first time or the last time I think that a browser maker has creatively addressed benchmarks, or creatively created their own benchmarks in order to look better than everyone else.
Brian Kardell: There's actually a term for that.
Eric Meyer: And it is?
Brian Kardell: Benchmarketing.
Eric Meyer: There we go.
Jake Archibald: Oh, very good.
Surma: Brilliant.
Eric Meyer: But there's a question that I want to put forth. Brian and I certainly have opinions about this, but I'm interested in hearing yours. Why is it such a big deal for browsers to have the most users or whatever? What is it that they're particularly pursuing in trying to dominate a market or have the most users or whatever?
Jake Archibald: I mean, I think that's different for every browser. For Google, as far as I'm aware, Google has to give a lot of money to Apple for getting them to use Google search for Google Chrome browser users, particularly on macOS. They don't have to pay that if they're using it in Chrome, and it can be used obviously to get people more into the Google ecosystem. So I always stayed away from this side of Google and tried to convince myself that I was being paid by Google to work on the web. I almost pretended I wasn't a Google employee in some ways, I was just working for the web via Chrome. But yeah, so there's some of the details of that kind of funding I never felt particularly affected by, and I'm not 100% sure of them, but I'm pretty sure that's it. And so for Safari, I'm not sure what their interest is in a larger user base. For Firefox, again, it's revenue. The more users they've got, the more they can charge for using Google search and the company stays alive, right?
Surma: It could lead to an identity crisis for me when I was thinking about what am I even being paid for at Google, because the web is open, it's not a platform that's specifically owned by any individual company or any individual person. Chrome is free, and I was paid to make people build more websites basically? I mean, I don't know if that's an accurate job description, but it felt like it. And that seems like a very indirect way to benefit Google. I mean, I think everybody knows Google is an advertising company, and most of the revenue comes from ads on the web, but man, that sounds still a couple degrees of freedom away from make the web better and help people build more websites. So yeah, I think I was in a similar camp as Jake where I didn't ask a lot of questions because I got to help people build better stuff and push the web forward and I genuinely thoroughly enjoyed that.
Jake Archibald: Do you ever feel like it sounds like as an excuse? No, we just made the uniforms for the bad guys.
Surma: No.
Jake Archibald: I do want to stress that the other side of that is I never felt like I had to do something that was against what I wanted for the web as well. And I felt free to actively push back on things that I didn't like so much. I was never a big fan of AMP, and internally there were specs that were created. Certainly when I was part of the service worker working group, there were specs and features that I shut down for privacy reasons. So it would've been great for ads folks, which you could say would be maybe good for Google, but I felt empowered to say no.
Eric Meyer: So your answers on why do browser makers care so much about whether they're the biggest? I mean it really comes back to something that Brian and I have opinions on, which is the fact that the entire browser ecosystem is effectively run by Google ad revenue. Google wants more users so they can make more ad revenue. Mozilla wants more users so they can have more revenue from Google paying them to have Google as a default search so that Google can have more ad revenue, and probably Apple as well. Apple of course has more money than God, but at the same time a multi-billion dollar a year payment from Google, that's hard to say, 'Yeah, we don't care.'
Jake Archibald: And they have things pulling them the other way as well. And I think people overplay this a bit, but I'm sure it's true to some degree that Apple makes a lot of money from App Store revenue and a all-powerful web that means you don't need an App Store would at some point become a bit of a drag on that funding. I don't think as many decisions are made based on that as people make out, but I also don't think it's... I'm sure it registers to some degree.
Brian Kardell: Yeah, I think that's the challenge in a lot of these things is that there's a lot of kremlinology that happens. People talking about all of the things at play, there's a group of sinister guys in a smoky room somewhere pulling all the strings. But I mean anybody who's ever operated in most businesses knows they can barely get a lot of things done, they're not definitely doing that. Even less believable when that's politicians. So I think I agree with you that it's not the major thing that people think it is with either Apple or Google the App Store revenue in exactly the way that it's portrayed, but it's also not nothing because both those companies have different factions with different budgets, and that is a very simple and basic way that plays out. In your ghost of Christmas past, you said Safari was against Extensible Web Manifesto? I never really felt that way. It's hard to say because they can't talk about it openly, but certainly their engineers cited it in a few cases. But I know that in proposals, there were people who occasionally would say this proposal is in line with this bit of the Extensible Web Manifesto. And I guess if that's a popular thing that people cite, you would understand why you would want to, but also definitely a bunch of other people were also critical, and I too am critical. But anyway, I was just curious, was there a thing that made you feel that or it's just?
Jake Archibald: That made me feel that Safari was against the Extensible Web Manifesto?
Brian Kardell: Yeah.
Jake Archibald: Part of it would be through my work on the service worker working group. Apple folks were in the room relatively from the start and contributing to meetings. But it did feel a lot, there was initially quite a bit of pushback away from the idea of it being a worker and is there a more declarative solution? And one of the things we did actually agree on at the time is that we will need something more declarative to avoid having to spin up the worker for performance reasons. I got frustrated at Google because they dropped the ball on that and they are doing it now, but it took a while. But yeah, other than that, it's things like all of the -WebKit, -CSS properties that seem to be doing one little thing that they needed in Quartz in the OS, like a reflection that was part of Apple's design language strongly at the time. And then things like IndexedDB just being left to rot. This thing had dreadful bugs, and they were left there for years. It made IndexedDB unusable and I felt this before I joined Google. IndexedDB was the thing I needed to use for particular projects, but I just couldn't not while making it also a project that would be compatible with Safari because it was just too buggy there. And I mean, obviously bugs exist. We all create bugs, but it was more the reaction of just not really bothering to fix them. It just didn't seem to get any priority at all.
Surma: So I was in the CSS working group for a while. I got into that because I was working on Houdini, trying to get Houdini started really. And again, Safari and Apple was part of that from the very beginning. They're always quite excitable for ideas that make the web more polished visually, and so they were really into Houdini on a conceptual level. But I also had a similar experience where it felt like they sometimes came into these discussions with a solution in mind that they weren't allowed to talk about and we're just trying to push discussion to stumble onto the thing that they internally had already agreed on. I don't know if that's the truth, but that's sometimes what it felt like. And part of the symptoms there, they were always going for something declarative, and didn't like the idea of imperatives API because I guess it's not like that they're disagreeing with a Extensible Web Manifesto per se, but they definitely seem to take more of a, we want to guarantee that the things developers build perform well or look good and they would rather constrain it so that there's no bad cases rather than giving developers [inaudible 00:21:05] and letting them run with it. And I think that sometimes was the tension I noticed. So there is definitely, I feel a philosophical difference in how Safari or Apple engineers approach the web platform and what should be added in the standards world here and how people like Jake and I tend to think about it.
Brian Kardell: The other thing that I wanted to mention is Safari is the one that gave us Canvas, which is one of the few really low level things that we had before the Extensible Web Manifesto. So I totally agree that it's more nuanced than that and that Safari's particular nuance was more toward yes, but we really prefer the high level things and less.
Jake Archibald: So Canvas is an interesting one, and I think that when I was talking about ghost of Christmas past, here's what Safari used to be like Canvas predates that period of time I was looking at because Canvas was before Chrome, right? Before Chrome was released.
Brian Kardell: Right.
Jake Archibald: But it also fits into something else I mentioned, which is a lot of, and again, because of how you don't always get full information coming out of Safari folks because of Apple's attitude to information, the big thing we would hear is that it wasn't when web developers were asking for stuff, it was when another internal team at Apple asked for something. That's when it really got done. And I definitely heard that about Canvas. This came from the WebView stuff, the use of WebKit within macOS or OS X at the time. They wanted a 2D graphics API, so essentially the 2D graphics API from Quartz was taken and just thrown onto the web. But you're right, it is a relatively low level system.
Brian Kardell: So I think the trouble is that the Extensible Web Manifesto is a pretty short document. It's very short. It's trying to be such a fundamental thing that it begs a lot of interpretation and follow-up. And I think it's also has to be remembered that it was written at a point in time. So it's reaction to the web of a decade ago, not the web of today. If you read it today, you would probably read it differently in a lot of ways. So the web had been almost entirely high level, really high level stuff. There were only a few really low level things. We had the DOM, we had these mutable prototypes in JavaScript and that's it really. We just happened to have also XMLHttpRequest, but everything that was good that was happening on the web that we were doing was figuring things out and rapidly experimenting and doing all these really interesting things, doing polyfills and stuff. And so a lot of the conversations there were, shouldn't it be, like Surma said at a later point, it's almost like tech debt. This new Navigation API that we have today, it's not even really the same thing, but it fills a need that previously gives you a holistic view. And also you had said Jake about pace transitions. Why am I ripping all this stuff out and reinventing it when the browser knows this stuff already? And yeah, that's what the Extensible Web Manifesto was also trying to say is, wouldn't it be great if we had this layered platform? And at the time, it was like prioritize those low level things like excavating the low level things to give us more parts to work with.
Jake Archibald: So the Navigation API is an interesting one because it is a little lower level than the History API. A little, not a lot. I think the reason we needed a Navigation API is that the History API was just.
Brian Kardell: Bad?
Jake Archibald: Really. And it wasn't fixable. It didn't integrate. It was designed by one guy, right? [inaudible 00:25:21] did great work on loads of the HTML spec, but there was a couple of bits that weren't great and History API was one and AppCache was the other. But yeah, so the Navigation API is still feels high level, but it gives you some more insight into the History system. But you can still use it without doing that if you don't need it. Probably the biggest flex we did from high level to low level was AppCache down to service worker. And when people say service worker is hard to use, it's that, well, yeah, we've let you write code in the middle of the fetch process. And that fetch process wasn't even specced. It was specced as part of the service worker effort and it had to be specced in a way of essentially just saying what browsers do, which of course wasn't entirely compatible, but then trying to get the browsers to meet in the middle and carve a path that worked. So to use service workers effectively, you need to understand large parts of fetch, and it is one of those examples where I think we should have built up much quicker on that into higher level systems because we've had time to observe now the kinds of things developers use it for. So yeah, we should be making that simpler, to have a look at the patterns, pave the cow paths as they say.
Brian Kardell: Yeah, this was supposed to be the idea, the Extensible Web Manifesto is that you could create? We called them prolly fills at the time, but speculative polyfills the tag renamed them to, where that's a much easier proposition, right? Hey, everybody says that they have this problem. You're all using JavaScript libraries and things to solve them now. Here's one that just emulates what we're thinking. Go try it. Because you can do that, right? You can go try it in the project where you're having pain right now and you can let us know without trying to participate in the standards life cycle, which can take, I mean it's not short. We've had a bunch of shows like Inert and Focus Visible. We had a show with Rob and Alice after that launched and we were looking back at the notes and we were like, 'Holy, that took seven years.' It's amazing. Nobody has time for that. People are worried about the project they're shipping next month. It's tricky, how do we get people involved? And I would like if we could find better ways to study that. I also pitched a thing on that to Open UI, maybe we can include a link to that, but I think we need ways to study that. And we have almost some of the tools that we need, like the HTTP Archive. We've done a lot since 2015 to improve the information gathering there, but this is also not perfect.
Jake Archibald: And there's good developer surveys. Now I know that's something that the folks at Google were involved in, and I know I think the other browsers were involved to some degree as well of going out and properly surveying developers and asking them where the pain points are. I was really happy to see that because I felt even as a DevRel working for a browser that folks weren't really listening to what me and the other DevRels were saying. And instead we're placing much more weight on what our particular team at Airbnb or Facebook were saying, even though we had a pretty big hunch that didn't represent developers at large. So I think these surveys are a good way of, it's not involving people in the standards process, but it's listening to developers better.
Brian Kardell: There are a lot of surveys, but there's the MDN developer survey, that was a huge, huge one. It had a lot of rigor. That is actually a thing that spawned interop and the WebDX community group and Eric and I are involved in both of those. I don't know if you have anything you want to say about those, Eric?
Eric Meyer: Yeah, I mean I miss the days when it was a smaller field and you could ask everybody, but those days are long behind us and are not coming back. Just things like the dev survey, like any survey, it's dependent on who you can reach, and are we reaching a representative enough sample of the industry that we're getting good signals there. And also, are we reaching the parts of the industry that are not what we might think of as a representative sample? How many dev survey results are we getting from China or India, which are enormous markets? Or Africa, anywhere in Africa?
Jake Archibald: Well, Eric, I mean I got to know you without you knowing me first through work articles and all of your CSS stuff, but we first met, I think, well certainly in the web conference world, and I spoke at Event Apart a couple of times. I think one of the things that event did a good job of is reaching those developers that weren't being, they weren't actively discussing web dev on Twitter. They weren't actively working on side projects on GitHub and exploring the latest frameworks and that kind of thing. And I think whenever I think of the developers that aren't being reached by some of these surveys or by someone like me when I was DevRel, I just felt like it was a total blind spot, was that group of developers that, and that must be, I don't know, I wouldn't like to put a figure on it, but I'm sure that's a huge percentage of the web developer community if you got us all into one room.
Brian Kardell: You also mentioned Firefox's shift and Firefox OS and you said Firefox OS is dead. But the interesting thing that I wanted to add to that is it seems like a whole lot of things happened at Mozilla Labs, and this is almost like Bell Labs where their things weren't successful, but then they went and inspired things that became reasonably successful. So I think KaiOS is still a thing now, right? And they actually have some business as far as I know.
Jake Archibald: Yeah, that's fair. I guess I meant dead in terms of it's not directing Firefox's strategy in the way that maybe it used to.
Brian Kardell: And also Servo is now in the Linux foundation, and I know because Igalia this year is doing a lot of work on it. Well, last year was doing a lot of work on it, and this year hopefully we can continue doing work on it. But as you said, it's only possible because we are funded by a super diverse group of people who have some kind of interest in something on one of the web engine. And I mean, I think that's really cool.
Jake Archibald: So what is Servo's position in the web development landscape? When it first came out, it felt like they're rewriting Firefox and then it felt like they took some of the things they learned from it and put it into Firefox. I didn't know it was still in the active. Yeah, that's right. I didn't know it was still under active development, so what is its goals now? Is it just to continue prototyping things that might go into Firefox, or is it trying to become its own complete package?
Brian Kardell: So it's Rust and there's all the Rust Crates. We had a show you can listen to with Martin who's one of the people on our team who worked on Servo originally and now also works on it again through Igalia and Linux Foundation. But I think those go in both directions. So there are people from Mozilla who still contribute, and some of those bits are used by Firefox. And I think there are some bits in Firefox that are still used through Servo as well. It's I think a little bit symbiotic right now, but its goal is to become useful as a thing itself to keep the development going. There are lots of uses of the web platform that don't have to be exactly feature complete, but need to have some characteristic about them that is really useful. So examples of this, there's lots of web engines that do something like what you were saying when Microsoft redid and had a new SVG that they could show off. Being really fast at Canvas or SVG or having some tweaks like that make you more appealing as an embedded web engine if you have more strict needs of what you do and don't need. So that's one possibility. Another is to keep it alive as a research project as it was originally, and maybe get built into various sorts of things and very community oriented. But yeah, it's an interesting thing. We have done a bunch of shows on.
Eric Meyer: The novel engines.
Jake Archibald: Oh, I like that term.
Brian Kardell: Yeah, so I think that what we are talking about just a minute ago is though part of the reason why, well, I don't know that this is the case. I actually want to ask what you think. So you had this, Chrome had this shift away to higher level and CSS, and probably, but it seems to me like Google's investment in CSS especially has always been really heavy. Do you think I read that wrong? Because they've always had somewhere around twice as many members to CSS working group as any other organization.
Jake Archibald: It might be that my read is entirely wrong here, but I felt like for a lot of time when I was at Google, the CSS focus was on the Houdini stuff. We were going to have a paint worklet, which we did get, but then we're going to have an animation worklet and you're going to be running code on the compositor, and you're going to have a layout worklet so you can prototype new kinds of layout, which is sounding great, or some way to hook code into this CSS selector stuff. Basically polyfilling any CSS feature was just an absolute nightmare and it just wasn't worth doing aside from as little experiments, nothing you would want anywhere near production code. And I think these days that is still 100% true. And the fact that Chrome isn't pushing on that any more as far as I can see is one of the things where I feel it switched to a little bit higher level, but also felt like I was pushing for page transitions for such a long time, and was getting pushed back because they weren't low level enough. But then suddenly we were allowed to do it, and then we're starting to see the higher level stuff trickle into service worker land as well. I think that's where I'm seeing that. But yeah, then there's lots of features that are landing in CSS, and I know that's not by any means just Chrome, but it's something that they're happy to chuck a lot of resources at. And I think there's a lot of, Chrome didn't really have a CSS devrel for most of the time I was there, but now I would say Adam, Yuna, and Brahmas are very heavily leaning towards the CSS side of things. So that felt like a shift in priorities as well.
Brian Kardell: Yeah, I mean I can see that. I also see maybe reasons for that. This is what I was trying to get at, I would like to ask. I also see in that same timeframe we got Grid, we got a rewrite of the underlying layout engine with LayoutNG, which was necessary. We didn't have fragmentation primitives, which are the basis for all the things that are happening now. We got lots of small selectors. We got CSS custom properties in that time. So it seemed like we were still getting a lot of other stuff besides Houdini stuff to me. And I wonder if a lot of stuff just got unlocked by paying down some of that tech debt, and also investment from the outside to take on some of those projects that everybody thought were impossible, like CSS grid. We did that in two engines and that seems pretty huge. Has, we're the ones that did the first implementation of that. That seems pretty huge. We worked on-
Jake Archibald: Was Grid in Chrome Igalia? Was that you folks?
Brian Kardell: Yes.
Jake Archibald: I felt for a long time that one of the things, the high level things that Chrome wasn't bothering with was Grid. I was a huge fan of the early stuff that appeared in IE because I didn't think Flexbox was good enough. But the message that I was hearing internally and also from some other folks as well is that, well, we've got Flexbox now. We don't need Grid. And I was like, well, no. It's like Flexbox is one dimensional, but there's large parts of the large parts of layouts which are not one dimensional. So yeah, I think that was one of the things where I felt like Chrome didn't seem to carry enough about the high level side, but that seems to have changed. But as you say, that might be about unlocking things by improving layout internally and also getting companies like Igalia to go and to do the work.
Brian Kardell: I think Interop also has been huge here. It let us align. And if you think about it in terms of a DevTools waterfall, the standards process, it's like there's no gaps. We're doing it all in parallel. So everybody's working on the specs and focusing on the same things at the same time. And so yeah, it just feels like a lot more productive on some of those CSS things probably too, because they're not taking four years, seven years, they're taking one or two years to get this major work done, which is really just about parallelism, which is a topic that Surma would like. Can I tell you a story about the Houdini thing really quick? I know we're way over time.
Jake Archibald: Do it. I want to hear the story.
Brian Kardell: So the reason that I began talking to Alex and Yehuda and Paul Irish and the people that I was talking to about the Extensible Web was because of the thing that Jake was talking about, which was I wanted to do something to polyfill CSS. And I was like, 'Boy, this is great.' You can polyfill other things like in JavaScript is great. Have these mutable prototypes. You can polyfill and basically not even be able to tell the difference for the most part. HTML less so, but maybe with Shadow DOM we could come up with something like that, but CSS, just forget about it. It was just, you can't. So after we published the Extensible Web Manifesto, I went to the W3C TAG and really lobbied on the mailing list and even went to some of their meetings and really put the pressure on, and got Alex to back me up on some things who was on the tag at that point, which is like, 'No CSS, you don't get to be special. You need to explain the magic. You need to have this kind of layering.' It doesn't need to be perfect. Do you know what I'm saying? It's just like there's no escape hatches at all. There's nothing. It is exactly the thing that you were saying, which is why am I reinventing all this? The browser knows how to parse CSS. I shouldn't have to write a CSS parser, but that's basically what you have to do and you can't plug into it in the same way because cross-origin stuff. And so finally, they said there's just not enough resources, there's not enough people. And finally I said, 'Look, the TAG has used in the past task forces. Doesn't have to be you. Maybe just say, we're thinking about doing this and seeing if anybody bites and is interested in volunteering.' Maybe somebody would, I would. They created a task force and I don't know, it was like somebody at W3C, I felt like they were gaslighting me because the name of it was WTF, What Task Force. And then surprisingly, all these people joined, all these people joined and they were trying to think of a name because that's the first thing you have to do is bike shed the name of your group. And it was going very, very badly. People wanted to name it FXTFFX or there were these wild acronyms that were totally meaningless. And so I said, what about Houdini? Here's why. And so that's where we got the name Houdini.
Jake Archibald: Oh, nice. Oh, I didn't realize you'd come up with the name. Very good.
Surma: No, I did not know this.
Brian Kardell: I am kind of sad about Houdini and I would like to know what you think about it because I think we focused on the wrong things and we burnt all the energy on goodwill without real success because I don't know that anybody needs a paint worklet. I don't think that that's the reason that we should have done Houdini.
Surma: Yeah, I would agree. I think I was always, and one of the things I look back on a little bit where I definitely presented publicly more excitement for something than I actually had. I knew it had use cases where paintwork lit was beneficial and helped you, I don't know, reduce the number of DOM notes in your document to achieve an effect and stuff like that. But the thing I was after was layout worklet like that for me was an extensibility primitive.
Brian Kardell: Exactly.
Surma: That was actually really valuable. I was also just conceptually really excited about the CSS parser API, which is exactly what Jake was saying, that you could actually start hooking into the parser, not only reuse it, but extend it was the idea. What if you could teach the parser about your own at rule and you provide the code.
Brian Kardell: Exactly.
Surma: Do the thing. But that one didn't even ever get a draft. I think it's literally an empty read me still. I haven't checked in a while but yeah, the things that let you hook into the engine properly were great. The original incarnation of animation worklet was also really cool because it was basically supposed to be a piece of JavaScript code that can take anything at input and control any CSS property. It could be scroll position, it could be time, could be another timeline as input, and you can do arbitrary math to set CSS properties or even set scroll position. I think it was quite the powerful primitive. But for the sake of shipping something, I think there were lots of compromises during standardizations that left us with a whole redesign and then animation worklet with that allowed effects that were very popular, like a scrolling defect, but were actually really hard to do right. And so I think it just never really got a lot of excitement and now we have scrolling effect in this case, being declarative is probably the better way to go about it. So yeah, I think I would agree with you that the things that were shipped, that were prioritized were not the things that Houdini was really at the core about.
Brian Kardell: Yeah, I think the parser media queries, custom functions is another one that you could do. There's a whole list of custom things that are listed in CSS working group drafts that I still would really like to see us do. And we are going back and looking at some of them now, but they're not called Houdini anymore, they're just CSS.
Jake Archibald: Do you know where you could define CSS functionality in JavaScript? Internet Explorer 6.
Brian Kardell: Boom.
Jake Archibald: Boom. Yeah.
Surma: HTC.
Jake Archibald: It's for people who've not, well, there's HTC, but there's also the expression CSS function that you could just put JavaScript in with a reference to the elements and that bit of JavaScript would run whenever anything happened on the page. So you move the mouse around, that little expression would be recalculated time and time again. It was an absolute performance disaster. But hey, a lovely piece of functionality. I definitely worked around bugs using it before.
Brian Kardell: This was so much fun. We probably need to wrap it up, but just on the way out, I just wanted to ask in your show, which everybody should go listen to, you closed off with what are your wishes? What should we focus on? If you controlled the money and the levers of power and whatever, what would you like to see?
Jake Archibald: I'm highly very influenced by the kinds of things I work on, and I've realized that everything I build has a static render, a worker of some description, and a checkered background somewhere. So that's Squoosh, which I did some of the front-end work on, SVGOMG, which I'm looking at building the next version of now. And so influenced by that, the things that I've been wanting for a long time and still aren't there is when I'm creating a pinch zoom component, I wish I could use platform physics. I wish I could make that pinch zooming feel like the official Maps app on the platform. It has all of the drag and all of that sort of stuff that feels natural. And I still think communicating with workers is such a pain, and I feel there are some really simple solutions there. Well, Surma worked on or built Comlink, which is a really nice library for bridging the gap between the main page and workers, but I think the platform could just ship a simple version of that. So if your module worker export a function, you should be able to call that from the other side. And obviously it would give you a promise for the value in that value would be structure cloned, and the whole thing could just be explained using post message and message ports under the hood. But I would just love to see that be so easy. I just want to be able to call a function on the worker I created that I have exported inside the source code for the worker. But yeah, maybe I'm thinking just because that's the side projects I'm working on right now.
Brian Kardell: Am I wrong? Maybe Surma, you can correct me if I'm wrong, but I feel like it's similar in some ways to CALM and CORBA and things from the early '90s even.
Surma: Yeah, it's history going full circle.
Brian Kardell: Right? It's really interesting, yeah, and I totally agree we should do something like that. It feels like we've been banging back and forth on a pendulum there. What about you, Surma? What do you think?
Surma: Yeah, I think for me, web platform, what is it missing? I feel like we have a couple of primitives lying around and you can all scoop them together and build really good things like app-like things even with it. But it still doesn't feel necessarily natural. If I sometimes look at your open Android Studio and you start building an app, just the fact that you build up your UI and you attach functionality to your UI elements and derive the next screen from a certain state object in a way that adapts to multiple devices fairly easily. It's like, yes, the web can do that as well, but it's definitely not as easy. And there's a couple of things that are quite easy to hook into on Android that is very hard on the web. And it's the thing like Jake, the platform physics, or you want to have a custom layout without trashing your entire page's performance or you want to intercept certain input events. I just want more of that to be exposed. Basically, I think what I'm saying is that I just want browser engines to be more modular and just allow me to replace certain parts of them with my own code if and when I want to. That would really give us the most flexibility to reuse most of the code that browsers have, and only ship the code where we need special behavior. Because the alternative currently is where it's this movement of you write your web apps in Rust with your custom web GPU renderer, which yes, ultimate flexibility, but also 19 megabytes of Wasm to get the square on screen. So I would love for us to find the middle ground where the browser has so much code, so much good, battle-tested, flexible code, and just many parts are not accessible to be reused and allow you to build more things.
Brian Kardell: Yeah, I think we need some stuff in the middle. Hey, thanks so much for coming on and humoring my invitation to come and chat on about these things. I had a really good time.
Jake Archibald: Oh, me too.
Surma: Thanks so much for having us.
Jake Archibald: Yeah.
Eric Meyer: Where can people find the Off The Main Thread podcast?
Surma: Hopefully, wherever people already get their other podcasts. If not, let us know, but it's Off The Main Thread. It's on Apple Podcasts, it's on Spotify, it's on Deezer, on Amazon.
Brian Kardell: Is it on Google Podcasts? Oh, wait, that's gone.
Jake Archibald: Oh, another dead one.
Surma: If you don't know where to find it, offthemainthread.tech is the website where there's links to all of them, and also a custom-built player by the two of us.
Brian Kardell: Awesome.
Eric Meyer: Okay. Very nice. And where can people find each of you individually on the interwebs?
Jake Archibald: On the various socials.
Surma: We have links to the Twitters on the offthemainthread.tech so people can find us there. And then you play, grab the rope, and just swing through all the interwebs to find the other ones. They're all linked from one way or another, so that's probably the starting point, offthemainthread.tech.
Brian Kardell
Eric Meyer
Jake Archibald
Surma