I'm so glad middle clicking links was talked about here

I would recommend Rich Harris's recent presentation on the topic: "Have Single-Page Apps Ruined the Web?"

The mention of early AJAX reminds me of my experiments in the 1990s in creating objects on the fly as data islands (XML or SCRIPT tags) when I realized I could set a src field and then get an event when the value had arrived. I didn't do too much with the idea but it's a reminder that such mechanisms are part of the native DNA of asynchronous browsers. There was also Curl which Steve Ward and Tim Berners-Lee developed in an effort to shift from pages to apps.

Here after getting started with Astro. Crazy to see how they solved a lot of the concerns discussed in this perfect discussion. The passion for web and user experience in this talk was inspiring.

Answer: It depends

Good discussion, I don't have a lot of dev friends so it's nice to hear opinions in casual conversation. Thanks! Loved this.

This was a great discussion around the benefits and tradeoffs of both MPAs and SPAs. This will really help people in deciding which method to go with. Great video as always!

I'm glad it was mentioned about middle clicking. I use CTRL click a lot. Particularly on shopping sites to connoisseur products. It's soooo annoying when sites hijack the clicks (either for SPA or analytics). So my rule when building is: if the purpose of the page is to show something different, it should be is own page. If the page needs some content tweaks, then SPA Is OK but still not required. But ultimately I evaluate on a per page basis not per site.

I'm programming a microcontroller and i have almost no other choise but to build single page apps. I can't afford full page loads every time a user clicks on a button. I learned early in my carrier the dom manipulation and form capturing and handling everything with websockets with this tiny machines. I have 500kb of RAM ( which is a lot but not enough for full front end pages ) or less.

Typically I watch these at a desk so I can follow along with the code. Today of all days I needed to multi-task because short on time. So I was going to try and loosely watch while cleaning the kitchen. What a perfect episode to just listen to :)

I've also been hurt by KZfaq Music before. It's nice to hear a company have criticisms of their own products. Makes me believe there could be patches to fix these some day

I love these guys with what remains of my heart.

I think SPA is purely hype which was forced on developers who were already writing efficient front end. Earlier we used to do SSR using JSP which already had lazy loading, routing, etc now with SPA libs like reactjs we do the same but everything is done on the client-side. Now, knowing good HTML and JS does not matter anymore

I was hoping to not use my brain cells but take some dogmatic answer I found on the internet to bludgen folks with. I guess I have to resort to nuance and thoughtfulness. Thanks :P (Just kidding, great video).

The two yellowish lamps in the background look like a giant beast is watching you two converse from the shadows, eyes wide.

For me there are two different things involved. There is the idea of providing rich functionality on the page which may include server calls and there is the idea of emulating navigation. I would only call something an SPA when it emulates navigation. If you have only one page in your app, even if it has popups, it isn't really an SPA. An SPA is the technique of when you make it appear that you navigated to a new page (but you didn't). So a SPA may even have real navigation between sections of the site, but within some sections, be emulating navigation.

I've seen a pattern where people keep their landing pages as a static markup and on that have a link to their react app for I believe SEO reasons. Then on their react app, have a FAQ, Contact Us, About Us pages which are again static markup. I feel the merger of SPA and static is the best bet. SSR is a little too overhead-y even though I really enjoy using nextJS.

I try to find the happy medium while developing an SPA. I split each route into a separate JS chunk, with style sheets that are only applicable to the components that are currently rendered. So still no stream of HTML, but small bits of code to render at a time, so the wait time is much less, and the network payloads are small. Also, a custom hacky build step where I inject preload tags for immediately needed resources after the webpacker build has finished 😆

Yeah, I'm still a bit scared/lazy? to read that How to Win CORS article ... I doubt I'd have the mental buffer to click another article from there :D

The concept of “SPA” is using Js to manipulate the DOM (as opposed to adding event handlers) which is router (client or server side) agnostic “MPA” means static page (maybe with some user event handles by way of Js)

It sounds like AstroJS solves a lot of your concerns. You can start with MPA and then add framework islands only as needed. In the end, if you need a full SPA it wouldn't be a complete rewrite. I'd love to see a new video on specifics of these kinds of island architecture frameworks.

For me the choice is quite simple. If you have actual application, that has significant state, lot of user interactions etc, SPA is the way to go. If you have a data provider site, use MPA.

The boss of SVGOMG. I use that tool everyday!

I'm a little shocked that big-ad producer Google produced such a well rounded opinion piece. How on earth has the industry taken such a misstep when Googlers are aware of the drawbacks. One thing I'd like them to push is the ability for Google (or other browsers) including some approved, unmodified canonical libraries sites can reference, with some new attribute for identity; so that you can still use a url for fallback with simpler browsers (like lynx). I'm quite sure we have an some places use all the raw-ingredients for this.

Most single page apps that I've used are horrible and unnecessary. There's little to no value in doing it in most cases, you're just introducing bugs, security issues and wasting time re-inventing the wheel. Modern web development is toxic.

