• Eric Meyer
• Brian Kardell

Transcription

• Eric Meyer: Hello, I'm Eric Meyer, and I'm a Developer advocate at Igalia.

• Brian Kardell: I am Brian Kardell. I am also a Developer advocate at Igalia.

• Eric Meyer: This week on Igalia Chats, we're going to do a time-honored tradition, the Mailbag episode. Pretty much, people have sent us questions, or made observations, and we're going to riff on those this week.

• Brian Kardell: I think, every week or so, Eric and I get together and talk about, 'Okay, what's our next Igalia Chats? Who are we going to schedule to have on,' if we're having somebody on? We have a list of them that are pending, and we thought, 'What could we do?' Eric suggested, 'Well, let's just toot, and ask, what do people think we should do?' A whole bunch of people wrote in, either via Mastodon on or through private channels, to suggest things, and ask questions. We're going to just going to talk about some good ideas in there.

• Eric Meyer: Yeah, we got enough good ideas that I think we'll do this again in the future.

• Brian Kardell: Somebody suggested, it was Fynn Becker that suggested that accessibility might be an interesting topic, firstly because of the discredit thrown around by one Jakob Nielsen, but more importantly, because of the upcoming 2025 deadline for private sector businesses to comply with the European Accessibility Act. We agree, that is a good show. In fact, we have been talking about doing at least one accessibility episode with some accessibility people on our team, so that is actually one of the ones pending. We had a different spin on that in mind. We hadn't been thinking about talking about the deadline for businesses to comply, so maybe we should also do a show that's more along the lines of what this one says, in the future.

• Eric Meyer: Yeah, that question was actually the first that I had heard of this upcoming 2025 deadline. I try to be aware of accessibility, and I try to make sure that the things that I do are accessible. I'm not as steeped in the community as many. It's not my primary area of focus. CSS still claims that spot for me. That's very interesting, that there is a deadline, apparently next year, for private sector businesses to comply. I don't want to speak too in depth on this, because I don't know much depth, a reason why we'll probably do an episode about it. We'll have someone on who actually knows what this is all about, and what the deal is, and then we can learn along with everyone.

• Brian Kardell: We could maybe, for listeners who aren't familiar with what the shade thrown by Jakob Nielsen is referring to, do you know what that was about?

• Eric Meyer: Basically, Jakob Nielsen, who was really a ground-breaker in user experience research and thought 20, 25 years ago, Nielsen/Norman, Jakob Nielsen and Don Norman, basically created a consultancy, and really blazed a lot of trails, and really did a lot of groundbreaking work in that area. That doesn't mean that Jakob is an expert in all things, and Jakob recently published an article basically saying, 'Accessibility has failed, everything is bad, AI will fix it.' A lot of accessibility experts said, 'Whiskey, tango, foxtrot, dude.'

• Brian Kardell: Leonie Watson, our friend, had a pretty great take down of that, in a way, which was basically her saying how she thought about this all day long, as she did all these tasks on her computer. She just walked through her day. 'I thought about while I did this, and I thought about it while I did that, and I thought about it while I did that.' All these things are the things she does on the web, and she is blind. Saying that it's a complete failure is obviously wrong. It's just observably wrong, but I think there's a point. Sometimes a point gets made poorly, and I do think that it could be better for sure, and I don't think that Leonie disagrees with that, even. We have presented things together that is like, 'Accessibility is, actually, unfortunately harder than it should be in a lot of cases. We should work on that.'

• Eric Meyer: A lot of the people who responded to the article said things along those lines. 'Yes, things could be better, but the solution proposed here is terrible,' I think is what I got down to. Expecting 'AI,' and I'm going to put the quotes around it, because from what I saw, Jakob was mostly talking about things like large language models to generate completely user-centric interfaces, and the point was immediately made by other people, you're saying that every single person will have their own UI? How is that going to work? How is anyone supposed to ever help anyone else do anything?

