If you’ve been on the internet the past couple of weeks, you may have noticed a sudden spike in articles decrying Single Page Applications (SPA). The inciting incident was when Guillermo Rauch, the creator of Next.js and CEO of Vercel, tweeted:
As of this writing, that tweet has over 241 thousand views, which led to a firestorm of comments and blog articles.
Then a week later, on February 4th, Alex Russel published The Market for Lemons, which poured gasoline on the fire. In Alex’s excellent post he points out that the promise of SPAs and the frameworks used to build them have not been delivered. In fact, many folks are worse off due to the complexity that these frameworks opt you into and the staggering amount of JavaScript they require to recreate functionality already available in the browser.
Alex goes a bit too far when he assigns ill intent to the purveyors of these frameworks. He may be making the fundamental attribution error as none of us are immune to cognitive biases.
In response we have seen a plethora of blog posts like:
- The case for frameworks by Laurie Voss
- Why I'm not the biggest fan of Single Page Applications by Manuel Matuzović
- Rethinking the Modern Web by Oxford Harrison
- The (extremely) loud minority by Andy Bell
- What to expect from your framework by Johan Halse
- And many others…
However, questioning SPAs as the way to build web applications is not a new phenomenon. Almost a year ago, Nolan Lawson wrote two posts detailing why your next application may not need to be a SPA. Nolan is one of many who have questioned the veracity of building a SPA to solve every problem over the past 10 years.
Am I stupid for building a SPA?
No, of course not.
You are stupid for that one piece of clothing in the back of your closet that you couldn’t pull off even though you convinced yourself you could. Since you spent way too much money on it, you can’t bear to give it away or donate it. That’s called the sunk cost fallacy. Just get rid of it — you’ll feel better and have more room in your closet, but hey, I don’t know your life.
Neither do I know what constraints you are operating under. You might be great at building SPAs, or there are some technology choices at work that you need to live with…for now. Don’t let anyone make you feel bad for doing your best job. It’s exceedingly hard to keep on top of all the new developments in technology and the pace is only accelerating.
How did SPAs become popular?
A little over a decade ago, I worked on the open-source project Apache Cordova/Adobe PhoneGap, first at IBM and later at Adobe. Apache Cordova enables you to build mobile applications using HTML, CSS and JavaScript while targeting multiple platforms with one code base. In today’s technology landscape, mobile is dominated by iOS and Android. In the early 2010’s we were awash in mobile platforms from BlackBerry, Microsoft, Firefox, Tizen, etc. Targeting multiple platforms, including the web, from one codebase was a game changer for overworked development teams.
When targeting these mobile platforms, you would package your HTML, CSS and JavaScript into the binary downloaded from the various app stores. Then your application would only request data over the network. Since this hybrid application was running in a web view container on your phone, not a web browser, your files were loaded from disk and not served from a web server.
This architecture necessitated duplicating functionality provided by your web browser and web server. For example, browsers handle page navigation using anchor tags, while SPAs need a client-side router to hide and show your HTML views and don’t even get me started on back button behavior.
That was the exact best use case for the SPA architecture. The phones of a decade ago are not the multi-core behemoths they are today. Without the SPA architecture, your device would need to load, parse and execute the JavaScript on each page. On low-end Android phones, this led to a terrible user experience. With the SPA architecture, the JavaScript was only loaded once at startup, often behind a startup screen, to get around this performance hit.
The other key point about this approach is that a lot of the browser API’s we enjoy today didn’t exist back then, like geolocation, taking pictures and notifications. Without the hybrid approach, the web would have looked like a second-class citizen next to native applications.
So should I still build SPAs?
No, probably not, but that’s just my personal opinion.
Today’s modern multi-page applications (MPA) have access to way more capabilities than ever before, reducing the need to build a SPA to give you that native-like application feeling.
- Back/Forward caching makes navigating between pages of your application faster than ever.
- Offline support is possible with service-workers
- Web Components provide a reusable UI component layer
It’s time to clean out your closet
Not unlike that embarrassing hoodie, you know the one I’m talking about, it’s the one with all the holes and all those stains. It’s time to re-evaluate the tools and frameworks you use to build web applications. Do you need to use these frameworks that reproduce what the web platform already gives you? Maybe it’s time to transition away from them like that pair of jeans that hasn’t fit you since before COVID?
Where do we go from here?
Earlier, I mentioned that it is hard to keep on top of everything, and that’s why we’ve decided not to chase JavaScript frameworks anymore and instead focus on the web platform. You can read more about our approach in my post on Why we Server Side Render Web Components.
Slow is smooth.
Smooth is fast.US Navy SEALs
There are so many remarkable new approaches like Astro, Qwik, 11ty and Enhance built around HTML-first promise that leverages the platform. If you decide to try out Enhance, please let us know what you think, as we’d love the feedback. Follow us on Mastodon and join our Discord.
Top comments (24)
Nah... A lot of us have always hated single page apps (or more precisely the way they were abused to fit in every scenario even when they were not the right choice). But since it was all the craze these last few years, we just kept our heads down, ignored the hype, and kept building MPAs with SSR (or, as I lile to call them, "websites").
Technology always works in a cycle : Some company starts using a technology that fits one of their usecase, it becomes fashionable, everyone starts applying it to every imaginable usecase, and a few years later people realize it was not the right choice for them.
This is so true. Tech is like a pendulum swinging between two extremes.
I agree! SPAs are not the answer to every problem on the web, but I still think they have their place.
At my current company they hired me to specifically work with React and almost all projects I've built were behind a signIn page with no public routes... SPA worked fine here, specially because the backend architecture for each of them vary a lot.
However when approached to re-do their public website or a web commerce I had to be clear that this approach would never work welll for search engines without using something like NextJS.
Also, I don't see any problems when building Electron Apps with SPAs, since it comes from disk and not a http server it makes sense to have only one html entrance point.
Now micro frontends are becoming a common thing as well, so maybe the days of SPAs are counted, but I don't see them as just something to go out of fashion, just something that will be used where it makes more sense and not the first option to fit everything.
I agree with you. Use the right tool for the right job. There is still a place for SPAs. The Electron app is a great use case. They are built in much the same way Cordova apps were built.
SPAs just shouldn't be seen as a solution for every problem.
I'm the same scenario at work. We're building a tool for data vizualisation and asked oursevles if we should migrate our SPA to Next or something and honestly, I don't even see what URL would be linked to which part of the app… Really, our product is meant to be an SPA, just like say Google Sheets or Lightroom CC. There is zero navigation, lot of shared state and data pulled from the server from little part of the screen.
Now, I get why people got angry when the storm of "make your blog with React router" appeared. They reasoning was absurd: React jobs on complex Saas make tons of money, so you need to learn React, so let's todo-list and blogs with it. That was infuriating indeed.
Still, I agree with Rich Harris, the modern web has its place.
Sure SPA aren't for every need, a lot of things can be statically generated, ask for multipage, ask for SSR, hydration, resumability etc. you can mix all of that. But for a bigger SaaS products, where a single page is stand-alone app, they fit and will stick around for a long time.
I think the initial craze of SPA rolled forward with only 50% of the problems solved or accounted for. People were right to throw up their hands and call bullshit.
I have to imagine most of the pain has been accounted for now, and the area is more mature in general, and these days it's more of a branding issue.
It's a pretty common lifecycle in software.
SPAs are great and I literally see no reason to hate it. Why does everyone raises his/her voice when some famous/person with many followers say an opinion, and tries to make it like it's everyone's voice?
SSG have their place, SSR too and SPAs are great for many use-cases. You won't build a landing page as an SPA but you will choose SSG tools.
I know that it's very "trendy" when you hear Sveltekit, Nuxt, SolidStart, etc and they are awesome btw, but you can't say we should not build SPAs. Why it's wrong building an internal dashboard as an SPA?
Come on, those posts don't make sense.
I never said you shouldn't build a SPA. Instead, that next project you start probably doesn't need to be a SPA. This is a good time to re-evaluate all the great things the platform has added.
To answer you question, there's nothing wrong with building an internal dashboard as a SPA. That sounds like a great use case.
You literally said:
Also, saying:
How can you say that without knowing what the next project requirements are?
Yes, and the the key thing about both of those statements is the word "probably". I don't know the requirements of the next app or site you will build, so I can't say for sure not to build a SPA.
What I am saying is it doesn't necessarily need to be a SPA. The web platform has evolved mightly in the past 10 years and especially the past 5. We are at a good point to re-evaluate how we build for the web.
When I wrote this post, I was trying hard not to come off as anti-SPA. I fully believe in the right tool for the right job. I just don't don't believe that a SPA is the solution for everything. It seems like I failed at that so I thank you for your feedback and I'll try to improve going forward.
This post is a little misleading
How so?
Are SPA bad because of performance? UX? JS fatigue? architecture?
The problem is that a huge chunk of the Javascript community thinks too much in solutions for all scenarios. Like how redux was the ultimate answer to state management, so every project needed to use redux... until after a year people came to the conclusion that redux is overkill for a lot of projects, made it overly complicated and it was a bad decision after all.
Just don't blindly follow the hypes. Stop it!
I'm still working with Ember JS. Other developers tell me that's something of the past and absolutely horrible. Our project is having a very successful run for over ten years now, with many more successful years to come, so please tell me.
Yes, there are use cases for SPAs, just as there are scenarios where a SPA doesn't make any sense. In general anybody with an extreme opinion is dead wrong. Sorry Guillermo.
It depends on what you're building. If you're building a music player, such as Apple Music (for web), then a SPA makes sense because you want the music to keep playing even as you navigate other pages.
Yup, that's a good use case. I've always been a "right tool for the right job" kind of person, but if I wanted my music playing app to be more resilient, I'd look at splitting my page into iframes so the music player is never reloaded while the rest of the app can be a MPA.
When I first heard of the SPA concept, my 15 years of focusing on OOP was screaming no way! It was the exact opposite of OOP and SOLID to me. It was then I realized that maybe the Javascript world had not learned things 'the hard way'. The OOP concepts weren't dreamed up, they were years of learning based on fails.
Just like all newfound architecture, the OOP zealots appeared and seemed to have too much opinion on 'the correct implementation rules'. For a while entire software sections in stores and libraries had hundreds of books, perhaps even thousands of books.
OOP became disgustingly polluted with hundreds of patterns, opinions, theories all available in books. Alas the prices were extraordinarily expensive all because they were the new shiny "corvette" needed to win the race.
As all the hype wore off we saw the extraordinary rise of Javascript popularity. This time; however, most knew nothing about OOP concepts. They were experiencing the same thing the Pioneers of the 60's did. However Javascript was more loved as a scripting language than a prototype based object language.
By the 90's, expert scripters were able to demonstrate impressive things, saying 'We don't need no stinking OOP'. Our Monorepos and SPAs meet our needs. Everything worked well for the first 4 releases but then technical debt caught up.
Monorepos and SPA Apps became almost impossible to maintain. The beauty of dynamic properties and functions and objects became booby traps. People actually lost jobs because it took too long to become a SME on those apps. Changes and new function could not be done fast enough. It was like reading a book with no paragraphs.
Today the Javascript world has all the attributes of remaining strong. It's just that the adopters had to learn things "the hard way". In the meantime, Barnes and Noble's Software section has just 50 books on two shelves.
Maintaining frontend end project for longer periods with smaller team is painful. Most of the npm packages were deprecated. Choosing frontend frameworks like angular and vue is the worst mistake I have made in my 15 years of programming career. We were working too much in frontend for sake of updating the framework.
Most of the time rewriting everything again. It is stupidity to write code that does not benefit the people who use the project. We rewrote everything in dotnet and vanilla js. We are more productive than ever as a team. Frontend framework is one thing I would never recommend to anyone. It needs too much maintenance and it hurts productivity
That is exactly where we ended up as well. We stopped chasing frameworks and decided to use the platform as much as possible. I detailed that journey in dev.to/begin/why-we-server-side-re...
Going back to 'old school' where a data (form) submission required a full http page request, the concept of SPA makes sense, but any decent sized application is actually likely to be a collection of SPAs. The workflow for raising a repair request is going to be completely from one for creating a new product.
The rise of Next/Nuxt and the other meta-frameworks addresses much of the issue with the SPA concept removing large chunks of the boilerplate code (router!) and helping to separate API data requests from UX interaction.
If you go back to when we built internal applications using Access (if you were fortunate, or Excel if not) we still had to build out user screens, form data, lookups, client side validation and every freakin button click, tab navigation and keyboard shortcut by hand. How quickly we forget how bloody complicated it was to make sure no one was running ols copies of the application, or made a copy into an unauthorized location.
The new fad of "SPAs are evil" is just as stupid as the previous hype of "SPAs are the holy grail" - both are missing the point, which is "use the right tool for the job" ...
Of course SPAs still have their place, and so do the other approaches ... for many a use case building an SPA is the right thing to do, and for other use cases it isn't.
Couldn't agree more. I've always been a "right tool for the right job" person. There still is a place for SPAs, but I'm finding fewer use cases.