Are SPAs better than MPAs? | HTTP 203
Вставка
- Опубліковано 18 жов 2021
- Surma and Jake have a discussion, weighing up the benefits and drawbacks between Single Page Apps (SPAs) and Multi Page Apps (MPAs).
Jason Miller’s article on “Island Architecture” → goo.gle/30zjX9P
More videos in the HTTP 203 series → goo.gle/HTTP203
Subscribe to Google Chrome Developers here → goo.gle/ChromeDevs
Also, if you enjoyed this, you might like the HTTP203 podcast → goo.gle/HTTP203Podcast
#HTTP203 #ChromeDeveloper #WebDev - Наука та технологія
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?"
Answer: It depends
Precisely.
Thanks for saving my traffic
wow, spoilers
The answer is 42.
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.
That is so cool. You were working out the basis of what would become async UX back when there was no manual, poor tooling, and minimal API capabilities.
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.
Good discussion, I don't have a lot of dev friends so it's nice to hear opinions in casual conversation. Thanks! Loved this.
Same
The two yellowish lamps in the background look like a giant beast is watching you two converse from the shadows, eyes wide.
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.
My front end can not rely on the backend to assemble the page for me. It would take ages. Instead in this situation, the backend relyes on the frontend and hopes that it can turn the data into a beautiful frontend :D
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
Knowing the basics of the technology doesn’t matter any more.
This is the problem today.
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!
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'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.
If you do your SPA the right way, middle-clicking a link should work exactly like on an MPA.
@@W4nn3 That's true. But I agree with the sentiment in the video that unless there is VERY good reason to make it an SPA, don't go to the trouble. Too many "gotchyas" and wheels that need reinvented.
I've also been hurt by UA-cam 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 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).
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.
What you are saying is that the term SPA should be used only if the same functionality can be implemented with a MPA.
So, for example, Google docs and spreadsheets are not SPAs, because you cannot implement those as MPAs.
@@hrgwea Yes. The terminology for page interactivity with the server was AJAX. The term SPA arose when people realized you could emulate navigation too and replace the whole page using AJAX and benefit by sharing code between all your pages without a reload. Of course there are hybrid approaches and gray areas but SPA is a specific application of page/server interactivity (AJAX) not equivalent to it. Google docs without multiuser editing/auto save could be done entirely with client side JavaScript and not use AJAX or be an SPA. I would only call it an SPA if you went from one document to another via what appears to be links but does not actually reload the page.
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 like that, I think React makes sense when building web apps and use static files when building web sites. No need to use React for web sites
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 😆
This was a really interesting discussion. Thanks.
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
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
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.
About memory leaks - I am sad to say that many of Google APIs are really bad on providing cleanup/destroy functionality and are real pain to use in large SPA-s. Hope it gets better in the future.
Can you tell me what you mean by “data provider site”?
@@jacobstamm I refer to web pages which primary goal is provide user with some data without (significant) interactivity with user. For example news, forums, most of company onepagers etc. In contrast to web applications that heavily relay on user interactivity, like Goolge Sheets, games, etc.
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
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)
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? :)
Could you guys post these discussions on your podcast channels? The latest season hasn't been uploaded. Thanks! :)
In some scenarios, when you can use websockets, javascript can be used to kinda stream response.
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.
Awesome discussion
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.
It depends, you still end up sending the library or framework down the line to hydrate the content... That is, when you have a 100% static page with little to no JS (maybe animations are carried 100% purely on CSS), the library or framework is going to be an overhead.
amazing!
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.
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
The boss of SVGOMG. I use that tool everyday!
Sammmmmee
I came back from the shop with 4 high quality beers in backpack. I open the 1st beer and I start watching UA-cam ( 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
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.
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.
Any recommendations to look at? I haven't really looked at ajax since 05? Thanks
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.
Excellent vid! Studio is great! But what are the two orange lights back there ?
Wifi antennas. We have bad reception in the basement.
The circular yellow lights behind you look like a giant monster's eyes
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.
Feels like we've gone backwards and now things are worse than when we were using tables and spacer gifs for layouts. Ugh.
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
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.
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 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..
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.
It would be cool, for sure. But I don't think you would save many bytes with it.
If you send the data as JSON along with the server rendered HTML, compression handles the duplication very well.
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.
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!
Could you use Service Worker to mitigate the problem of middle click / mobile closing the background tabs?
You can remove the network delay, but not the execution delay
TLDR; YES!
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.
It depends 😀
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.
Svelte? Seems like we should use Svelte :)
What about offline-first? Doesn't that paradigm lean heavily to the SPA camp?
Not always. The Chrome Dev Summit site is offline first, and it's an MPA.
Like everything programming, it depends.
Like everything in everything*
Too many cuts, why not keep just one camera and add more visual context. Still a great episode.
Totally agree
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
15:30 so vanilla js was the answer all along
I actually think SPA is kind of bad user design for most times.. I wish we got back to MPA's more.
I think the crux is stateful -> SPA vs. stateless -> MPA
MPAs can have state. Eg, almost every e-commerce site is an MPA and there's loads of state.
logins are state, server cookies were invented just for that reason
"All the acronyms are bad" 💯
0:33 - yes, it should have been harmonized!!!!
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.
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.
No because SPAs provide a much better framework for testing and development imho. It's like developing a native application.
Just build a MPA and transform it into a progressive web application.Problem solved.
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
Answer NOOOOOO
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.
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.
I was talking to a large publishing web site last month. They're an SPA, but they're moving to MPA. They're not getting any benefit from being an SPA, yet it's a maintenance burden for them, and a performance issue for users. Again, I develop both MPAs and SPAs so I'm not against either, but some of the worst web performance I see in the wild is from sites that are needlessly an SPA, presumably because the developer didn't know better and assumed everything should be SPA.
Very interenting topic. These days I've been tempted to go back I write SSR dom :)
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.
I'll also say the other even lamer argument for SPAs is that it's just so easy to just point Webpack at your src/index and slap a template html plugin in there.
I've also been playing with passing rollup nothing and using its HTML plugin (which is an entry point handler) with every html file in src and it's been pretty nice.
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.
No that is not true at all
14:45 watch Surma describe QwikDev in just 35 seconds :)