• Brian Kardell: That is interesting. This is a thing that gets thrown around a lot, on that respect specifically. How is anybody supposed to help anybody do anything? How is it supposed to work when you call tech support if you don't have the same interface? It's very common that you don't have the same interface, because you have an iPhone and an iPad, and your laptop and your computer with the big screen. In responsive design, those may be very different things.

• Eric Meyer: They may be, yes, but they would be consistent from one similar device to another.

• Brian Kardell: Sure.

• Eric Meyer: Whereas, I think what Jakob is talking about is, literally everybody gets their own software constructed.

• Brian Kardell: Yeah.

• Eric Meyer: Even reading it, I was like, 'I don't think Jakob knows how this would work either.' I don't know that he's thought about it that far.

• Brian Kardell: Yeah, I don't think so, either. Jakob Nielsen, I used to follow him very closely, and I remember thinking for my whole life, not my whole life-

• Eric Meyer: Your whole professional life.

• Brian Kardell: Yeah, my whole professional life, I've followed his work, and I just remember always thinking, when I would read his things, his website is so ugly. How can I take the advice from this guy? He did have a lot of good research, and I think Don Norman is the guy who wrote The Design of Everyday Things.

• Eric Meyer: Correct, yes.

• Brian Kardell: That is a really good book, I thought. I enjoyed that. There's so many good practical things in there that people still don't pay attention to. I point out the door example, I don't know how we design doors so poorly still. It seems so obvious once you read that book. It's like, 'Of course, this means pull,' and still somehow, we get where it's not that way. I don't know, I guess to an extent that is built in. Maybe we should move on. That could be a whole show of its own.

• Eric Meyer: Yep.

• Brian Kardell: Let's see. Dayan, who is on the MathML working group with me, wrote in to say, 'Top of mind, I'm curious if anyone in browser land, or Igalia land, wants to comment on the White House memo, Future Software Should be Memory Safe. I know you recently had a Servo conversation mentioning Rust. Maybe there could also be conversation mentioning C++, and various security risks. Given the memo, are there long-term maintenance risks?' I was not aware of this memo. Were you aware of it?

• Eric Meyer: I had become aware of it maybe half a day before Deyan asked the question, and mostly, I had seen that it was a thing, but I hadn't really gone and looked at it yet, and Deyan's question prompted me to go look at it.

• Brian Kardell: We mentioned Servo because we're interested in it, but also because Igalia is working on it. This week, coincidentally enough, two things happened. Well, I guess three things. One, we led a W3C breakout session on how we fund the web platform. Two is, I wrote a blog post about it, and three is, we launched a collective for funding Servo. You can go donate some money to that, or better, try to convince your company to do that.

• Eric Meyer: And spread the word. The reason that it fits in here, and why Deyan brought it up is that we've talked about Servo, and Servo is written in Rust, and Rust is designed to be memory safe, many other things, but memory safety is one of the core design principles of Rust as a language. If future software should be memory safe, then languages like Rust are good languages to use for implementing things. My understanding is that C++ is not memory safe in any way whatsoever.

• Brian Kardell: Yeah, it is not memory safe. The reason that I tie those things together is, I wanted to make the same point that I made in my blog post about it, which is, better if you get your company to invest in Servo. There's a lot of good reasons for your company to invest in Servo. Better yet, if you know somebody who works at the White House, tell them that there is one surefire way to make sure that lots and lots and lots of future software is memory safe. That would be to invest in a web engine that is memory safe because it's written in Rust, and there's only one of those. Send them a link to the collective, and say, 'We'll be waiting for the check.'

• Eric Meyer: For that matter, if this is truly an important thing, which I would tend to agree, software should be memory safe in general. It's also for national security reasons, perhaps, but software should just be memory safe. Putting some funding into languages like Rust, they are also largely advanced by groups that are looking for funding. The more support that goes into memory safe languages, not languages that are having memory safe wedged into them, but languages that are just memory safe from the outset, would be a good thing. Certainly a web engine, it's been said by many people, but as we said in our presentation on funding the web ecosystem, the web is now infrastructure for 5 billion people. That is over half the entire human population. There's probably a decent chunk of the other 3 billion people who do not directly rely on the web, but things that they rely on rely on the web. It's indirect infrastructure for probably a decent chunk of the 3 billion that were not included in that 5 billion, and it's really important that we treat the web like the civilizational infrastructure it has become and is continuing to become.