today if you're using SPA I think you should assume that everyone is using static pre-rendering. Not because everyone does this but because the cost of it is so low (aka, all the major frameworks make this exceptionally easy). Once you do this, i think SPA beats MPA in most use cases. Further, if tooling continues to improve, the cost of more advanced scenarios which allow for easy configuration of hydration and better adaptive presets, I think it'll be really hard to think of MPA as a viable option outside of extreme edge cases. And ... tooling always improves.

The fastest pages I’ve ever worked on have been server rendered with Ajax, because the technology was simple, small, light, and well understood by nearly every developer. When spas first became the new hotness, that all immediately changed and spas became the least performant Frankensteins on the internet. When you did them flawlessly you got a pretty good experience gain.. sometimes. When you did them bad however, they were worse in nearly every way in that, the site was never faster than mpa with Ajax, nor did they save you bandwidth. Ultimately I’m very glad that spas won out, because of how they modernized native app UI development is soo much better now

I came back from the shop with 4 high quality beers in backpack. I open the 1st beer and I start watching KZfaq ( which is my favorite tv ) when I opened 3rd beer I spot the HTTP 203 so I press play. The title of the episode make me think - shall I drink 1 beer during the episode - lets say is SPA == or shall I drink 2 beer of 4 ( I drunk 2 before HTTP 203) - let say is MPA. The same issue is with hosting domain for SEO - it easier to positioning 1 domain but for better User Experience many domain of the same app do the job. So the coclusion is that the MPA PWA rule especially with 2 beers in hands =) 20:13 "Tell you what great for a memory-leak situation" this event was design for memory leak so 20:29 "Just because you had an event list the wrong way" 20:30 "YEAH and a lof of the SPA frameworks have done a good like they solved those problems" For that reasoen I think that creating Your onw PWA that work offline - solve more global issue than memory leaks

We have to push Web Standards to have proper streaming support on the client-side. The things I really miss are: Portal\Teleport support (render at a desired location instead of where it came from server), better scroll management, native support for streaming elements (instead of hacks), frameworks that really embrace streaming and treat it as a first class citizen instead of an opt-in feature that noone uses.

I want to point out a old trick from me that solves the problem at the end before 10 years we got mpa's and we delivered the full page on every request then we listened on all links and prevented the default action we started a ajax request that grabs the new html then we simply used a simple regex to get only the relevant section of the html text. and finaly update the dom. the process was always fast and smoth. there are even wordpress addons that use the same method.

In my case, I used Gatsby for generating the static site, then removed all react/preact javascript with a plugin and inserted only the bits that were necessary in the specific page. Now my blog loads blazingly fast. Still, this is mostly useful if you don't have a very dynamic website, otherwise you really want the possibility to use the framework. It also requires a little bit more thinking every time you create a new component

Could you guys post these discussions on your podcast channels? The latest season hasn't been uploaded. Thanks! :)

It depends aand the borders are fuzzier than ever before: islands, interactivity on-demand, optimised preloading, SPAs w/ SSR, MPAs w/ SPA-like contents, etc

In some scenarios, when you can use websockets, javascript can be used to kinda stream response.

Also, MPA / SPA terms are really hard to explain to an outsider or a newcomer: How come that SPAs can have multiple pages? Can an MPA consist of only one landing page? Can MPAs make XHRs? Uh. Do you have any suggestions for better terminology? :)

It's all much about nothing really. Surma touched on it... "context". What is the purpose of your site/app? We should of learned enough by now to know what type of site works best for the type of problem its solving, the audiences it is aimed at etc... That is what should be driving those decisions.

SPA can be different. In your discussion you imply that an SPA means a framework. In my experience frameworks with accompanying indispensable tooling create more problems than solve and indeed add tremendous needless obscure complexity. Majority of developers make tools for companies, not for all the browsers in the world. When Chrome is an institutional tool and business needs are relentlessly changing, SPA is the fastest solution, whereas all the frameworks are sure waste of your otherwise free time.

I kind of come away from this discussion feeling like what we need to handle the cases where SPAs are used to compensate for some of the potential performance issues of MPAs is the ability to take the streaming content of a full page load and put it into a single node of an existing DOM, either through something like the fetch API or sort of an iFrame 2.0 that melds the parent and child DOMs.

I find it incredibly annoying, when articles change your navigation history, based on where you are on the page. Once in a while, I will open an article in the main tab, scroll through the whole article, then decide I it's not for me. Then what usually is one "thumb-button" press away, escalates into right-clicking the "go one page back" button, then identifying the point before entering the article. Depending on the article size, the last two steps might have to be repeated..

What I like about MPAs is that it's much easier to work in parallel on the code. SPAs are typically more intertwined through shared states and always require an additional build step whenever a component is updated, to compile the monolith. There are more integration issues since you're likely to work mostly without the context of the full SPA, which can cause things like clashing CSS. And then there's dependency hell, with different pages in the SPA being developed with different versions of the same package, causing all sorts of compatibility issues when compiled together.

