The infamous Jake Archibald, member of the Chrome Team, an author of the Service Worker spec, and host of the HTTP 203 Podcast takes us on a whirlwind tour of recent and upcoming browser standards including Portals, iframes, App Cache, Service Workers, HTML, Browser History and more - why they are the way they are, why we can't have nice things, and how we might get nice things anyway in the future. Lots of good back and forth and only a little name calling… jaffa…

Panel

Guest

Sponsors

Links

Picks

Special Guest: Jake Archibald.

Sponsored By:

AJ_O’NEAL: Well, hello, hello, everybody, and welcome back to another beautiful episode of JavaScript Jabber. This week on our show, our guest is Jake Archibald. 

JAKE_ARCHIBALD: Hello. That's me. 

AJ_O’NEAL: That's right. Ladies and gentlemen, it's the one and only. And on our panel today, we have yours truly. Yo, yo, yo, come in July. From They Changed the Trash to Tuesdays. And then we also have Dan Shapir. 

DAN_SHAPPIR: Hi from Tel Aviv. 

AJ_O’NEAL: Amy Knight. 

AIMEE_KNIGHT: Hello from Nashville.

AJ_O’NEAL: And last but not least, I'm just reading from left to right, Steve Edwards. 

STEVE_EDWARDS: Hello from beautiful sunny Portland. 

 

This episode is brought to you by Dexecure, a company that helps developers make websites load faster automatically. With Dexecure, you no longer need to constantly chase new compression techniques. Let them do the work for you and focus on what you love doing, building products and features. Not only is Dexecure easy to integrate, it makes your website 40% faster, increases website traffic and better yet, your website running faster than your competitors. Visit dexecure.com slash JSJabber to learn more about how their products work. 

 

AJ_O’NEAL: All right. Well, with that out of the way, let's go ahead and kick this busy off. Jake, I have no idea why you're on the show because my notes are completely empty. 

JAKE_ARCHIBALD: That's great. Yeah. people a good heads up for what I could talk about, because I just sort of threw some notes together just earlier today. But firstly, I don't think I am the one and only. I looked this up. I think there's some college footballer also called Jake Archibald. I really thought that my parents had came up with a good idea by giving me such an obscure name, but it hasn't worked. I'm not the one and only. I'm having to share this world with another a couple of Jake Archibalds, I think. 

AJ_O’NEAL: So you're not the NFL player. 

JAKE_ARCHIBALD: Oh, this show is going to be very disappointing for everyone who was expecting that because like my knowledge of American football is less than my knowledge of English football, which is not a lot. 

AJ_O’NEAL: So hmm. Well, that is disappointing. I thought we were having an episode about football throwing job scripters, but that's okay. We'll move along. What are we having a show about today, Jake? 

JAKE_ARCHIBALD: Well, that's, that's a good question. Um, I've been looking at the session history side of the browser recently, it started off working on portals and pre-rendering. So portals is this new HTML elements proposal, which is a little bit like an iframe, but it's like a temporary representation of the page. The idea is that it would become the main page after a click or after something. It's kind of a primitive that allows you to do things like navigation transitions. So you can imagine like throw a page into this portal, you load it into a portal, and then you animate it from the side of the screen to the full screen, and then you activate it. And then it's like just a normal navigation, but you're able to animate the progress of it. 

 

DAN_SHAPPIR: I'm not going to let you just relegate portals to such a meager description, because if you brought it up, I think that portals are potentially, if and when they land because I haven't heard they're like an official part of any standard yet. I think that they'll potentially have a really significant impact on how we build websites and even web applications. I think that, you know, a lot of the stuff that we currently do as single page applications may actually, you know, transition back to being multi MPAs or multi-page applications without a lot of the downsides that are usually associated with MPAs and some of the reasons that have cost a lot of us to develop SPAs or single page applications. 

 

JAKE_ARCHIBALD: Yeah, I agree with that as well. I know a lot of people go from a multi-page app to a single page app because they want to control things like transitions from page to page. You take on a lot of complication by doing that. You can really hurt performance by doing that and not realizing you're hurting performers. So yes, so offering a multi-page way but to have those transitions from page to page will hopefully be a big win. I know that I end up in situations where I'm on a site which is built as an SPA. GitHub is a good example of this, where I sometimes I click a link and it's doing its SPA style navigation. And I know it's quicker to open it in a new tab because they do a server render, but their server render is quicker than their SPA style render because most SPA style renders don't stream. So you have to wait for that full page content to come through before it shows you anything, which like all of my complaints about web performance or, or come down to websites, which withhold everything or withhold anything until they have everything. So, you know, the downloading lots of data, but they're not doing anything with it. And then once they've got it all, they serve it all up at once. And it's just like. It's not what the browser does by default. And there's a reason for that. And it really hurts performance. So yes, if we can get back to a model where we can have the browser's default streaming, but we can do these enhanced things like transitions, that would make me happy. 

 

DAN_SHAPPIR: The funny thing though is that an original reason for, one of the main original reasons for single page applications, besides the ability to do fancy transitions which you can actually do transitions between pages, even without a single page applications, was originally actually about performance and also about not losing context. So you could link, you could click a button on the page that started in AJAX to get some data that will update the page, but while waiting for that AJAX to complete, you could actually remain interactive and responsive to user interactions within the user interface. So it's funny that you're actually criticizing SPAs for doing the, for behaving in the way that was one of the original motivations for going from NPAs to SPAs. 

 

JAKE_ARCHIBALD: Well, I think we maybe got lost along the way a little bit when like, so yes, using Ajax, as we called it at the time, to use a press of a button on the page, it fetches some content and it appears sort of in line without disrupting everything else. Yeah, it's great performance. When I was an intern at Reuters, which was my first ever web job, I used XMLHttpRequest for the first time. It had a little click to expand area of the page, and I knew that the database requests to populate that area were actually quite expensive, and not a lot of people use it. It was a great way to introduce that without losing context to the rest of the page. But once you're replacing most of the page's content anyway,

that's when you start to cross this threshold of, like, you lose the benefit of the SPA because you're replacing anything anyway, there's like, there's not a lot of context preserved and then you're losing the benefit of streaming. So like for people who don't know, like HTML is a streaming format. Like if you've got a 12 megabyte document, like the HTML spec, for instance, the browser can start rendering that as soon as it has just like the header bit. But generally when we do the SPA thing. What we tend to do is fetch a load of text or JSON. And then when we've got it all, then we pass it onto the next bit of JavaScript, which is going to render it into the template or whatever. That's not to say that all SPAs have this problem. You can pick a format like newline delimited JSON. And so you can download a set of 100 search results, but start displaying them as soon as you've got the first one. And that's relatively easy with frameworks like React and Vue and whatever. Or if you are just downloading raw HTML, there are sort of interesting hacky ways to sort of to pipe that through an independent document and stream that onto the page while keeping the SPA style context. Yeah, but as I say, especially if you've got like parts of the page like service worker cached, if you're replacing the whole page, each click, then you're not getting a ton of benefit from an SPA. And that's kind of like, this isn't, this isn't what I plan to talk about in this episode, but we're talking about it now. Like I have a sort of sadness with, with what a lot of the frameworks do, like next JS, where there's this pattern of like, they have a, an HTML render, a static render or a server render, which is great, but then it lands and it re-renders the whole page from a different data source. And that can usually be like a heap of main thread activity and additional bandwidth that ends up doing absolutely nothing to the page. You know, so I was really excited when Nick JS had... 

DAN_SHAPPIR: You're talking about hydration, about the React hydration or whatever? 

JAKE_ARCHIBALD: Yeah, there's two problems with hydration. One is like what you serve as HTML shouldn't really be the same as what you then go on to enhance with a framework. And the other part of it is you shouldn't be enhancing with a framework what is just going to remain a static content anyway. So for instance, like if you've got buttons on a page that depend on JavaScript. If you've got an image carousel and you've got buttons to flip from slide to slide or whatever, those shouldn't be in your HTML because the user shouldn't see those when they don't have behavior attached to them. And again, then if you have an article worth of content, there's no point sending that down as data again, because that's just sending the browser the same thing twice. So something's gone wrong there. Like that's just a waste of data.

DAN_SHAPPIR: I totally agree with everything you're saying. I think that in a lot of ways with modern frameworks, we've kind of painted ourselves into a corner. And now we are introducing a lot of, you know, amazing technical innovations that are just designed to somehow get us out of the corner, which potentially we should have been in to begin with. 

JAKE_ARCHIBALD: Yeah, I mean, so I played around with the build system on my blog a bit, because you know, your own blog is a good excuse to play around with stuff. And it's built using Preact, because I like the developer tooling of Preact and React. I like the structure of it. 

DAN_SHAPPIR: And because it's sun-biler is amazing. 