• Brian Kardell: Absolutely.

• Eric Meyer: And treat it on par with things like electricity.

• Brian Kardell: Roads.

• Eric Meyer: Definitely roads, treat it like roads. I know that not everywhere treats roads great, you and I live in the land of potholes, but they're still maintained. They may not be maintained as perfectly as we would like, but they're still maintained. Things like web engines are now really much more critical than, 'It lets me watch YouTube.' I think actually, those of us in the industry tend not to realize it. We tend not to realize how critical these things that we work with, and sometimes curse at for not doing exactly what we want it to do have become.

• Brian Kardell: Yeah.

• Eric Meyer: In the same way that there's public radio and public television, should there be public web engine? I am not ready to jump to one conclusion or the other, but I'm leaning pretty more heavily towards yes these days.

• Brian Kardell: What's really amazing about it is that, when we talk about public radio, here in the U.S., we have national public radio, and that mostly gets some tax breaks, I think. Very little of it is actually funded nationally. A lot of it is funded by sponsorships, fund drives, things like that. We could fund it any number of similar ways, but also, we don't even have to limit it to a single country, because this is infrastructure for the entire world. If every country kicked in a little bit toward that, it would probably be almost as much as any of the big companies make.

• Eric Meyer: Yeah, probably. Again, this is a thing we could do a whole show, probably more than one whole show about, so we should move along. I'm going to introduce the next one. Peter Rushforth said, 'Waiting for the day when maps are the topic.'

• Brian Kardell: Speaking of government, Peter Rushforth works for a part of the Canadian government that is concerned with maps. I'll give you the context for this. He believes that we should have maps in HTML. Well, there is a map element.

• Eric Meyer: I was going to say, actual geographic maps as opposed to the area map elements.

• Brian Kardell: That's right. He has been working with a community group, it's a small group, I think, but they have been working for 10 years on trying to make some kind of polyfill, it's a custom element. A lot of what they had, at least four years ago or so, it involved a protocol. It involved something more like ActivityPub, but for maps. It has a whole protocol that goes along with it, because maps are like that. When you get geographic information, a lot of times, you need to get a particular zoom of it with particular features, and communicate back and forth to the server. It's an interesting problem. They've been working on it for a long time. There was a W3C workshop a couple of years ago that Igalia attended, and produced a position paper on. I think that there is room, actually, for some maps related stuff in HTML, in the web, and I would like to see something happen there. I think the challenge is, a lot of different people want different things out of that, and I think that there are challenges getting everybody on board to the same page. Also, it's complex, it's very complex. I had some ideas. I know Amelia Bellamy-Royds, from SVG and CSS fame, also did some consulting work on that, and also had some ideas. She helped organize and run the workshop. Yeah, that could be an interesting show. Maybe at some point we could do a show on that.

• Eric Meyer: Maps are clearly a major use case on the web.

• Brian Kardell: For everybody, right?

• Eric Meyer: Right. A lot of the mapping stuff in your phone, your mobile device, is web driven. It's not running at the internet layer, it's running at the web layer. It feels like this is a thing that maybe there should be native elements to describe this. The other part of me is like, 'Yeah, but there are so many other things that could be like that. How far do we want to take this?' Maybe custom elements are the way to go. It's great that's where they're starting. Don't get me wrong, I love maps. I have loved maps for a long time, the aesthetics of them, the utility of them. Of course, you and I come from an era when maps were printed in books that you bought in gas stations and you kept in your car.

• Brian Kardell: Had spent hours trying to get back into the right shape.

