 Right. So, excellent. Done. Thank you. Bye-bye. Subscribe. Twitter, it's a thing. It is. I've got lots of opinions, weak opinions, strongly held. We had recently quite lively discussion, many people participating, and it was MPA versus SPA. Nice touch. I should have harmonized. Because, you know, this is the second batch of filming, I don't have slides for this. I didn't have time to repair them. I was going to gloss over the fact that the reason we used to do discussion. We used to, yeah. People, it was mixed back. People didn't like when we were talking about code and not showing code. In retrospect, pretty obvious that that was a bad idea. But we're going to try and do one of the old school discussion episodes. Yeah, I thought we would have a nice discussion about this topic, because it is actually quite interesting. Because there's, well, I guess we should start by explaining what MPA and SPA is, because some might know, but some might not. So MPA stands for multi-page app. Yes. Which is basically, well, that's a name that's only come about since the invention of single-page apps, the SPAs. Spoiler alert. Okay, yeah. We could bleep that out, bleep people guessing. But like the first websites ever made on the first browser ever were multi-page apps. Let's not get into the discussion of apps versus sites. Yeah, that's a difficult one. But yeah, it's multiple pages, multiple HTML pages, linking to each other. That's an MPA. I would tend to call it the default on the web. But then, you know, stuff like, I guess, Ajax came along, the XML- Look, I was going to stop you right there, Mr. Simon. Look, at university, I remember, I made, I made a login form, right? And the way it works is it did a pop-up window, you fill in the details there, press the little button, and then the JavaScript in a thing reached back to the main page and edited the URL logged in as bit, and then it closed itself. And once I did that, I was like, because I thought I was going to have to reload the initial page. And once I thought, I don't have to do it. And I did that, and I like, in my head, invented it. There was no, there was, I mean, look, there was loads of people doing it. I mean, that's what you try to invent and nobody ever created you for it. Of course. It was one of those things of like, Oh, I can do this. And then later found out that that's what loads of people were doing. That's how a lot of these sites were operating. But that was pre-XML HTTP request. So like there were sites like that. So what basically is still a form, I guess? Yeah. And it's submitted. And then when the page reloaded inside the, I could have used a knife frame and saved myself the pop-up I realized later. Anyway, but yes, then Ajax came along, which is a term I still dislike. What does it stand for? Asynchronous. Okay. Which it doesn't have to be because you can do it synchronously. XML HTTP request can be synchronous. Shouldn't be bad. But yeah, sure. The X stands for, oh, the J is JavaScript, right? I hope it's not Java because that would be confusing. Yeah, correct. And then the A is and. It's and? I think so. You've got to be wondering now. And then an XML. So it's asynchronous, JavaScript and XML. Pretty sure that's what it is. That seems like someone came up with the acronym first. And I was like, what does it mean? There were people because like XML HTTP request can use XML. And HBD? And it doesn't have to. All of the acronyms are bad. But what they all mean, what that means, what Web2 meant and means, it does stuff on page change without navigation. And that's the big difference, right? On a multi-page app, if you want to change the content on the page, you go to a new page that has that content in there. In the single-page app paradigm, I guess, instead you load the data with fetch XML HTTP request and you put that data into the DOM that you already have instead of doing a full reload. And well, would you, do you have to do a fetch? Like, I think, could just generate whatever. Well, Scrooge would be an example of this, right? Like the Scrooge site we both work on, that's a single-page app. But there's the fetching. I mean, there's a lot of script fetched, but there's no content. It's actually interesting, because Scrooge is a single-page app, and it also really has only a single page. It has the landing page and the editor view, I guess. Sounds like two to me. But you never want to land on the editor page because it doesn't make sense by itself. Yeah, that's true. So, but I guess the, so that the SBA pattern is this whole, let's just re-manipulate the DOM, add things, remove things, instead of doing a full-page reload. And this has been, things have been built on topic. We have routing, client-side routing. There used to be a time where you used the anchor, like the hashtag, and then a pseudopath to actually emulate that it was a real site, even though it was not. And then JavaScript would pick it up and load the correct data and render it. Well, the reason we did that is because that was the only way that you could commit a navigation into the history stack without triggering a page reload. Oh, okay. Your fragment navigations were the only way of doing that. Okay. But yeah, so those, I guess, are the two paradigms, MPA and SBA. And then there was this huge discussion on Twitter about, I guess, which is better. Yeah. And I don't know, I find myself standing up for MPAs a lot. And I think people think I'm on team MPA. And maybe I am, but I would say, like, you know, Squoosh, S-B-G-O-M-G, things which I work on frequently, Prox, these are S-P-A's. Yeah. Unless we decide that having to fetch content is part of that definition. But I don't think it is. And then there's my blog, Thugling Report, and the CDS site when I was, the Chrome Dev Summit site, when I was doing that. And these are MPAs. Right. I mean, and actually personally, it usually drives me mad when I see a blog not being an MPA. So, and that was the question being raised on Twitter, was that, is that actually bad? The whole discussion was, what about S-P-A's everywhere? Particularly, if S-P-A's were perfect, are they always better than an MPA? Oh, that's an interesting question, though, isn't it? Like, for example, I think someone don't want to, you know, don't want to call them out too much, but my go-to example for bad S-P-A behavior, and I think the second thing that you taught me is GitHub. Oh, okay. Because you click a thing, and you see their own implemented progress bar loading, and it takes a while, and then you see the next view when you've done an experiment where actually loading the target URL in the window is faster. And do you know what? And through the art of editing, that video is going to be playing now. What you're seeing is this is genuinely me at Heathrow Airport, and I click a link on GitHub, and what it does is it does this S-P-A style, go and fetch everything, pops it on the page, and in the time it's doing that, I can open the link in the new window, and it's faster. And I guess it would be interesting to maybe come up with the downsides of S-P-A, because that is one of the main ones, is that you lose the content streaming. And that's the huge skill of the web, I feel like as a whole, as a streaming platform, that you can start showing content despite not everything having been downloaded fully yet. Yes. And that's, I think, my issue with blogs, because blogs inherently are usually a top to bottom consumed item. And so when the top loads, you can start reading while three pages down, it's still loading. That's fine. The user can already start loading. And so with an S-P-A approach, at least how it's usually implemented, you load the entire page, you load the JavaScript, JavaScript then goes off, fetches the content, and then loads the entire content, turns it into a DOM object, and then it pans it so you get one big reveal at the end. And there are hacks you can do, and they are very hacky right now in order to stream HTML into the page. But if you've got something that you can iterate over, like if it's a series of tweets, for example, you could use some format, like Newline Delimited, JSON, or something to bring those in in a similar way. This is solvable. Since we have, at least now, that readable stream and stuff is exposed on the fetch, you could literally try and go through the response and start putting it into DOM when they're ready to be put in the DOM. Yeah. And you can, there's a really, it's a very hacky piece of code that you can do. You can create a new document that isn't attached to an iframe, and you can actually call document.write in that with some text. And then inside that document object, which isn't being displayed, but it starts generating nodes, and then you can drag those nodes out into the page. Right. And you can stream HTML if you're willing to jump through the different behaviors that you get from that. Yeah. So maybe like, yeah, what other downsides of SPA do we have, and are they things that we can't fix or other things? I mean, all the classics, it does rely on JavaScript where, technically, you don't need JavaScript, right? It's a huge complexity leap. Yeah. So things like the history API. Very weird API. You suddenly have to drill down to get proper URL bar behavior. And back and forward to work. Yeah, absolutely. And there is a lot of stuff that that involves, which might not be obvious at first, things like form state. The browser does a lot of that itself. There is scroll position. If you've ever done major own SPA thing, you'll have encountered like, this is one of the things you have to fix because you're on one page, you SPA into a new page, you scroll down, you click back, you're still in that scroll position. But you need to reinvent that caching of the scroll position between views. But again, this is a solvable problem. And it's a problem that existing systems like, you know, your React Rooters and all those things have solved. But it's at a cost of code then, right? Like it's all code that needs to be sent to the client, which increase your payload, delays the actual activation point of that code because it needs to be loaded first because JavaScript itself doesn't stream. Like it needs to be fully there before it can start executing. Yes, I guess things like loading state, you need to reimplement that as well. But again, things that people have already done. So the argument I've heard from the other side on this is that you've got this big JavaScript bundle or you've got a JavaScript bundle that is formed of the code to repeat this stuff that the browser already does. But you load that once and you're done. And that's cached. And you navigate around 10, 20, 100 pages. You've still loaded that JavaScript once. On the flip side of that, you might have also on your page some other heavy scripts that are not in your control, such as a really bad ad script or like an analytic script, which is badly made. But for business reasons, you can't remove it. And again, like in a multi-page app, you are loading, you are pausing that. Hopefully not downloading it every time. Hopefully there's some caching going on there. But who knows? Things crossed. Yeah, you're definitely evaluating that JavaScript every time. I mean, that's what I mean. Like even measuring that behavior on sites that are already in cache is not necessarily the primary use. If you talk about blogs, then it's like I'm interested about people coming to a new blog post that I published. It's good if some stuff is cached because on my site before, maybe my header logo is cached or whatever stuff like that. But the content itself will still have to be downloaded. And if I stream something HTML, it will be on screen sooner than if I first load a page even from cache, JavaScript from cache, then fetch the content and pipe it in the documents. But then the SPA solutions that we see now, I think when we were having this argument 10 years ago, and I have blog posts from 10 years ago having this argument, the SPA systems at the time were not doing any server rendering. And there has been a mindset shift there because at the time, the people who were building the frameworks were telling me that I was wrong for saying that server rendering is much faster. That has shifted now. It's now pretty much universal that a server render or a static render markup in your page is the right thing to do as a first step. I mean, that would be my next question. Is it a dichotomy? Can you only be one or the other? Or can you do both or is there a way we can reap the benefits of both? Because I feel like that's kind of where... But it also depends on what both means. So what we see with Next.js and the similar systems is that the model of doing both is to deliver the markup for the page, but then also deliver the JavaScript for that same page. So basically you duplicate the content. Which is like... You end up with a lot of redundant execution recreating a page that's already there, but also redundant in terms of download. And so this is a problem, actually we faced with Squoosh recently and I don't even know if we landed the fix yet, but I inlined the Squoosh logo because one of our metrics was scoring us down because that logo wasn't appearing fast enough and it's right at the top. So I inlined it. But because we do follow that system where that view is delivered in HTML but it is also then delivered in JavaScript, that fairly complex SVG is now twice in the code. And it was... You know, SVG can get big. I was umming and aring about inlining it to start with, but now I'm inlining it twice. What I ended up doing, and this is horrible and hacky, was... Because it's a shared component, but the component said like, if I'm running on the client, just go and get this element. Get it from the DOM before you re-render. And get the inner HTML, the outer HTML for it or whatever. And so it was then only once in the markup, but then you're relying on sort of doing inner HTML tricks. That's what I always feel like is a solution I want for this whole hydration problem, I guess, where you send server rendered markup. But then you want to hydrate, make the leap to an SBA where now, let's say, Preact takes over. But once Preact boots up, it does this whole, I render the DOM and updates everything. And so that needs to have the same DOM markup in its own VDOM thing. And my... In ideal, it was like, okay, just grab the information from the HTML to grab the state and to grab the component. So you don't have to carry that in the JavaScript code. But that's actually quite hard. It is. And it would be interesting to see if we can get a system where you could say, like, well, a lot of this page is not interactive. It's never going to change. You know, can I just send the code for these little islands? Yes, I'm going to be controlling the whole page later on. Yeah. But it's only these like four buttons and this one button that have any interaction and any changes, any SBA style changes associated with them. But as you say, it's a hard problem. I think in terms of the discussion tends to get dominated by the two sides, and I guess one side of it is us, which are like, look, if the browser can do it, well, then just let the browser do it. It's going to be better at optimization, blah, blah, blah. But the other side of the discussion, I think it's dominated by the people who work for a desktop application that people leave open in a tab. And I think a lot of people bet on their site being one of those, like when they set out and it doesn't come true. Like, because thinking of the tabs that I have open all the time, it's Gmail calendar. Get notifications for me. Oh, get notifications as well for me. It's very few sites. And I think to sort of start off saying that, you know, I'm going to bet my performance on being one of those is tricky. And I think people maybe don't realize how often a page reload happens. One of the things like, oh, YouTube music, this is quite an app that is slow to load. And I'm sure they've made this bet that, hey, people are going to leave it open. Because look, I'm going to play your music. I've got to play your music. We can't change pages. But the amount of times that I have been listening to something and it'll say related artists are here. And I'm like, I'll open it in a new tab. I'll open it in a new tab. And do you know what? That doesn't work. The amount of time I ended up duplicating the tab and then clicking the link because it's not a link. Of course not. And so if you're betting on this one upfront load and then it happens again, people who middle click to open, if you're on the home page of a blog, a news site, you click all of those, you're hitting that full reload every time. And the other side of it is that the reason I said desktop is on mobile, that long lived thing just does not happen. No, the browser intervenes. The browser intervenes and closes the page. So when the user goes back to it, like, or even just back to that particular tab, it might have been evicted for memory reasons. And so you're going to hit that full page load again. And so betting your performance on being open all the time, I don't think is a safe bet to make. Yeah. Yeah, I still feel like browsers have a mode where they excel, and that's what I'm always trying to figure out when the apps are right. And I think it's the MPA. I don't know. I feel less than as confident. Like, I guess it's always like, it's not a single answer. Like the context matters. Yeah, I think the browser should do a better job of attacking this from both sides. Like, to provide the lower level primitives, or even like mid-level primitives for making SPAs better, one of these is going to be app history. Oh, yeah. Like, the history API is awful. Like, it's really badly designed. The app history API is essentially just, you may as well have called it history too, right? Like, it's just like, let's get this, let's do it properly this time. So, there's a better lower-level primitive. But then the mid-level ones, things like, caching scroll position, could we just have more, because there's loads of code for that in the browser. Why can't we just expose it more? But then I mean, that's another thing where some people feel pushed towards the SPA approach, because they want to have nicest transitions. Right. Like, have more control over how a navigation looks, because so far we've had no control for developers. And that's attacking it from the other side is like, what can we improve about MPAs to, some of the reasons people might go SPA, you know, taking on all of that complication, is it for some reason that we can just fix? Yeah. And the other part of that will be shared element transitions. Yeah. Of like, you know, can we do the nice swooshy-swooshy thing from page to page that, you know, some people do, like they go full react just to get that. And it's like, well, for those people, can we close the gap there? And that's not like, you know, trying to ban SPAs or anything, it's just like, if that is the only reason you're doing it, then we can fix that. It's a lot of complexity to take on state management and element, like code loading, turning it into a DOM element and doing the transition, which often involves all kinds of get bounding client-direct shenanigans. And we could just let the browser who already knows where everything is on screen. Yeah. And this is a bit of a, I don't know, we did an episode recently on memory leaks. Tell you what's great for a memory leak situation, reloading the page. Yeah. So if you're doing an SPA, you need to do, be doing so much better with your memory management. And as we've seen, like that's hard. It's hard. It can be very surprising when something leaks just because you had an event list and they're the wrong way. Yeah. And a lot of the, you know, the SPA frameworks have done a good, like they've solved those problems, hopefully. Maybe. You know, over time, they'll spoil a lot of stuff, but it's harder to stop the people building on top of that from creating those problems. Like the users of the framework, because it's that problem of like, you add an event list. So, well, the sort of stuff like, we're supposed to be good at this, right? And we saw the problems that we had on Squoosh. Oh, yeah. Right. And it's like, it's stuff that on the surface, you think, oh, yeah, that's like, a beginner mistake to do that. Of course that's going to leak. And it's like, yeah, but we did make the mistake because it's hard to spot when this happens. Yeah. Because you're going to put a retouch observer here and then suddenly that in combination. Oh, look, I'm taking no responsibility for that. That was a browser bug that we fixed now. I'm still going to blame you. But yeah, but I didn't even think to check that that was working or not. You know, it turns out that was broken in all browsers. So what is your bottom line? Dumb it down to one answer which is better. So I'm going to go home. If we could just wrap this up. I think it's what you suggested before. I think like rather boringly, there's no universal way. It depends. Yeah. And the idea of like, I know like my blog, I build it using Preact, but only to generate statically. You build it with React. You know, like you turn it into aesthetic markup, right? Yes. Yeah. So I'm using, I've got JSX components and the lot and it just generates HTML at the other side. But I do have areas like I kind of use this stupid markup trick. Like I don't know. I wouldn't recommend people doing it the way I did it because it was just hacky and I needed it for an article that kind of says this little bit here is this component. And so if you could make that live on the page and that works really well. I think that's something actually Jason wrote himself about about the islands of interactivity that is something that he thinks more frameworks should model around because it is just like you said, most pages are predominantly static. Yeah. And I'm not, I haven't optimized for the case. If I say in one of my blog posts, check out this other post. If you click that link, you're doing a full page navigation, which if you, if you build the perfect SPA would be quicker as an SPA. Like if you solve all the streaming issues. Yeah. But I don't see the need on my blog for that level of complexity because I mean, I don't think many people, but people are going to see a link to one of my blogs from Twitter or something. They're going to read that article. I don't have a high confidence. They're going to look at anything else. Yeah. Or even if they do, they might do what I do, middle click it, like read later. And also there is a difference between the fastest possible way to implement this and fast enough, right? Just because there is a way to do it fast that doesn't mean you need to do that or it's worth putting in this effort to save 10 more things. Or even if it's a significant amount, like if you're still, I always say like, we have these, the rail guidelines there, but potentially a bit outdated. But if you're hitting those, maybe you're just fine. Yeah. I do like fast as possible because it means on a lower end device, it might make the difference. But it needs to be at some reasonable complexity cost. And so even at a basic level on the Chrome Dev Summit website, in the designs, I don't know if a company is doing it. It's not me this year. But they made the error in their wireframes that we have seen the IO website make a ton of time, so it frustrates me. And that is when you click an event, it opens in a modal. So you've got your schedule, click the thing and there's the event. And that creates that problem where you're, even if you do the right thing and update the URL, you share that. The first thing the other user sees is... Not the modal. Yeah, it's the page underneath. And then a bit of JavaScript goes, wait a minute. Unless you really do add the complexity and render that page as a separate HTML site which actually has the modal baked into the markup. Well, what we're going to do, I think, is roughly that, but without the actual page behind it, the close button will then do your navigation back. But yeah, it's... You think about the amount of situations you're actually going to be faster for and are you really... Is that really going to happen? Does it warrant this jump in complexity? I think that's the question. Like if you have your metrics, if you're good, you should feel less incentive to do an SPA or an NPA switch. If there is things to optimize, think about whether that one of these switches could potentially help you hit your goals. Make a better user experience. Yeah, and it's great that all these sites are doing that static render now because we have seen in the past that sites have gone, or wait a minute, actually, if we just don't do the client side stuff, this is faster, and they're able to turn that off for individual pages where it makes sense. And then on a page that has more interactivity, bring the JavaScript back. It depends. Great. Get some flat Eric in here. Flat Eric, flat beat, Mr. Hoiso, flat beat.