JAKE_ARCHIBALD: Yes, yes. It is absolutely incredible code. It's incredible what they've got. But I don't often use Preact on the client on my site, but I do sometimes. And in the cases where I do, it's in like Little Islands. I wrote an article about AVIS image compression. And I have like parts of the page or interactive where you toggle between the different image compressions, which sounds like, you know, why do you need a framework for that? Well, in this case to make AVIF work, I was actually using a WASM decoder, which had parts of which I stole from Squoosh, which is an image compression web app that I'm part of the team that works on that. So that's written in Preact already. So it's easy just to pull the parts out of that. But yeah, so I've got this long article and then these little bits. It's all rendered using Preact, but then these little bits of interactivity, which are also Preact. But the hydration is just done on those little islands of interactivity. So it doesn't re-render the whole page again, it just picks up those little blocks. Where it would get more complicated is if I did want the whole page to be controlled by Preact on the client side after that. And I think that's when you run into the problem of you have to send down the whole representation of the page in another data format other than HTML, like usually JSON. Yeah, but again, like on a blog, you don't really need to do that. 

DAN_SHAPPIR: It's interesting because it seems to me that thanks to services or platforms like Next and Knox for View, et cetera, we've kind of started using modern JavaScript frameworks in the same way that we used to use PHP and JSP and ASP in the past as a means of generating HTML on the server side. And then if we need some functionality, then we just throw in hydration. But as you pointed out, it's all too easy to get to a point where you're hydrating the entire page, which can be really expensive and mostly totally needless. 

JAKE_ARCHIBALD: Yeah. I wonder if we'll get to a model in like a next generation of frameworks where hydration can be shallow and deep. Like it can just hydrate the parts which need to become interactive. But then when the wider page needs to become interactive, it can then take the hit. It can take the CPU hit there, rehydrate that, and hook into all of the other little bits that have already been hydrated, like the little islands of interactivity, and then do something with the whole page. Maybe that will be possible in future. As I say, it's a sort of limitation of the tooling we have right now. But things like Squoosh, just thinking of doing that without something like Preact or React, like I wouldn't want to take that on anymore. I used to be quite anti-framework. And I think I was sort of in the bad old days when it did seem to cause more problems than it solved, especially around performance. But now I'm super happy with Preact, especially. But yeah, you can make fast stuff with React, and a lot of people do. 

DAN_SHAPPIR: And we've gone down a really deep rabbit hole, I think. 

JAKE_ARCHIBALD: We were going to talk about session history in the browser, I seem to remember. 

AJ_O’NEAL: So can I ask a question that might help us get back towards that. So you're talking about portals before we went down this rabbit hole. What is the security policy on portals and will that help us solve the login redirect problem where you have a login that completely disrupts and destroys your app because it redirects entirely away from the page and then entirely back to a fresh new page? 

JAKE_ARCHIBALD: Yeah, so there's an interesting feature of portals which is different to just the navigation transition thing is when you activate a portal, which by activation I mean taking the document inside the portal and making it the main document. That's going to change the URL bar, so the user knows they're on the new page and all that sort of thing, which is especially important if it's a different origin. But through a series of agreements between the two sites at an API level, the new page can take the previous page and put it as a portal on its page. What that means in practice is you can create this thing which looks like a modal dialogue on top of the previous page by just creating a portal to the previous page, putting it there in the background, blurring it or whatever, and then putting your own UI over the top. That would be your login window. At this point, the URL bar is showing that you're on the login site. The user can look at that and go, oh, yes, I can give my credentials to this login service because I know it's this login service. They enter in the details, and then it can hand back control of the page, back to the previous page, because it's got that portal. It can activate it again. So it's sending the user back to essentially the previous page, but now you can say, yes, I'm logged in. So you've gone between two origins in a way that is safe for the user, because they can see the URL bar changing, but it doesn't have that full breakage. It doesn't fully feel like you've broken the link with the site you're on, it kind of feels like one flowing experience. Yeah, that's certainly one of the things that we're trying to do. It's problematic when people use iframes for this sort of thing. I still, my bank seems to use iframes. Like if I do a purchase on one website, I sometimes end up with an iframe to my bank where I have to confirm details. And it's, it's super bad because it's like, I don't know if this is, this form is coming from my bank or not. It says it is. It has the logo, but that you can do that with images and CSS. The security boundary is really that URL bar telling you who you're interacting with. 

AJ_O’NEAL: Well, Stripe does it that way. But you can't do it this way with login applications because the cookies are considered third-party. So the thing in the iframe can't access local storage or cookies to know whether or not you're logged in. So you can't do it that way with any modern browser anymore. 

JAKE_ARCHIBALD: So this is one of the things that we're trying to solve with portals and pre-rendered because yes, if you have an iFrame and you've got like third-party cookie blocking or storage partitioning, that sort of thing. Yes, absolutely. 

AJ_O’NEAL: Safari, Brave, Chrome is holding off for a little bit because Google Ads, but eventually Chrome is going to have to upgrade to this as well. But I think every other modern browser and Brave, which is based on Chrome, all have that turned on by default nowadays. 

JAKE_ARCHIBALD: Yeah. One of the reasons we haven't picked it up yet is it's not specced, you know, and that's why the implementations between Safari and Firefox and Brave are not interoperable, right? Like, there's kind of sketches for things like request storage access, but there's no spec for like, you know, what happens with async storages in that respect, what happens with sync storages in that respect, what happens with storages that span across multiple documents such as shared workers and service workers. Yeah, I think it's the right move. And I work on the service worker spec, and I've been supporting that storage partitioning for years now. Because yes, Safari has had a type of that for years now. They've gone through many iterations of it. But yeah, it's something I want to support, because I think it is the right thing to do. So the interesting thing with prerender and portals is we do want it to have access to its own storage. But at a time that it is the main document. When it is in its own window, like, you know, well, a pre-render isn't visible. A portal is in a kind of shape like an iframe. We don't want it to have access to its own storage. And so managing that transition is something that we are still figuring out, but we want it to be interoperable, right? We are going to like, we don't want to just kind of like hand wave it. We want to ship it in a way that developers can understand by reading a document. Hopefully, other developers can write talks around it or simpler documents. But there'll be a spec there which is saying this is what browsers are actually supposed to do here. 

AJ_O’NEAL: So if you did that though, immediately people are going to abuse it. What they're going to do is they're going to blink to get ad tracking. So it's going to do full transparency, come in front, change the URL, blink for a millisecond, and then it's going to go away once it's done the ad tracking.

JAKE_ARCHIBALD: Absolutely. 

AJ_O’NEAL: And that's we prevent bad behavior if you enable nice behavior. 

JAKE_ARCHIBALD: So one of the the ways we would overcome that is Like I mean bear in mind that what you're talking about there is possible today, right? You can do that with navigations so it's not a new problem. 

AJ_O’NEAL: Well, you used to do it with iframes and pixel images and stuff like that. And you couldn't do that in a reasonable way today. I cannot overlay a page that's transparent in front of the current page without having any visual change, only have the URL change, and then have it change back in less time than the user would notice. I can't do that today. 

JAKE_ARCHIBALD: Yes, that's fair. 

AJ_O’NEAL: But if I'm using an antiquated browser like Chrome, I could use third-party cookies and an iframe. because of Google Maps. 

JAKE_ARCHIBALD: Oh, antiquated. Oh, is that where we're going with this? 

DAN_SHAPPIR: I'm enjoying this. 

JAKE_ARCHIBALD: Oh, it makes me sad.

AJ_O’NEAL: Are you on the Chrome team? 

JAKE_ARCHIBALD: Yes. 

AJ_O’NEAL: Oh, sorry, I didn't know that. I had no notes. 

JAKE_ARCHIBALD: Oh, I thought you were just being a douchebag. OK. You're just an accidental douchebag, fair enough. 

STEVE_EDWARDS: But we usually assume that to Jake. We usually assume that's what he's doing. So.

AJ_O’NEAL: Yeah, that's a safe assumption. It's a good assumption. But no, in this case, I literally, I did not get show notes for this. I came in here and I saw Jake Archibald and I am not, you're probably famous and I probably just don't know it. That's why I confused with NFL guy. 

DAN_SHAPPIR: If you've not seen Jake's 203 videos with Surma, you should probably drop everything and go watch them, like binge on them and then you'll know. 

AJ_O’NEAL: What will he call? 

JAKE_ARCHIBALD: HDB2 or 3. 

DAN_SHAPPIR: You'll find a whole bunch of them on YouTube. I'm a big fanboy of his. Because of those videos, amongst other things. Also because of the socks. 

AIMEE_KNIGHT: I'll have to add to that. I feel like I owe a lot to you from blog posts that you've written. I've learned a lot from them, so thank you. 

JACK: Oh, we're just trying to balance out the other guy now, right? 