• Eric Meyer: Exactly. You had to learn how to fold them, or you had to decide that you just didn't care. Eventually, the wrong way folds would cause them to rip, and develop holes, and then you would eventually replace them. Planning a route basically on paper with a highlighter, I have always really enjoyed and appreciated maps. For me, to have them be more native to the web, I would find that awesome at a personal level. It would be really interesting. The map group's effort reminds me a lot of MathML, where there's a mall core of dedicated people trying to push something that they feel is really important, and have done work with, essentially polyfills, whether those are custom elements or using JavaScript the way that... crap, I just lost it. The JavaScript library that will take text syntax and turn it into either an SVG or-

• Brian Kardell: It's one of those LaTeX to HTML.

• Eric Meyer: Yeah, stuff like that.

• Brian Kardell: It's a conversion library from one to another.

• Eric Meyer: It would be very interesting to see advancement in that area.

• Brian Kardell: Let's see, moving forward. Eric Portis, another friend of ours, 'The web as an input and output of AI.'

• Eric Meyer: Yeah.

• Brian Kardell: Biggest web... he had several.

• Eric Meyer: Well, let's start with the first one. The web is definitely being used as an input to AI.

• Brian Kardell: I think too big a topic, should be its own show.

• Eric Meyer: Well, probably, and when we say AI, really here, we mean large language models. There really isn't a larger source of language than trying to snarf up the entire web, and then using that to be the output of your large language model. I've seen various people do things like, 'We're using chat GPT to generate layouts. Just describe the layout that you want, and it will spit something out,' and that sometimes works. Simon Willison was recently writing, or posting somewhere about how they needed to do something in CSS. They weren't sure how to do it, so they used one of the large language models. Simon uses every single large language model available, so I don't know if it was chat GBT, or what it was, I don't remember. What Simon said was, 'I told it what I wanted to do, and it spit out CSS that was wrong, but it was close enough to right that it got me the rest of the way.' That was, I don't know, interesting in a sense.

• Brian Kardell: Yeah, it's interesting. Sometimes that's really great. I've heard a lot of other interesting feedback on that. Basically, you're doing that in isolated places, so you're like, 'I am stuck. I need something here.' It is not aware of your whole rest of your code base, if you have something that solves parts of those problems already, you already have functions somewhere. It's going to solve that problem in a vacuum, and what ends up happening is, there's large amounts of repeated code. It tends to get not very dry at all, and you wind up with obscure bugs in potentially many places. Other questions that he asked, 'HTTP, does Igalia work on it at the IETF?' We don't really work on the IETF, on HTTP itself, except passively. There are some things that we have gone and worked on there, but we do have people who do implementation. We do maintain the library that WPE uses, and I think Epiphany as well.

• Eric Meyer: Are you thinking of libsoup?

• Brian Kardell: Libsoup, yes. Delicious, delicious libsoup. Libsoup, it's made of all the precious libs, when they're in season anyway. He also had a documenting/teaching/learning web development in 2024.

• Eric Meyer: There's a lot of things are either degrading or shutting down. People have been getting mad at MDN recently, because Mozilla has done things that they don't like. There's that, but Eric Portis also mentioned An Event Apart, which closed its doors at the end of 2021, A Book Apart, which has not closed its doors but is shifting to no longer producing new books, basically maintaining its back catalog and that's it. CSS-Tricks, there's been a lot of commentary about how DigitalOcean bought it, and promised to do a lot of great things with it, and has not done many if any of those things. There's no new content showing up there. My feeling is that documenting/teaching/learning web development, MDN is still the go-to, but beyond that, it's really much like social networking, for many of us, has become decentralized. You don't any more go to A List Apart. For a long time, it was just, everybody was subscribed to that, and when they published a new article, people were talking about it. They haven't published a new article in a while, and it's the same thing. You don't have just one place to go. Smashing Magazine is maybe the closest you get to that, but I don't see a lot of people regularly talking about articles in Smashing. People will regularly talk about, 'Hey, I just saw the CSS article,' and it turns out to be from some website that you've never been to before. Or, 'Hey, check out this CodePen that shows this really cool JavaScript trick.'

