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). T...
For further actions, you may consider blocking this person and/or reporting abuse
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.
They've been a bad idea since Twitter and Facebook popularized the shebang URLs (see this complaint from 2011 github.com/browserstate/history.js... ) and like most things on the web, this was followed by a bunch of overengineering to get back to what HTML delivers out of the box.
I understand the offline benefits (although the manifest is a much better solution these days) but most js Frameworks make the same mistake as SOAP - they sit on top of the web, without taking advantage of it.
There's a difference between a website and a web app.
Anyone who uses a web-based mail client like Gmail is using a SPA basically.
Yes a single page app is going to be pretty silly for a company's marketing site. Once you have complex interactivity or reasons to keep areas of your site mounted as you do navigation, now you're in single page app territory.
But of course the CEO of Vercel is going to be very a biased to anything that is going to increase his corporate income. There is a reason why server-side rendering has become so popular in the NextJS ecosystem. Of course service side rendering is going to make far more profit than selling a CDN service. Even better, their answer to global performance is to put up a server for you in each region! Edge computing definitely has its applications and like any solution there are companies who will greatly benefit from it. But just like a single page app is way overkill for most marketing websites, Vercel's server-side rendering patterns for nextJS 13 are equally overkill for those similar websites.
Myself, I've been impressed by Astro lately. I'm actually working on a hybrid site that is mostly a statically generated site from Astro with some islands that take over the navigation and a small subset of the route providing a more app like experience in just a small area, which is often way more common for most projects that I see.
For example, I might build an app an Astro that is mainly static degenerated. Let's say it's an e-commerce app, so for the checkout process I want something that feels more interactive and flows like an app. So when in the /checkout/[...] I might drive something in like react router and have that section with animated elements.