AIMEE_KNIGHT: He's great though, but he's just just like very heads down. 

AJ_O’NEAL: So, no, I get what you're saying. I may have read some of your blog articles, just not recognize the name as well. I mean, but it's been a while since I was heavy into Chrome tools and stuff. Like several years ago, like more than five years ago, I used to watch a ton of videos like tech talks and Google, Google IO and all that. But I, I, Amy says heads down, zoned out, whatever you want to call it. 

JACK: Yeah. I would say, no, I mean, I, you know, I deserve sort of what you're saying. Cause I've, I've definitely been on the other side of that before. Like when I joined the Chrome team, like I I had a real being my bonnet about Safari. I mean, this is going back even before I joined Chrome. Cause like at the time when I found out that, well, not, not just Safari, like all browsers were like every click on a webpage was being delayed by at least 300 milliseconds. Like in case it was a double tap, like as a developer who wanted the web to win over native that made me so angry. So like, 

AJ_O’NEAL: Oh yeah, I agree with you. 

JACK: So when I, when I joined like Chrome, it was one of the first things that I pushed to get fixed. And it took Safari five years later to fix the same thing. And during that time, I was really angry about that. And that's when I was using a similar language to what you were using, right? But about Safari, because I was angry about that. I was angry about IndexDB. 

AJ_O’NEAL: Well, it was Internet Explorer, and then it was Safari, and then it was UC Browser on Android, which heaven knows why anybody still, I'd like Google, get yourself together. Get that out of there. Now it's good. 

DAN_SHAPPIR: Yeah. But if I may say, just to be fair, so I think a lot of the, let's call it the criticism that we heap on Apple for the state of Safari is warranted and justified. The fact that it's tied to operating system releases, the fact that you can't install an alternative engine, the fact that they're not willing to appear to be unwilling to invest resources in advancing it in certain ways, the fact that they appear to be opposed to progressive web apps and so on and so on and so forth. On the other hand, you can't deny the fact that if you look at any performance comparison table, for example, Safari is just so way ahead of any other browser on any other platform that it isn't even funny. 

JACK: It's not very fast on Windows, I would say. It doesn't do well on Windows. 

DAN_SHAPPIR: Yeah, but who uses Safari on Windows, really? I don't even use Safari on the Mac. 

JACK: Well, it doesn't exist on Windows anymore, is my point. Yeah, I think Safari did show the way with the JavaScript engine a bit. I know Chrome, we changed our direction with JavaScript after they were winning a lot of benchmarks. I would say, actually, with CSS animations, they tend to do quite well performance-wise as well. They're also quite buggy, but when you avoid the bugs, they are fast. But this, I mean, this is why we need multiple browsers, right? And I know like we get comments on our videos on the Chrome channel, quite a lot of like people saying, it's like, you know, I wish, you know, everyone just use Chromium. And it's like, no, like that's just not what I want at all. Cause it is this diversity that we have. And it's what they means we get innovations on the privacy side coming from Safari. Firefox brings a lot of standard strengths. Whenever I see a behavior that's different across multiple browsers, it tends to be Firefox, which is the one which is correct according to the spec. And they're pursuing the privacy thing well now as well. I guess Chrome has a focus on features and how can we compete with native. And it's great that this is happening. Yeah. So it's, it's, although I've, I've definitely been angry at the differences between browsers in the past, like both as a developer and as a, someone on the Chrome team, like I would be much sadder if it wasn't there. 

AJ_O’NEAL: So right, right now we only have two browser engines. I, well, I guess maybe technically three. 

JACK: I mean, not just, not, not just technically three, absolutely three, right? 

AJ_O’NEAL: Like we've got, well, there's KHDML, which is, which is Linux browsers, Safari Microsoft Edge, Google Chrome, Brave. Like that's the whole, that's 90% of browsers are K HTML. 

JACK: Or it depends if you count it as that anymore. I mean, it's, you know, you could say that we're all carbon, right? Like we're all the same, but I think we sort of branched at some point. You know what I mean? And I think the same is true of browser engine. 

DAN_SHAPPIR: Yeah. Blink versus Blink versus WebKit or whatever. Yeah. I mean, I don't think you can refer to Safari and chromium based browsers as being like quote unquote the same anymore. I think you definitely have Safari on one side and then you have Chrome with Edge and Brave and a couple of others on the other side. And you kind of sort of also have Firefox. 

AJ_O’NEAL: But they haven't been rewritten, right? Like the KHTML line from KHTML to WebKit and Safari. 

DAN_SHAPPIR: Oh, I think that's so, you know, Jake. Or have they Yeah, Jake can probably say a lot more about this. 

AJ_O’NEAL: Is Blink completely different from WebKit now? Has it been, is it like so different that you can say like, yeah, it's really different? 

JAKE_ARCHIBALD: Well, I mean, you were just telling me one was antiquated and one was modern. So like, you can't then tell me they're exactly the same. 

AJ_O’NEAL: Well, no, I mean, I understand they're sporks and I didn't mean to give the wrong impression that there's not like feature ads, but like, you can expect almost all browsers to render things in kind of the same historical way as opposed to like internet explorer used to be its own thing and it had a Complete different history that it preserved and all these bugs that it preserved on purpose and then you know eventually they dropped that and they did edge which is their own thing and then they realized like a as a team we just don't have the resource slash competency to make this a viable business model. We're gonna use I guess they're using blink 

JACK: Yes edges using chromium which is a link Yeah. 

DAN_SHAPPIR: AJ, look, Blink was released back in 2013. 

AJ_O’NEAL: That's what. Oh, gosh. That's a long time ago. Yeah, exactly. And then. OK, I'll shut up now. Time compression, man. I'm getting all. 

DAN_SHAPPIR: So just think about the fact that how many refactors and rewrites have happened since then. So even though originally, I guess, it was the same code, as far as I know, a lot of the rendering stuff has been completely rewritten, for example. 

JACK: But then you could have even. So Firefox also uses Skia, which is the 2D graphics library that Chromium uses. So it's difficult to say that there is one line that starts at Gecko and K HTML and goes upwards. There is shared code between the two. There's different code between the three. I think it's fair to say these days that there are three independent engines which is Gecko, Blink, and WebKit. There's definitely code sharing. Like, you know, multiple ones will use SFMPEG for a lot of video work, you see here for the drawing, but they have like separate JavaScript engines. Like there will be code that's similar still between WebKit and Blink, but there's been so much that's being changed. Like I have to say that there's, you know, there's a good reason that developers complain about, so you know, Safari lacking these things and or your chrome lacking these other things and it's because those engines are different 

AJ_O’NEAL: Okay, so taking us back back up a step out of the rabbit hole. We were talking about Session stuff and then I dragged us into this Meyer so let's go back to that for a second and it turns out you are famous HTTP 203 big deal on the internet my apologies

JACK: No, I'm not saying it. This happened to me on Reddit, and it really wound me up. It was like there was an article I wrote, or it was an article someone else wrote. Anyway, someone in Reddit comments was being wrong on the internet, you know? And so I, you know, I was trying to avoid doing the work I shouldn't have been doing. So I kind of debated them on stuff. And they were arguing back and whatever. And then all of a sudden they went, oh, I didn't realize you were, you know, that Jake Archibald, I'm sorry, I wouldn't have said those things otherwise. I was like, I can I swear on this podcast? Let's just imagine. 

AJ_O’NEAL: We try to keep it family friendly. So we get the keep the good rating and iTunes and all that. 

JACK: Well, I thought some swearing. I was wearing and then I was like, it really, it really worked me up that it was that this guy was going to change his whole tact over a, over a sort of idea of who I was, like not what I was saying. And I don't know. I think there's a lot of hero worship in the industry. 

AJ_O’NEAL: Well, don't worry. I'm an equal opportunity offender. 

JACK: That's totally fair. That's how I like it. 

AJ_O’NEAL: But no, normally what happens is we have show notes that happen when the invite goes out. And I don't know if you even saw this go into your inbox, because we had some trouble with this slightly. But we have a show note request that goes out. And then like, we as a panel get that before the podcast starts so that we know we have a little bit of a background and we can do a little bit of Googling if we need to or whatever to bring up relevant topics or questions. And so that's what I was saying. I had no notes. That process failed. Anyway, we don't have to go into the podcast works. I know. 

JACK: Don't worry about that at all. Like I said, I would, you know, I would rather be not treated differently. You know what I mean? Like, I'm totally happy with that. 

AJ_O’NEAL: So anyway, the antiquated browser Chrome, you're talking about how the session works. 

JACK: Yeah, absolutely. Yeah, so the HTML spec, in terms of how history works, is bad. And it's bad because it was never written down properly in the first place. 

AJ_O’NEAL: And it's written in Pascal. 