• Brian Kardell: There is Web.dev. They're getting a lot of stuff, and investment. It's all Google, mainly.

• Eric Meyer: That's true. There is some there, but again, we're not any longer in the era of single points of conversation. It's very much more like the very earliest days of blogging, where you would see on somebody's blog, 'Hey, I was just at this other site.' You'd jump around, and there were web rings and things like that. There wasn't any one place to go. It feels to me like we're in another phase like that.

• Brian Kardell: Yeah. Just a reminder, this show is brought to you by Igalia, who are proud sponsors of Open Web Docs. You can support the web platform documentation of the web that exists on MDN, and is written by independent contributors. We really love it. Opencollective.com/open-web-docs.

• Eric Meyer: Yeah.

• Brian Kardell: Okay, so the biggest web platform regrets was his last question.

• Eric Meyer: Yep.

• Brian Kardell: I wanted to say that when I saw this, I felt like I've seen just the same day, even, a thing, maybe it was the day before. Kent C Dodds had asked a related question, but it's different. It was, if you could break backward compatibility on the web, what are things you would break and why? It's not the same question, but it does have this similar, if I could go back in time aspect to it, and for me, it's headings, I think. H-one, H-two, H-three, H-four, H-five, H-six, the thing that irritates me the most about them is that it's a bad idea, and we knew it was a bad idea from the moment that the web existed. There was a moment in 1991 when Tim Berners-Lee sent the first real email to WWW talk. I always have to say that very carefully, in which he had very few commentaries, but one was, 'We should fix that. That's not smart. There should probably just be section and H.' The only reason that H-one through H six exists is because it was part of SGML before that, for 30 years. Tim was trying to solve, originally, a chicken and egg problem. How do you wind up where you're not in that xkcd comic, where you're like, 'There are so many competing standards. We should just have one. Let me make a new one. Now, there's just one more.' He just graphed across the corpus of existing documents CERN, and a lot of them were this SGML, and of course, they had all of the things that are most common in text. That should surprise no one. It included all these H's, and it was flat, because of its origins. The reason it bothers me is because, what a lot of people don't see is that there are just thousands and thousands of person hours that have been spent trying to get that fixed since then, and trying to get accessibility right. It's not the way that the web should work. What you want to say is, 'This is a section, and this is a heading for the section, and it's going to be pulled in via a CMS, or template constructs, or whatever. The reason that we separate them out like that is because, well, it will exist in potentially many contexts. We don't know.' Maybe on the overview page, it's an H-four, but in the article itself, it's an H-two. Because of the flat, original nature of this, and the fact that there are numbers, and the fact that there are now so many documents as screen readers, and the fact that we also tried to make this document outline in HTML five, and then did the worst possible thing, and implemented the CSS that makes it seem like it worked, and also didn't make it a breaking change. It's very difficult to fix in retrospect now. I still want to fix it, but if I could get that time back from all the people that have worked on the problem, I think we can agree there are better things that they could do with their time if they could get that time back, and the world would be better for it in both respects. That's mine, it's subtle, but there's other things. There's so many things, right?

• Eric Meyer: Exactly.

• Brian Kardell: Another one that makes me very sad, for example, is that we have the CSS OM.

• Eric Meyer: The CSS object model?

• Brian Kardell: Yeah, and that's nice. You can get at it, and if you want it to do something that was polyfilling, or you want it to make a CSS-like language, it's great, but you can't really use it for polyfilling because it throws out things that it doesn't understand. The parser doesn't build the CSS OM for stuff it doesn't understand, and I think that's really regrettable. It's made some things a lot harder than they could be otherwise. Yeah, there's a lot of stuff like that.