Svelte? Seems like we should use Svelte :)

I fully agree with Surma about rehydration should be done from html and not fetch same data again. It's not probably even that hard. Storing metadata in data-attr - they may describe what kind of data it is, relations etc... and the values would be retrieved directly as node value. In cases where node value would not follow the shape of expect data, the data could be saved as data-attr aswell.

Excellent vid! Studio is great! But what are the two orange lights back there ?

This was a really interesting discussion. Thanks.

Too many cuts, why not keep just one camera and add more visual context. Still a great episode.

I feel like SPAs are not as bad as everyone is acting like they are. People have fast internet these days, I mean a react app can load in

The argument used against SPAs for blogs is that the content isn't streamed (mostly plain text) and the conclusion for MPAs is that we don't need the best perormance possible ? I agree with both but neither argument actually matters much to me and they seem paradoxical put this way. It really depends on apps to me. However loading an MPA with bloated javascript (what most MPAs do) seems counter productive. What SPA frameworks like next.js bring is a lot of best practices regarding performance like code splitting, image optimisations... doing that for an MPA requires handling that complexity so I really don't necessarily agree with the complexity factor. Like most of these sterile arguments, it all boils down to context: what app you are building and what developpers are building it you can find great examples of both and we definitly need to keep working on getting the best of both worlds. They are tools in our toolbox let's just try to use the right tool for each job.

Feels like we've gone backwards and now things are worse than when we were using tables and spacer gifs for layouts. Ugh.

The circular yellow lights behind you look like a giant monster's eyes

As for "betting on being open all the time" ... isn't it more about 1st page versus subsequent? You could even go as far as 1st time visitors and return visitors if you cache all assets with a service worker (which is pretty much zero cost). Generally the experience of 2nd page onwards (and to a lessor degree first page if assets are already cached) tends to be strongly in favor of SPA's. Obviously the tooling needs to ensure that basic blocking and tackling like JS caching with service workers is done and that async loading and parsing of JS is done in a smart way but again the SPA frameworks have made this quite easy. Overall I think the strongest trend here is that SPA's have tons of momentum and they are year after year, removing problems that historically had been issues while at the same time allowing developers to more fluidly move from front-to-back as well as reducing the surface area of technology that someone needs to master to get useful functionality to users.

Never mind all that chat, I want to hear more freestyle beatboxing!

W3C should set a standard for SPA. Right now (2023), we have a bunch of hacks, from pure JS to big frameworks, it's a mess. Put a tag in the header, *this page is a SPA,* let the browser deal with it. Programmers have more important things to do.

Awesome discussion

Could you use Service Worker to mitigate the problem of middle click / mobile closing the background tabs?

What about offline-first? Doesn't that paradigm lean heavily to the SPA camp?

I do think the thing that is missing is the context of what you are doing. If you are building a corporate tax app an mpa can be difficult. But a blog yeah maids fine. Trying to say one way or the other is so limiting

Like everything programming, it depends.

Not shure but I think VueJS is solving the Problem at 15:50 by compiling 3 Versions of the Render funtions: 1. One for Client navigation 2. One for SSR 3. One for Client hydration And on SSR only 3 is send to Client and executed. Only If you later need the full component 1 is loaded.

I actually think SPA is kind of bad user design for most times.. I wish we got back to MPA's more.

amazing!

Frameworks like NextJS deliver multiple pages on build as well as SSR, all the while keeping the magic of SPA routing. That's when I think SPAs would become a thing of the past for any mid/large size applications.

I think the crux is stateful -> SPA vs. stateless -> MPA

15:30 so vanilla js was the answer all along

TLDR; YES!

It depends 😀

"All the acronyms are bad" 💯

Just build a MPA and transform it into a progressive web application.Problem solved.

0:33 - yes, it should have been harmonized!!!!

I feel like they are trying hard to be impartial and admit that there are still valid use cases for MPAs but in this day and age most projects should be using SPAs.

Very interenting topic. These days I've been tempted to go back I write SSR dom :)

How do you know you need an SPA? You don't know. AAAAAND that's why we built an SPA. Congrats to google not being able to figure it out in 20 years

SPA's are bad because people use bloated frameworks for them. If done right, SPA's are faster, more reponsive and use up less bandwidth.

Answer NOOOOOO

25:41 mins spoiled

There's the kind of lame argument for SPA, which is you can trivialy have full applications with a static, edge caching server... but that's also tractable with MPA with sightly more smarts.

People are writing SPAs because they don’t want to write html & css. And that is the absolute truth. Programmers wanna program websites. I hate that it is like this but this is what happened. JavaScript eats up everything and it will eventually eat up the entirety of the platform. MPAs can’t win because developers wanna write just JavaScript. Universities are still not teaching html and css and now that you can everything in js or avoid writing css altogether thanks to buttbreeze, behindstorm, tailwind, there is also no reason to learn it. We’ve lost. JavaScript is eating everything up.

14:45 watch Surma describe QwikDev in just 35 seconds :)