JACK: And it's compiled in Pascal. Well, so one of the things that I guess is probably something that's come up in this podcast before is WebAssembly and WebAssembly and threads and SIMD. And like we introduced, I mean, you know, the whole specter meltdown thing happened and shared memory became a massive, massive problem for the web. And that's when we saw a lot of browsers rush for a stricter process model. But also things, you know, there were casualties along the way and shared array buffer was one of those things. Because that, you know, created a system where you could create a timer in a tight loop and you could essentially do the spectrum meltdown cache exploit and read things that were in the same memory. 

AJ_O’NEAL: So I'm still not entirely clear on that. When I first looked at it, it sounded like you could just get information like you could create some data. And if the data was in the CPU cache, then the operation would run quicker. And so you'd know that it was in the cache. And that was perhaps my very mistaken understanding of what happened with that. Is it, is it like you could actually cause it to retrieve the wrong data and give you back other data? 

JACK: So it's not entirely my area of expertise, which is a posh way of saying, I don't know, but it's very, it's. It's essentially a timing attack, as you say, of being able to determine things that are happening in the same process, which is a problem if your bank's websites and an evil website are running in the same process, which could be persuaded to happen. There were things like iframes, but even things like loading the source into a script tag, all of this sort of stuff. And so the solutions were twofold try and prevent things from other origins entering into the same process in a way that might be read, just through a series of Band-Aid solutions there. But the main one is this COOP and COEP declaration, which is where you say on your page, I am not going to include anything on this page that's from another origin without that other origin saying it's OK. And your methods of saying it's OK are cause and a cross origin and better policy or cross-origin and better policy is the way to say that affects your whole page. But there is another header for it. What website can come back and say, Hey, you can include this in your page, but you're not going to get access to the bytes. But really let the best solution we have there is cause. Once you make this declaration, the browser can ensure that that whole process is isolated. And that's when we give you back shared array buffer because your ability to do the late spectrum meltdown is much less likely to yield anything useful to you or that you don't already have full access to. 

DAN_SHAPPIR: I see. Interesting. I didn't know that these two were related in this way, but it definitely makes sense now that you explained it. 

JACK: So that sort of stuff was kind of just shoved into the HTML spec in a way that broke how session history worked. So yeah, the thing I'm noodling on right now is trying to boil the ocean a bit with the HTML spec to go and make the session history stuff make sense. And that paves the way for the shared array buffer stuff to make sense, but also means that we can spec things like portals, pre-render, in a way that makes sense, but also opens the door for a new history API that is actually useful to developers because the current one is not. 

 

Have you ever wondered if you could be offering a faster, less buggy experience for your customers? Let's face it, the only way you're going to know that is by actually running it on production. So go figure it out, right? You run it on production, but you need something plugged in so that you can find out where those issues are, where it's slowing down, where it's having bugs. You just, you need something like that there. And Ray Gun is awesome at this. They just added the performance monitoring, which is really slick and it works like a breeze. I just, I love it. I love it. It's like, it's like you get the ray gun and you zap the bugs. It's anyway, definitely go check it out. It's going to save you a ton of time, a ton of money, a ton of sanity. I mean, let's face it, grephing through logs is no fun and having people not able to tell you that it's too slow because they got sidetracked into Twitter is also not fun. So go check out ray gun. They are definitely going to help you out. There are thousands of customer centric customer focused software companies who use Raygun every day to deliver great experiences for their customers. And if you go to Raygun and use our link, you can get a 14 day free trial. So you can go check that out at javascriptjabber.com slash raygun. 

 

AJ_O’NEAL: So why can we not drop this stupid HTML living standard garbage and go back to something like HTML four strict, like let's have an HTML six strict where it's like, if you opt into this, you get awesome features, awesome security, awesome performance, and zero legacy. 

JACK: Yeah, I mean, well, that's what the Kubeco episode does. Like, it's a switch. This idea of, like, could we just start again? Oh, there are so many teams at Chrome, and I know it's been looked at in Mozilla as well, that have gone about that. And they come away going, like, you'll disrupt the whole industry in a way that people are going to have to learn this whole new thing. And it's all doable with extra additions that don't mean people have to relearn everything. 

DAN_SHAPPIR: AJ, just think about the fact how often images on websites are delivered from a different domain than the actual page. Now think about re-architecting all of that. I mean, it would be great to build an awesome new web, but would anybody actually be there? If all your content, if all your, look most of most users care about content. They don't care about how the web works. And if you're going to create this wonderful walled garden that has absolutely nothing interesting inside of it, you know, who would go there? 

AJ_O’NEAL: Well, I'll tell you who everybody who wants the latest features. Like we already tried this with JavaScript. 

DAN_SHAPPIR: JavaScript has certain features, but users don't want features uh, certain behaviors and content and for the web to behave in a way that, you know, 

AJ_O’NEAL: but users are the ones that have to deal with it. It would be developers. Like with JavaScript, we have, we have APIs that are only available when the security policies are met, including that there's HTTPS. So anybody that wanted to use a whole slew of new JavaScript features had to get HTTPS on their site. And guess what they did? They got HTTPS on their site. They figured it out. What I'm saying is, 

JAKE_ARCHIBALD: this is the system works. So what are we looking to change? 

AJ_O’NEAL: Well, I'm saying that you can, you can put up a walled garden and say, Hey, like the perfect opportunity to do this would have been with the video tag. Like anybody would have fixed their website to have the video tag. Anybody. Right. So you have a bunch of like brackets that don't close. You've got invalid HTML and you've got bad Juju, Magumbo, whatever in there.

JACK: Invalidation isn't a problem, right? No one's having a bad experience on the website because there's a lack of a self-closing tag on an image, right? This is the mistake that XHTML2 made. It went for the strictness thing. It was a huge problem for developers. It excluded a large section of developer community who... 

AJ_O’NEAL: Well, if I don't put a closing bracket in my JavaScript, if I leave my function open at the end closing curly brace, like no one cries over that. It's like, well, what the closing curly brace? Why can't I see it? Why can't these policies do that? 

JAKE_ARCHIBALD: If we turn the whole web to be like that, like there's a lot of web developers like who make good content on the web who don't write JavaScript, you know? And that's why we have things like, you know, CSS. Like CSS is a way for, you know, they're styling a webpage. You don't need to know JavaScript to make it work. 

AJ_O’NEAL: If I don't think about closing bracket in CSS, it doesn't work.

JACK: Yes, it does. Yes, CSS has very, very strong error correction. Like it will recover that block and it will carry on to the next block. And this is how, like, one of the really powerful features of CSS is it's backwards and forwards compatibility through very well-defined error correction in the parsing algorithms. And it's something that JavaScript doesn't have and can't really have because it's a, you know, it's a programming language. So it has to error out when it reaches syntax that it doesn't understand. Like, and that's why Blake CSS is the overall simpler and much more high level. But through that, it can have these error corrections. 

AJ_O’NEAL: All right. Well, I guess I'm not admin out here. 

AIMEE_KNIGHT: Isn't that just like the nature of what the web was originally intended to do, that HTML has to know the context of what's around it, whereas others like a more traditional, like an actual programming language is context free? 

JAKE_ARCHIBALD: Yeah. I think you're right. Like it's...The thing about CSS is it assumes that if it picks up later, it might be okay. Like, you know, you might end up with a bit of styling broken, but it, you know, your core content might still be accessible. And that's the same with HTML as well. Like, you know, it's got a lot of error correction built in, so it can pick up and figure out like, hopefully the right intent, and even if it's the, it assumes the wrong thing, then, you know, the content should still be accessible in many cases, whereas with JavaScript, yeah, if it's ambiguous where the loop starts and ends, then there's no way back from that. And that's the nature of those two different things. And I think it's fine to have both. 

AJ_O’NEAL: Well, anyway, my argument was just that if we did implement something where you had to actually be correct and unambiguous and intentionally do what you intended to do, then we could people would have to adopt it in order to get new features. So if they were new developers that wanted new features, we could structure things in a way that like all of this other stuff that gets mumbled jumbled. And I mean, we kind of did that with cores, right? Like we introduced the feature to be able to get, be able to read data across a website and we didn't break the old stuff. But if you had the new headers, then the new security policy applied and you couldn't use things the old way with the new security policy headers. We've done these progressive enhancements where we've let people opt in to breaking changes and it has worked and people do opt in to get the features they want. That was my thing, but I get what you're saying. It just makes me sad that the solution is, well, we'll just guess at what they want. If it doesn't look like expected, good luck for them debugging it. 

JACK: Well, no, because you can have both, right, debugging, we can point out the locations where the error correction kicked in. And so this is the problem that we faced with XHTML2 when that was a standard that was being built, which did have this feature slash bug where if you missed a closing paragraph tag, you would end up with nothing on your page. Now, obviously, that's a problem for streaming, but that's another matter. 