• Eric Meyer: I did look, in the replies to Kent Dodds, 'If you could break backwards compatibility, what are the things you would break?' A surprising number of people just answered CSS. Didn't say what about CSS, and it wasn't clear if they meant, 'I would just throw away CSS and replace it with something different,' or if they were saying, 'I would break backwards compatibility in CSS so that we could fix some things about it.' Certainly, the CSS working group maintains a list of design mistakes in the language. It says at the top, 'To be fixed if we ever get our hands on a time machine,' things like the original box model being content focused rather than border focused. The whole reason that the box sizing property exists, and a whole bunch of people just say, 'Star, box sizing border box,' because they want everything to be sized by the outer edge of the border. I get it. I totally get it. Headings is one of mine, too, but you already covered it, so I'm not going to go through that again. Actually, I regret some of the missed stuff in HTML three, not HTML 3.2, but HTML three, that had things like a footnote element. There were a number of really interesting ideas in there that just didn't happen, and have probably been re-implemented by many people over the years, in many different ways. Footnotes and side notes have been re-implemented so many times by people using JavaScript, usually just JavaScript. There were a number of things similar to that, that were proposed in HTML three that did not make it to HTML 3.2, that I wish we could have had, because we would have, maybe a richer expression. This whole thing, this is the nature of the web at the technological level. You can't really break backwards compatibility. That's just a built-in design principle.

• Brian Kardell: Unless you really have to.

• Eric Meyer: Well, right.

• Brian Kardell: We broke backward compatibility for HTTP.

• Eric Meyer: Yes.

• Brian Kardell: Because HTTP was inherently unsafe. We moved enough of the needle to HTTPS, and made it possible enough to convert that gave it enough time to happen, that we finally agreed to, we're not going to support that anymore.

• Eric Meyer: In general, you have to have an extremely compelling reason to break backwards compatibility. By design, the web is supposed to be backwards and forwards compatible in time. This is why a lot of web features take what seems like an inordinately long amount of time to figure out how they're going to work. The amount of bike shedding that happens in the CSS working group, for example, over, what should this property be named? This is because the working group is constantly trying to think five, 10 years the road. If we do X, is that going to close doors that we're going to regret later? You can never think of every possibility, but there's really a lot of thought put into, is this violating any of these forward or backward compatibility design principles?

• Brian Kardell: Nathan Knowler wrote in to say, 'I think this has come up already in some episodes, but maybe a dedicated episode, or a series of episodes about how to get involved with web standards.' Yeah, that could be a good future episode. In fact, I spoke to someone yesterday about coming on, they agreed to come on. I'm not going to say who that is yet, but I think Simon Pieters would be a good guest for that as well. He is now at Mozilla, originally was at Opera. He did a thing while he was at Bocoup, which was the web platform contribution guide, which is very good. I think that would be good, to get him to come on.

• Eric Meyer: Seth Roby said, 'Sometimes it seems like Webtech assumes you're doing a complete rewrite of your site every couple of years, to pick up new stuff. It's all amazingly backwards compatible,' like we were just talking about, 'But we rarely talk about how to evolve what you've got in place as the years pass on, and your tech debt accumulates.'

• Brian Kardell: Yeah, I think that's an interesting topic. I used to think that myself. How are y'all writing your apps over and over again? Oh my God, I used Backbone, and then I switched to Ember, and then I switched that to Angular and then this other thing, and then React. Well, I really like Vue. Where are y'all getting the opportunities to write so many things? Do you work on that many different projects?' I would be involved in products that had... the shortest project I think I've worked on ever was a three-month window, but a lot of times, there were year projects, or multi-year projects even. Then you don't have as many opportunities to switch, so you have to get them. You can't just rewrite your entire application over again because there's some cool new thing.

• Eric Meyer: Yeah.

• Brian Kardell: I guess some do.

• Eric Meyer: Well, sure, but you made a good point about the HTTP archive data.

• Brian Kardell: Yeah, if you look at the HTTP archive, it shows that there's a lot of use of jQuery. I don't think that it's because so many people are choosing it today. I think it's because that stuff just exists in old code, and that code is mature, and we don't want to mess with it. When we say mature, sometimes that's code for, I'm afraid to touch that stuff.

• Eric Meyer: Yeah, and certainly, if someone created a site 10 years ago using jQuery, and the site's still up, it's probably still running jQuery, and jQuery still runs in browsers, because forward and backwards is compatible in time. It's going to show up everywhere, and I think that's what happens. At the same time, at least that aspect of it, I don't think of it as tech debt. You've got a site that's running on jQuery. Okay, so your site runs on jQuery. That's not tech debt. I think ongoing active projects that have many pieces, when each piece is written in the latest hot new thing, that's where the tech debt really stacks up, because over time, more and more, you have to get them to work with each other. You have these different pieces. Does the Preact thing talk to the jQuery thing, or however it's set up? That can be rough.

• Brian Kardell: That can be rough.

• Eric Meyer: I think in that case, really, your solution is, make it work until it doesn't, and then you fix whichever bit broke it, honestly. Yes, I know again, that's an accumulation of tech debt all on its own, but I feel like, as with many systems, not just code, but many real world systems, you either have to start from scratch or you just have to continually adapt.

• Brian Kardell: I can say that there is this mentality in corporate software that, we want to be an X shop, whatever X is.

• Eric Meyer: Right. Not Twitter.

• Brian Kardell: Right, not Twitter. For example, I worked several jobs in my career that were like, 'We had all these different solutions on the server tier middleware, but we want to be a Java shop, and we want to be based on Spring MVC, or Struts, or some particular framework.' The place that I used to work had 170 different web applications. By the time you start digging into that, something in that is going to change. You can't rewrite 170 web applications overnight. It took you 10, 15 years to get there in the first place. Once a lot of things are written, they go into maintenance mode, and they don't maintain the same budget that they took during development. A lot of times, it's the same 10 people made 20 applications. It's a lot easier to maintain an application once it's already running, because we do have this good backward compatibility on the web, than it is to keep writing them fresh. I have faced this, where you're trying to look at the problem, and how do you manage this? Especially when there is interesting churn. Maybe at one point, the solution to everything was jQuery, and you were like, 'This is good, jQuery. These are good jQuery UI. This is good jQuery plugins.' Later on, it was like, 'We do actually do a lot of application-y things, and maybe it's okay if those are Angular,' and then you spend some time figuring out where the marriage of your server side and your client side... I think it's engineering, and breaking down problems, and accepting that you're probably never going to get to 100% on any of them, and finding where the big wins are. If you're doing performance stuff, that's why you say, premature optimization is the root of all evil. You could be spending a lot of time on something that ultimately doesn't matter very much. Only when the thing is running, and you can see it, can you get a really good sense of where the bottlenecks are. You can spend a little bit of time on maybe the most important two or three bottlenecks, and suddenly have a system that's 300% more efficient, and it's like, 'Fine, maybe there's diminishing returns from there.' I do think the thing that I said about jQuery raises an interesting question in my mind, that I have to remember to follow up on. Barry Pollard or Rick Viscomi, if you're listening to the show, please write in and let me know if we know the jQuery version distributions that are out there. That would tell you if we're getting new versions of jQuery, or if they're still the 1.3, 1.4 versions that have been out there for 10 years or more. That would be interesting to know.

• Eric Meyer: I think that actually, that about wraps it up. We're about out of time, but we can do this again in the future. I think we will. If people listening have questions they'd like to hear us address, maybe ping us on the interwebs, or drop a comment on YouTube, if that's where you listen to Igalia Chats, on YouTube. Always happy to see questions there. Let us know what you think. Let us know if we got any of this wrong, because we might have.

• Brian Kardell: Let us know what you think about the mailbag episode format.

• Eric Meyer: Yeah, that too.

• Brian Kardell: If you enjoy this once in a while, or you think it's not actually so interesting. We do have plenty of topics. I think we just got another five or six today. The other thing is, if we missed your question, because we did not get to at least three or four other people's questions, we just ran out of time, sorry about that. Maybe handle it in a future episode. All right, thanks. That was fun.

• Eric Meyer: Yeah, that was good. Talk to you later.

• Brian Kardell: Bye.