AJ_O’NEAL: But why would you back and forth, whether it's a space or whether it's an element block. 

JAKE_ARCHIBALD: Which browser would you use? The browser which displayed a red error message or the browser which displayed the news article? 

AJ_O’NEAL: It depends. 

JAKE_ARCHIBALD: Which is the better browser? 

AJ_O’NEAL: If I opted in and said... 

JAKE_ARCHIBALD: No, you're the user. Now I'm talking about the user here. You're the user and you just want to read the government guidance about COVID, right? Which browser is best? The one that displays the error message or the one that displays the important information about coronavirus. 

AJ_O’NEAL: I mean, well, obviously the one that displays the error message, it's got more accurate facts in it. 

JAKE_ARCHIBALD: So that you see what I'm saying, right? Like the error correction is good because it may be getting the wrong thing, but it may be showing a lot of the correct information to the user. And yes, the best of both worlds is where a validator will tell 

AJ_O’NEAL: If the developer ops in, then the developer would have deployed the site correctly in the first place. 

JAKE_ARCHIBALD: I, I come on. You don't have to be like that's, that's pretty naive, isn't it? Like we all know that sites end up on live, like through, you know, piecing together bits of server architecture, that sort of thing. Like there will be a version of your website served at some URL that you have never seen before.

AJ_O’NEAL: Why would a developer opt into something that they didn't want to use and that they weren't capable of deploying? 

JAKE_ARCHIBALD: Well, I'll tell you the answer, though, because it's what happened with XHTML2 is that no one opted in, because why would you? You don't get a benefit, you only get risk. So it's like... 

AJ_O’NEAL: Your site being exactly what you intended it to be. But anyway, sorry... 

JAKE_ARCHIBALD: No one intends their site to be an error message, because no one intends their site to be an error message, right? And that's what we're talking about the... 

AJ_O’NEAL: I do. If I did it wrong, I intend to get an error message if I do it wrong because I'm a programmer. 

JAKE_ARCHIBALD: You do as a developer, but you don't as a user. And if you can have a warning, but this is the whole progressive enhancement thing, right? No one expects their scripts to fail loading. No one expects them to hit an error in browser. No developer intends that to happen. But boy, does it happen. And you've got two choices there. You can either fail with the user seeing a blank screen, or you can fail with the user getting something. They might not get everything.

DAN_SHAPPIR: Yeah, the funny slash sad thing is that with modern frameworks like React, et cetera, very often when something breaks, you literally do get a blank screen. 

JAKE_ARCHIBALD: Yeah. If your script tag is your point of failure, which, and that's what I don't want to happen. Like, and it's kind of frustrating because like, so, because I always build in this progressive enhancement technique. I, an agency I worked at, we built this nice kind of JavaScript interactive site thing, but I did it with breast enhancement. And 11th hour, the client came back and said, we wanted to work on these BlackBerrys. And it was BlackBerrys that were using their proprietary browser engine at the time. Like they weren't using... 

AJ_O’NEAL: Should've used HTML. 

JAKE_ARCHIBALD: Well, I think it was WebKit they switched to in the end. But like, this browser, this old browser, it was bad at JavaScript. Like, it was like the stuff that it got right, it did slow. And my solution the problem, as I say, it was 11th hour. I just added a server side check. If the request is coming from this BlackBerry browser, don't run it. In fact, I think I did it client side. I think I wrapped the whole script in an if essentially. I think it did end up downloading the script anyway, but it didn't run it. The site worked and it worked fast. Even in a system where it hit the script and failed, I would say, well, it's not going to run it still be in a situation where the user was able to access the page on a browser that I didn't even know I had to design for. And that's the kind of beauty of this model. Like failing hard, it's like why, as a developer, it's great. And you want to have errors and you want to see where you've done things wrong. But if as a user, you're faced with like, you know, if you're not getting the information about coronavirus that you need and you're told, well, I'm sorry, but like the developer got something wrong. It's like, well, can I see the information anyway? Oh, yes, but we're not going to show it to you because the developer opts into a thing. It's not a model that worked with XHGMO2 for good reason, I think. 

STEVE_EDWARDS: Jake, I got to say real quick that you're giving me money with Python flashbacks when you started talking about nobody expects. And I started thinking about the Spanish Inquisition. 

DAN_SHAPPIR: But pulling us yet again if for the few minutes that we have left to the history API. So you mentioned that you had all this, all these things that, you know, were forced to change because of Spectre, because of other stuff. And it kind of broke browser history. Why and how? 

JAKE_ARCHIBALD: Uh, the spec was, is built on this idea of a browsing session being the top level thing, and that's where all the history lived. But in order to have the process isolation that we need to make shared array buffer safe, we have to switch the browser session around. So it was just sort of hand-waved in the spec that this would happen. But yeah, it's down to someone to actually go and fix it so it makes sense. And that's fallen to me. But there's more than that. There's just so much of how the back and forward button works in the browser that is just not written down. I'll give you an example. OK, so you've got a page and it's got an iframe on it, you navigate the iframe five times. And that actually creates, you've now got six session history items. Like you've got six clicks of the states that the back and forward button can be in because the back button and forward button affect iframes as well. Like one question is like, if the iframe is removed, what do you do? Actually, what do you think browsers do in that situation? Like we've got six history entries, but five of them are to do with an iframe that just vanished. What happens when the back button is clicked?

DAN_SHAPPIR: Ideally, those, well, ideally, that iframe should come back. But 

JAKE_ARCHIBALD: And that's a problem that's now a lot of the rest of the document changes. It's like, where do you put the iframe back, right? 

DAN_SHAPPIR: Yeah, well, look, from the user's perspective, when I click back, what I expect to happen is to essentially be presented with what I had before. That's my expectation as a user. So I would expect but yeah, once we start mucking about with the DOM using JavaScript, you know, all bets are off really. I mean, how can you realistically revert to a certain state in an application? 

JAKE_ARCHIBALD: Yeah, so this is a problem. So you end up with these history entries that don't really point anywhere. In Chrome, those history entries stick around, like, and you hit the back button and nothing happens five times. In Firefox, it actually removes those history items immediately. Well, so the back button kind of makes sense. Like you lose all of the history states that was associated with those iframes. There's some parts of the UI where it's not quite right, but I think the Firefox behavior is pretty good. Safari keeps all of those history entries around like Chrome, but if you click back, it reloads the whole page again. So you actually lose all the state you had because it's a modern browser, not an antiquated one like Chrome. But yeah, so we've got like even in these pretty basic interactions, all the browsers are doing something different because no one wrote it down. And in that case, I think Firefox has got the right answer. And that's like the one I think that we all want to converge on. And it's just like the more I look at like session histories of more of these weird behaviors spring up where because no one wrote it down, all of the browsers behave differently. And it's not always Firefox that's right. It's kind of different every time, which is fun. 

DAN_SHAPPIR: I'll tell you what I think of it. I think that on the one hand, the back and forward button, especially the back button, but also kind of the forward button, are an amazing thing and one of the things that are the, one of the best things about the web. The fact that you can click a link, go somewhere, and then just go back. And it's something that's wholly missing from most applications. It's gotten to the point where I'm using an application that's, for some reason, not inside the browser. I literally miss the fact that they don't have a back button. But that being said, the more applicative that the web becomes, the more difficult it is to provide a rational behavior to a back button. Because like you said, if I'm doing sort of micro changes within the page and I click back, you know, the naive expectation would be to undo those changes. And all of a sudden, if I as a user find myself in the previous page, or even worse, the previous site, well, that's totally not what I expected. So yeah, I think we're kind of starting to reach the point where, you know, there's a reason why most applications that are not inside the browser don't actually have a back button. And we're starting to get there. 

JACK: Yeah, and that's this is the problem with the current history API that we've got, right? It tells you that you've got history.length, and that is like whatever, 10. It's like, well, what does that mean? It means that there are 10 states that the back and forward button can take you to. But that might be on other origins. Some of those might not reload the document because things like push state, things like hash navigations, they create these new history entries. As a number, it's absolutely meaningless. If you call history.back, you don't know where it's going to take you. So this is why we need to fix this API. So there is a proposal for a new history API, which is much more focused onto the history entries that you created, that happened within your site, doesn't include what happened with iframes. You can attach state to these things. The length of these history states makes sense because it's states that you created, not states that some other website created. Developers have been complaining about the history API for years now but there is finally some movement on creating something better. 

DAN_SHAPPIR: But then what happens with existing History API? 

JAKE_ARCHIBALD: Well, I think it has to stay there, right? And the new thing is compatible. You don't have to switch into another mode. Things like history.back will continue to behave like history.back. History.length will continue to tell you a number that isn't useful to you, but it will still be there. It doesn't damage the new system. One of the problems with the current system is that if you call pushStates, which is your way of like adding something into the history state, like an arbitrary serializable JavaScript object that you can pick up later when you navigate back and forth, it will create this history entry that has this data associated with it, which is great because you can read that back and like if the page refreshes, you can pick that up and realize the state you need to be in. But if the user clicks a link on the page that takes you to like scrolls you down the document, which is a hash change navigation because the hash of the URL changes. That's added a new history entry that doesn't have that state you added on. So it's kind of like, well, you know, but I just wanted to scroll down the page. I didn't want to lose all of the state from beforehand. So it's things like that that mean that the current history API isn't usable. And this new one corrects because it doesn't lose your data on hash change, that kind of thing. And it gives you visibility into your other history states that are back and forward. Yeah, the history API was one of those bad APIs that was written by like just someone sat in a room thinking and never like really talk to developers about it and check that it actually works. The history API and app cache. They're in the, you know, they're on the naughty step. We've managed to kick out cache pretty much. 

DAN_SHAPPIR: And you just woke AJ up again. 

AJ_O’NEAL: Cash worked beautifully. Once the bugs were fixed, which was by the time it was about deprecated. 

JAKE_ARCHIBALD: Yeah, sorry. I, I, I, something broke up there. What, what did you say?

AJ_O’NEAL: I said appcached worked beautifully when the bugs were finally fixed, which it was about the time it was deprecated. 

JAKE_ARCHIBALD: I don't think that's true. 

AJ_O’NEAL: I don't want to go into it. I don't want to do relis on that road. I mean, if you want to go ahead. 

JAKE_ARCHIBALD: Well, kind of if you want. So like with appcache, like every URL, you know, you were put into a state where things cached as it went along, or you pre-cache stuff. But if you had like a different query string on the URL, it wouldn't hit that cache. There's a ton of security bugs because it doesn't differentiate between calls visible content and non-calls visible content. And that's- Say that one more time. So like when we cache content- 

AJ_O’NEAL: What are those words? 

JAKE_ARCHIBALD: So it doesn't differentiate between content that you have byte visibility into and content that you do not have byte visibility into. 

AJ_O’NEAL: Ah, okay, I understand. 

JAKE_ARCHIBALD: And there's a heap of security issues around that that we had to fix, usually by double caching everything, because we didn't know in advance whether you wanted it visible or not. So we had to do both. And so if you were in the mode where you were caching everything as you went along, all an attacker had to do is like. Hit some high large resources on your site with a lot of different query strings, and it explodes your cache and the browser has to remove it. Like it was it. Advocat is one of those systems where it could do one thing, but it was very rarely what anyone actually wanted.

AJ_O’NEAL: I think that would have been a nice middle ground between app cache and service workers, because service workers are too complicated for the average developer to understand or use correctly. And I think that there's just as many problems, if not more, with service workers. I mean, not necessarily on the security side, but on the usability side of like the cache is wrong, the cache is out of data, didn't update as expected. It keeps on reloading the homepage over and over again, without the updated changes, blah, blah, blah, blah. 

JAKE_ARCHIBALD: But it does exactly what you tell it to do. And a second ago, you were telling me that that was great. Like it should fail hard if you get something slightly wrong. But now I'm hearing that that's too complicated for people. But you know what? I agree with you. 

AJ_O’NEAL: The problem with caching is you can't correct the mistake. So when people tell it to load from the cache, I like things when they do exactly what you tell them to do. But what I'm saying is that it is too difficult for people to discern what they're able to do. It's not like a closing tag where it's like, oh, Oh, I put this div in the wrong place. Like, oh, no wonder it's showing down at the bottom of my page rather than underneath the content that it's supposed to be at or whatever. It's a different type of piece. 

JAKE_ARCHIBALD: But with simple service worker examples, it is obvious. It's when things get more complicated. And that's the same with documents. And that's why. And then I'm agreeing with you. Service worker is really complicated because it puts you in the middle of the browser fetch internals and says, you know, do what you want, but you need to know what you want. And you need to know how the things around it work. 

AJ_O’NEAL: Well, just like build tools. Like, so there's a, um, I'm working with some people, they've got an app that somebody else created. It's with create react app and it's got a bunch of service worker stuff. And like, basically I got to the point where I was like, look, let's just turn it off. Let's just figure out where that option is and disable it because, because nobody understood what it was doing and nobody that was there had worked on that. It was just like built in to create React app or something. And I may be misrepresenting it. I may be misrepresenting it. 

JAKE_ARCHIBALD: No, you're not. You're 100% right. Like the problem with create React app, and I was kind of disappointed with that that was done at all. Cause what create React app does is it gives you a boolean, which I think for a while was on by default or whatever, which is like make it work offline. And I was really disappointed that that happened because that was the thing I was fighting against with AppCache. I was like, that's what AppCache is trying to do. It's like list your files and we'll make it work offline. But there are loads of ways to make something work offline, on a resource by resource level in a site. And AppCache just gave you this one solution off the bat. It's like, we'll do this one way and if you want it slightly different, sorry. But then what React app did is it took Service Worker which is the thing I worked on to give people the power to do what they want. And it did the app cache being to it. Yeah, don't worry about it. But that's the thing. But no, but the create React app made an app cache of service worker and service worker is complicated. And it's like one of the things that I really believe in, in terms of the design of APIs is the extensible web manifesto, which is this idea that standards developers are not good at creating high level features without the guidance of web developers. IndexedDB. IndexedDB, I've got Stockholm syndrome with indexedDB these days. I actually sort of feel like if you put a Promise API on top of it, it's not as bad, but still, that whole thing. 

AJ_O’NEAL: Mozilla has forestDB where they just create local storage with indexedDB and it's like, works perfect. 

JAKE_ARCHIBALD: Yes, so I maintain a library called idbkeyfile which is just key value storage built on top of IDB. I maintain another library called IDB, which put promises on top of IDB. So it depends how complicated you want to go, which library you would pick. But yeah, the idea is that yeah, standards developers not good at creating high level things without the guidance of web developers. So what standards developers should do is build the low-level thing and then observe what developers do with it, the problems they have, the tooling that gets created around it, and then try and like, you know, what can we do better? Like how can we make that tooling better? How can we make that tooling faster? How can we make that tooling smaller? Like by taking parts of it and putting it in the browser. Like that's what we didn't do with AppCache. That's what we didn't do with the current history, the history API. So we didn't do with index DB. Like what we should have done with index DB is created a byte storage. Like here's a lot of bytes and we're going to persist those. We'll give you some kind of M map style access to them. Go build a database on top of it.

AJ_O’NEAL: Oh, you're talking C, like memory map? 

JAKE_ARCHIBALD: Yeah, sure. Like, yeah, you could just write these bytes and it would commit them to disk and you would have like some way of confirming that. And you could build, you know, SQL on top of it if you wanted. 

AJ_O’NEAL: Well, that's what they did with index DB anyway, right? I mean, all the Web SQL stuff is deprecated and then transitioned to like Web SQL JS or SQLite in the browser. 

JAKE_ARCHIBALD: Yeah, but the problem is it was just another high level thing, right? So if we had this byte storage, people could build low-level databases that are fine-tuned for one particular kind of storage. Or they could build something more complicated. And then as standards developers and browser developers, we should have been able to go and say, oh, people want this way of just storing essentially JSON data. We could make that multi-threaded and blah, blah, blah. So let's put that in the browser and take care of that use case in a way that doesn't need a massive library and could be faster. That's the way I think that feature development should work. Yes. Service worker was built with that in mind. 

DAN_SHAPPIR: And now we have people putting three megabytes inside local storage and, uh, 

AJ_O’NEAL: yeah, yeah, I mean, three megabytes, three megabytes. I mean, oh, you mean like in a single key value. 

DAN_SHAPPIR: Yeah. Yeah, exactly. And then reading those three megabytes back in a synchronous operation. 

AJ_O’NEAL: Hey, it's faster than iterating over it. 

JAKE_ARCHIBALD: Local storage is, is tricky because it's, it's that blocking. thing across processes. But yes. 

AJ_O’NEAL: But how often does that really get in the way? People always talk about blocking with local storage. Again, like I'm just, I have so little experience in the vast world of everything that could possibly ever be done. But like, I just, do people have a problem where it's like, oh man, reading from local storage better sit here for five minutes. It's like, blink. 

JAKE_ARCHIBALD: No, but it can become a bottleneck in the start of the page especially, because that's when we have to lift the stuff from disk kind of like on first access. And so if there is an early access before we can preempt that, and there's like so much code now that tries to preempt that because people do it, right? And there are race conditions with local storage across processes because it's a synchronous API, you know? So it's difficult to handle things like, you know, read a value, increment it by one, write it again, you know? These are things that- 

AJ_O’NEAL: Two browser tabs open at the same time? 

JAKE_ARCHIBALD: Yeah, which happens, you know? Absolutely. So this is something that IndexDB does solve that problem. But it created this whole database that looks like nothing anyone's ever seen before in order to do it. And even then it's got a transaction model, which could be granular, could be more granular than it is. It could be better if it was more granular, but because we were just sort of lumped with this high level thing straight away, like it, yeah, it's the best thing we've got. But I hope one day we do get just a raw byte storage. So...

DAN_SHAPPIR: Out of curiosity, are there any significant web applications out there that are actually using IndexedDB? 

JAKE_ARCHIBALD: That is a good question, actually. I know Google Docs does, but other than that... 

AJ_O’NEAL: It would, wouldn't it? 

JAKE_ARCHIBALD: Well, I mean, I think we might have had more skin in the WebSQL game, actually, back in the day, standards-wise, but whatever. Yeah, do you know what? I just don't know the answer to that. It's not something I've really looked at. I've not done a lot of work. I do maintain this index DB library for like the one, a few times that I ended up using index DB as a, as a developer in terms of sort of the broader usage of IDV. I not actually that knowledgeable. I don't know much about it. 

DAN_SHAPPIR: And now we will have the file system API in the browsers with Fugu. So maybe we won't even need it. 

JAKE_ARCHIBALD: Well, yeah. I mean, so again, like that's where you would need some kind of a decent database on top of it. But that means that when you go back- 

AJ_O’NEAL: I don't know if I want people that can't figure out how to use service workers access to Mmap. I don't know. 

JAKE_ARCHIBALD: Well, it'd be Mmap style, right? People have file system access already. When you create index DB stuff, it's creating a file in your browser profile, right? It's just very well controlled and managed so they can't just get access to everything else in the file system, right? So-It would be the same case here. It's nothing new, really. But I think developers should be given as much power as they can have in a way that's still safe for users. Because I think we see incredible innovation from developers, and I think we should support that. 

DAN_SHAPPIR: I think we can ramble on forever about all this stuff, but I think we definitely need to start wrapping up. So I just have this final question about the history API. So it's awesome that you're fixing it. 

JAKE_ARCHIBALD: Well, I'm not fixing. I'm a fan of it being fixed. It's Dominik Danikola who's doing most of the legwork. I'm just trying to fix the foundation part of the HTML spec to actually make this stuff possible. 

DAN_SHAPPIR: Okay, thank you for that clarification. 

JAKE_ARCHIBALD: I don't want to take credit for things that I'm not. 

DAN_SHAPPIR: So you're doing the easy stuff. Yeah, that's right. When, so the question then becomes, when do you think it might land. I mean, when will it make a difference? 

JAKE_ARCHIBALD: Right now it's in the design phase. Like we're looking for feedback from developers. So, you know, hopefully we'll be able to put a link in the show notes. But if you're a developer who's had trouble with history API before, or you know, do things with history state, it's worth taking a look at. Because, you know, we want to make sure that this is heading in the direction that's actually useful to you. It's difficult to put a timeline on these things because, you know, we would need cross browser agreement. I know Chrome does ship stuff, maybe hasn't been supported enough by other browsers. That makes me sad. I don't think that will happen with this history proposal. 

DAN_SHAPPIR: Has it actually happened? 

JAKE_ARCHIBALD: Bluetooth API doesn't have support, I think. 

DAN_SHAPPIR: Local phones? Yeah, that was a thing. Yeah. Will the history API finally have an add event list there? 

JAKE_ARCHIBALD: Lots of them is in the sketch right now. So there will be a way to intercept navigations that are happening so you don't have to add like click listeners to things and assume that a navigation would happen as a result. You can actually hook into the navigation. 

DAN_SHAPPIR: Oh, the way that I've seen is actually to intercept to replace the push state or whatever and then or pop state or stuff like that and get notified that way. 

JAKE_ARCHIBALD: Yes, there'll be an equivalent of pop state would actually make sense. It would be more about like that your current history entry has changed which is sort of what pop state should have been. But you'll have access to all of these history items as well that are back and forward to your current position. And they have events as well that they'll tell you when they're going away. Because if you have five history items, you go back four times, and then you create a new history item to be appended on, it clears the forward history. So events will tell you about that sort of forward state is going away as well. Yeah to make sure that developers will actually be able to track what is going on with their session history and they're not left guessing. 

DAN_SHAPPIR: Now that you're describing it, it'll probably end up being a history observer or something like that. 

JAKE_ARCHIBALD: Oh, we'll probably just use events. The state of when should something be an event, when should something be an observer is very complicated. Most of the observer patterns that we have on the web could probably have just been events. 

DAN_SHAPPIR: Amen to that.

AJ_O’NEAL: So I gotta get us wrapped up here. I hate to cut us off in the middle of an amazing discussion, but either we need to pause and let Amy do picks so we can cut her back in, or we need to wrap things up. 

DAN_SHAPPIR: I think that we should probably wrap things up. We've been rambling for a long time now. 

JAKE_ARCHIBALD: I enjoyed it. It's been a... 

DAN_SHAPPIR: Oh, I would love to have you on again and you know have another episode maybe about why you love Reduce so much or something like that. 

AJ_O’NEAL: Yeah I thoroughly enjoyed our banter and I apologize if I offended you for no no I'm not you're part of that I was like 

JAKE_ARCHIBALD: oh no no it's all I'm not I'm not easily offended oh sorry what maybe discussing where you get all the socks yeah I've got no I'm not easily offended and like I like a good debate. So no, I really enjoyed that. 

AJ_O’NEAL: Awesome. Well, let's go ahead and move on to picks. Well, first, actually, Jake, where do people get in touch with you? 

JAKE_ARCHIBALD: I'm JaffaTheCake on Twitter. My DMs are open, which is a risky move. 

AJ_O’NEAL: For those of us that don't have a posh accent, can you say that five times slower? 

JAKE_ARCHIBALD: Should I try it in an American accent? The username? Yeah, try with an American accent. Oh, god, this is going to be embarrassing. So my Twitter handle is JaffaTheCake. And my DMs are open, so you can message me on there. So it's Jaffa, as in J-A-F-F-A, and the, as in the, and cake, as in the food. So Jaffa the cake. If you search for Jake Archibald Twitter, you'll get there as well. 

AJ_O’NEAL: Oh, yeah, yeah, yeah. Well, we'll just have people do that, because I don't know. 

JAKE_ARCHIBALD: Unless you get an NFL player, in which case, ask him a ton of JavaScript questions. I'm sure he'll love that. 

AJ_O’NEAL: Yeah. NFL Chrome team, Jake Archibald. Got it. 

 

This episode is sponsored by Sentry. Sentry is the thing that I put into all of my apps. First thing I figured out how to deploy them. I get them up on the web and then I run Sentry on them. And the reason why is because I need to know what's going on in my app all the time. The other thing is, is that sometimes I miss stuff. I'll run things in development works on my machine. We've all been there. Right. And then it gets up into the cloud or up on a server and stuff happens, stuff breaks. I didn't configure it right. AWS credentials, something like that, right? And so I need to get the error reporting back. But the other thing is, and this is something that my users typically don't give me information on, is I need to know if it's performing well, right? I need to know if it's slowing down because I don't want them getting lost into the Twitterverse because my app isn't fast enough. So I put Sentry in, I get all of the information about what's going right and what's going wrong. And then I can go in and I can fix the issues right away. So if you have an app that's running slow, you have an app that's having errors, you have an app that you're just getting started with, go check it out, sentry.io slash four, that's F-O-R slash JavaScript, and use the code JSJABBER for three months of their base team plan. 

 

AJ_O’NEAL: Cool, so we'll go ahead and start off picks with Amy. Amy. 

AIMEE_KNIGHT: Sorry, I was trying to find the mute button. I'm going to pick something I saw in Hacker News yesterday that was actually really interesting. And I think as someone who my lifestyle now is substantially better than it was growing up, reading this was like a good reminder where some people still are and just relating to them. And it really brought back some not so great memories. But again, like, I never want to lose sight of like, what I learned growing up. Um, so like I would probably, I, you know, I usually make picks lightly, but this is actually kind of something that I really wish everyone would read. Um, because I just think a lot of people don't necessarily know what it's like. Um, but it's on the experience of being poor for people who aren't. So yeah, it just like talks about, like, this is like very poor, just like the stresses people go through of like, am I even going to be able to get to work tomorrow because of public transit or you know, is my car going to start and stuff like that? So I just thought that was really good. So I'll leave it at that. 

JAKE_ARCHIBALD: I'm really looking forward to reading that, actually. So I grew up on a council estate. I mean, you know, it's similar to you, like financially very secure now. But yeah, growing up wasn't. And it does surprise me how often, you know, people who clearly grew up quite rich have not no empathy for for it either way, because they just haven't really thought about it. So that's that's a really good thing.

AIMEE_KNIGHT: It's really good. I liked it and I just, I never want to lose sight of that. Like it's important to keep that with you. I think even, even if times are better. 

DAN_SHAPPIR: Yes. But as long as it doesn't get in your way. 

AIMEE_KNIGHT: Yes. Dan is my counselor. 

AJ_O’NEAL: And with that, we'll move on to Dan for picks because we need a nice transition from like the hardcore into the medium core. 

DAN_SHAPPIR: I don't know if that's like, okay, whatever. So a funny thing, so I have our middle son, he's really into mob movies. So whether it's The Godfather or Goodfellas or Casino, he really loved these movies. And because of that, we kept on telling him that he should watch The Sopranos because that show played before his time. And after badgering him about it for a long while, he finally said, okay, but, and then my wife started watching it with him and they both of them kind of dragged me into it as well. And it's just such an awesome show. It hasn't lost any flavor. It's some of the best TV ever. And I highly recommend it to anybody, even people who've seen it, certainly to people who have not. One of the best TV shows ever of all time. James Gandolfini is an amazing actor. And now in retrospect, you can really appreciate it. He's literally in every scene and he just carries the show. But there's so many amazing characters there. And so basically I just highly recommend watching The Sopranos all over again, or certainly if it's for the first time. And that will be my pick for today. 

AJ_O’NEAL: All right, with that, we will move over to Jake if you're ready. 

JAKE_ARCHIBALD: Oh, see, I was gonna pick a tech thing, but I've been really swung by the sort of, yeah, the less less tech choices that you two have made. So I'm going to follow suit. And it's going to be a TV recommendation as well. I recently watched It's a Sin, which is a Russell T. Davis show. And it's about gay people growing up in London at the time that HIV and AIDS became a thing. I find it fascinating because I mean, it was a kind of I was like, you know, too young or not even born at that sort of time. So it's a period of history I knew nothing about. And it's a fascinating show, but it's especially poignant now because of the parallels between what was happening then with AIDS and HIV and what is happening now with coronavirus. In the combination, in terms of that confusion around it, the misinformation, it sort of really echoed a lot of that stuff for me. But it's also just a wonderfully written and very funny TV series. So that's Ittison, especially T. Davis, whose name you would know if you watch things like Doctor Who. 

AJ_O’NEAL: That sounds interesting. I might check that one out. And then let's move on to Steve. 

STEVE_EDWARDS: Yes, since I have been dominating this conversation so much, I will try to make it quick. Actually got two picks today. One is one tech and one non-tech. First is a blog post, which is interesting for me in that, you know, I'm come into the front end world from the back end world. And so my skills with some of the CSS intricacies, like doing things like transitions and some of the fancier things, at least they're fancy to me are not quite as good as other skills. And so I came across a blog post by guy named Josh Kamo, C-O-M-E-A-U, not sure how to pronounce it, sorry if I mutilated, called an interactive guide to CSS transitions. I don't see a date on it, but it looks like it's fairly recent. But it's looked, it's a very, one of those things I've looked for that gives you a pretty good description in detail of the different parts of transitions, how they work, it's got pretty graphs and everything. So I will put a link to that in the show notes. And then secondly, sort of playing off part of our earlier conversation about, uh, the Spanish Inquisition, a la Monty Python. Uh, I got a couple of YouTube videos about the Spanish Inquisition part one and part two from the sketch. They're just classic, classic sketches. And one of those things that the way my brain works is anytime I'll hear a phrase, and if it's a partial phrase of some comedic line or something like that, that's the first thing my mind will go to is finding something funny. So anyway, a couple of YouTube videos, so I'll put those in the show notes as well. 

AJ_O’NEAL: All right, and then I will go ahead and do my laundry list here. So first I'm going to pick the non-authoritative information podcast, otherwise known as the HTTP two or three podcasts, not because I've listened to it because I only found out about it just now, but because from the titles in the list there, that is exactly the kind of thing that I would be listening as I'm walking a mile across campus to and from different classes. If I were still in college, I would be soaking that thing up from just from the titles. And from our conversation here with Jake, I imagine that it's exactly what I imagined that it's like, which would be really, really good. So I'm going to pick that not as, not as recompense for my bad behavior, but just because I actually think that it looks really awesome, very, very similar in style to the tech talks I used to, to listen to as I was watching back and forth between classes. Also, because we've been talking about all this like weird browser stuff, blast from the past. Mac OS in your browser. There's this guy that back when CSS three was the new hotness, created a replica of the Mac OS desktop experience in the browser. And it looks like it's, it's kind of broken now. It doesn't work entirely the same as it used to probably because of new security policies and stuff. Like opening up Safari doesn't open up an iframe that lets you use Google like it did when I first saw it. But anyway, that's just kind of a cool thing, just a technical marvel to look at. Amazing because like by today's standards, it's not that great, but this was, it was hot back in the day when, when that was hard to do. Then I'm also going to pick a video game, of course, worms WMD, which is available on lots of different platforms. Uh, worms games are just like stupid games. You're a little worm you're fighting against other worms. The turnstile takes forever for no particular reason, which is the most annoying thing about it. But it's just kind of fun when you wanna chill, relax and blow some stuff up with bazookas and sheep and concrete donkeys. So I'm gonna pick that, but I can't pick that without also picking Deku Deals and Play Asia. Deku Deals is where you go if you are a Nintendo fan and you wanna know when stuff's on sale so that you don't pay $30 and you only pay $5 instead, which is how I been getting new games, I just subscribe to a bunch of things on DekuDeals and I get an email and if the price is low enough, I'm like, okay, I'll go ahead and get that now. I wasn't going to get it, but maybe I will. Or I guess I was going to get it when it got low enough. And then Play Asia, which if you need to get the physical copies of games like the Final Fantasy 7 and 8 and 9 and all that and stuff like that, Play Asia, you can buy the Asian version which has English, English subtitles as well as English audio for pretty much every single game. But you can get like the legit physical copy of it when they're not available in the U S for whatever reason. And the last thing I'm going to pick on my long list today is a larynx and nimble. And very few people would have a use for this, but we use it at church. So this is a, it's a broadcast system based on our TMP and HLS, which is basically whenever you watch live broadcast, it's being broadcast in RTMP, real-time media protocol, and it's being consumed in your browser in HLS, which is HTTP live streaming. And so this pairing of Lyrics and Nimble makes it really easy for you to use just a cheap $200 iPhone off of eBay, a Zoom H1N recorder, and be able to broadcast meetings. So if you have something that is like that, whether it's a user group or a church thing or some other type of meeting situation and you're looking for a situation. I'm not going to say that the server setup is super simple because I haven't done it myself, but it's figure out a bowl and there's YouTube videos on how to do it, but the, the experience of somebody going in and hitting record every week is ridiculously simple. And so I got a link to one of the videos by the company that makes lyrics and nimble as well as a kit that I put together that has all the stuff. If you're the rare type of person that needs to do that sort of thing.And that is all. 

DAN_SHAPPIR: we wrap up, I have to really quickly mention two things. So first of all, because you brought up Jake's and Surma's 203, I have to shout out that episode on the timer that you did about creating a timer that just counts up. I mean, that episode, you know, I enjoyed it so much, I have to say. You know, like taking that such a simple, seemingly simple thing and showing how not how unsimple it is. That was just awesome for me and all the methods and so on. So that's one thing that I have to mention and the other for those of you who listen know that we have show notes associated with all the various episodes and usually what happens with episodes like this when is that we get this message telling us well you didn't fill in the title of the show notes, what's this episode about and I'm just dreading trying to to fill in the title and summary for this episode because I really don't know what we should say except that I really enjoyed it a whole lot. 

AJ_O’NEAL: Browser internals rampage. 

JAKE_ARCHIBALD: Yeah, I think that's a good title. I like that browser internals rampage or standards rampage. 

DAN_SHAPPIR: Anyway, Jake, it's been awesome having you on. Thank you for coming on. 

JAKE_ARCHIBALD: Yeah, thank you for inviting me. It's been a good one. 

DAN_SHAPPIR: And I think with that, AJ, you need to wrap us up, no? 

AJ_O’NEAL: Oh, yeah. Yeah. Thank you very much for coming. I thoroughly enjoyed the episode. I hope that our listeners will as well and would love to have you back to chat another time. And I think I am, I'm going to try to check out this timers episode at least that the Dan just mentioned and maybe some of the other stuff you've got like a hundred things that there's no way I can consume it all, but it looks amazing. Thank you so much for coming on the show. Good night, everybody. Adios. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C-A-C-H-E-F-L-Y dot com to learn more.