Why does everyone suddenly hate Single Page Apps?

Feels fairly simple. A decent chunk of people always disliked SPAs, due to their very obvious disadvantages. Another chunk of people always liked them, either due to novelty or to their, again, fairly obvious advantages.

Depending on who you talk to or what online forums you frequent, you may have had an impression that the first group was far smaller (or larger) than the last group. Due to changes in the media you consume, or changes to the culture of various online forums, it may seem to you like the first group is now larger (or smaller!) than the second instead.

On the margin I suppose a few people who liked SPAs due to the novelty may have got bored with them, but most people, I think, have had pretty static views about SPAs, because the pros and cons are pretty obvious.

Yeah, okay, some prominent engineer tweeted something bad about SPAs last month and it went semi-viral, but prominent engineers have been tweeting and writing bad things about SPAs for the entire existence of SPAs. And more than a few of those have gone pretty viral.

Better question might be "How come I saw this tweet on my feed, but didn't notice all the earlier ones?", but I don't think that's super interesting.

The real answer to why everyone hates SPAs now is that there are well funded companies providing frameworks that are touting their SSR capabilities as a massive advantage, seeding the internet with content about how SPAs are the worst.

Something similar happened about a decade ago when everyone started loving SPAs.

SPAs didn’t become popular because of cell phones. In fact, outside of Facebook for a short period of time, there has been a strong consensus over the entire “everything must be a SPA” period that mobile apps should be native. Facebook, once it realized its mistake, tried to fit its massive “build once run anywhere” peg into a tiny “native for mobile, HTML5 for the web” hole through React Native, not SPAs.

SPAs have their place. Although I’m not a huge fan (though less of a hater now, thanks to the fact that at least the JS world has largely agreed that typing is good), I have a highly successful SPA that’s been used with almost no maintenance besides basic security upgrades for nearly 7 years now.

The reason is that we used a proper framework that fully supports building a SPA, EmberJS, but it could have been anything other than trying to cobble together a variety of react-* libraries thst only barely work together, and that our application actually was a heavily interactive user driven application with most of the stuff happening on the same page. There are only a few minor other pages (such as settings), so the application itself is largely a single page application, which is why a SPA fits it so well.

There is no sudden about it, SPA's are yet another one of the so-called "modern web" cancers of the Internet. They go completely against the protocols and architecture they run on and the only reason why they became so popular to begin with is because of all the hype from the big business, like so much else.

A web application or a website, by its very nature, is a series of small requests. When someone sends all requests in one big lump of a page, they have just defeated this very important architecture. Not to talk about the fact that they break searching on pages and a whole lot of other things.

I've built so many spa's in virtually every popular framework.

I'm over it. Even the simplest SPAs end up being way more effort than they are worth IMO. I'd write thin API layers and it seemed great.

Recently though. I moved to all backend with some jQuery. I render all the views on the backend and if they need to be swapped out I make a simple ajax call to pull the rerendered days and swap the div. It's like 2 lines of code for me.

Everything is so much faster, primarily because JS has so many gotchas. And so many times where you wonder "wait why isn't the data right here? Shouldn't this have blown up".

There is no appreciable difference to the user here but I can work in a backend lang and sparingly use JS and it's a pleasure.

SPAs certainly were not a "zero interest rate phenomenon".

It was early in the 2010s that I saw all the web design shops who made Ruby on Rails sites in my small town suddenly start building all their apps in Angular and struggling.

I'd ask them why they were doing this and it wasn't masochism, rather they believed that small town web clients demanded SPAs and that they couldn't sell user-friendly RoR apps that were affordable to develop.

Here here! Let me click around a site again with real a href links that change the browser url and are copy passable!

I've always hated them but it's good to see the tide turning. Slow (one of the first signs of an SPA - a page with its own custom loading indicator), requires JS to do things that otherwise needn't, and things like links don't work right. I do wonder if the otherwise superfluous --- and constantly changing --- JS requirement is part of the "weaponised change" approach of Google to furthering its control over the browser, since it's relatively trivial to create a browser that's usable on sites that need nothing more than HTML forms, but substantially more difficult to create one which will work with the simplest of SPAs.

I don't understand the premise, because I have always hated Single Page Apps.

Because like all fads with narrow applicability, idiots in big enterprise assume that All New Things Must Become the Only Way.

At $dayjob I regularly see "SPAs + microservices" getting deployed for static content that could have been literally just HTML, CSS, and JPG files.

I've seen a design recently for a trivial app that had two Kubernetes clusters in the architecture diagram. Two!

Not to mention that virtually all SPAs are infected by Node and NPM, directly or indirectly. JavaScript package management seemed "so easy" at first, and has slowly but inevitably morphed in a nightmare.

Minutes of CPU time was insufficient to disentangle the dependency graph of one particular Angular app in the effort to upgrade its packages. If hundreds of billions of machine instructions aren't up to the task, a squishy meat brain definitely isn't either.

Maybe SPAs are a great idea if they are your only product and are truly used to develop web applications that are constantly maintained. For corporate web sites they're idiotic beyond belief.

1) They are more fragile / have more bugs and don't get tested properly, because it is more work for most "applications"

2) They're slow to start

3) They usually lack a good UX (deeplinks, hijacking links, etc)

The ecosystem of web standards, browsers and search engines is mostly optimized with MPAs in mind. That's the base experience for web. Things have only gotten more complicated as we've built abstractions on top of MPAs.

In the earlier iterations, SPAs broke navigation, broke SEO, had no decent state management solution, and required a good understanding of reflow/repaint to avoid performance issues.

The ergonomics of SPA frameworks has improved drastically and metaframeworks like Next.js have mostly fixed those issues. But the myriad of options and paradigms might be exhausting for some devs.

Some experienced devs might be nostalgic for the document-centric PHP days. I imagine that many newer devs have only recently been exposed to the pleasure of building a simple MPA website, as they were initially thrust straight into React.

For example, I recently chose to use Hugo for my blog. Just wanted something dead simple to build a static website without all the bells and whistles of a SPA.

I like SPAs when they're actually used for applications.

I hate SPAs when they're used for crippled website functionality and slower load times than a normal server round trip.

The arc of web development is long, but it bends towards grug brain:

https://grugbrain.dev/#grug-on-front-end-development

It's not sudden, I've hated them since they've existed with only a handful of exceptions such as gmail. Most things on the web would be better without them.

As many folks mentioned already, the hate isn't new. Teams keep trying to use a one size fit all. Using SPAs for traditional websites was never a good idea, but people kept trying. SPAs tend to be pretty cheap and easy to build, especially if you cut corners, which makes them good to get an MVP out of the door quick (even if it's gonna suck). When trying to build "app like" products and given enough effort, they worked well and people made tons of money from them.

Now though, there's a couple of entities who benefit a lot ($$$) by telling people "Actually, this SPA thing sucks, look at OUR solution that will solve all your problems!". And they're VERY vocal about it (much more vocal than people who actually dislike SPAs).

A lot of trend setting in the tech industry is just from people ruffling feather or sowing confusion on purpose to then sell a solution. Right now we have a FEW of those, a bunch of people making money out of training you to solve the problem you didn't know you had, as well as a couple of Youtube "influencers" making money from the confusion.

Svelte creator Rich Harris gave a great middle-of-the-road talk about single page apps with examples a year ago: https://www.youtube.com/watch?v=860d8usGC0o

Then he released SvelteKit which has the best of both worlds: https://kit.svelte.dev/

Because you normally need to use a framework + the front-end ecosystem and it's hard (as in: not something you can improvise, you need to be good at it and have years of experience in it). Many developers on the back-end think that the website should be a thin veneer over a service. When they find out they can't just hack on it, but they need to learn React/npm/react-router/table virtualization/some component framework they get irritated because they've always seen front-end as a "lower" discipline for "worse" developers. That said, a well-written SPA is able to express a class of web-based applications that, if written well, are indistinguishable from normal web pages (with anchors etc) but can do much more things than a traditional server generated web page. Since native apps are essentially living in paid, closed, walled gardens, long live SPAs.

Love me a well built SPAs. Great tech. I certainly don't mind if others don't build them. So many people trying to advocate the "one true way" of tech instead of acknowledging that it really depends on the use case as which tools end up being superior.

I have been building SPA with SSR for years, if you truly know what you are doing they work very well. Yes there are some downsides to SPA's but the amount of friction is removed due to the speed of the app it does amazing things for business. We increases conversion rate and sales like crazy because of the experience of the website. It is true I had do some extra work to make it so fast, but dam the growth we had with the SPA was amazing. Know keep in mind that in our case it made sense because our users are buying 3000+ products in one session

Whenever this “SSR vs SPA” question comes up, I feel like it’s the wrong question to ask, because neither is ideal.

Server rendered or static sites make sense in some specific use cases (e.g docs, blogs), but even for those classic use cases they’re not ideal (e.g full page reloads every time).

On the other hand, SPAs make sense in some specific use cases (e.g Gmail) but even for those classic use cases they’re not ideal (e.g first render takes time).

I think we always need both server and client rendering, regardless of the use case, and the question we need to ask is how can we achieve this in an ergonomic way.

There’s some progress being made there (e.g Next.js) but I feel like it’s not quite there yet.

Imagine if this was reversed and mobile apps suddenly started switching to SSR. Instead of downloading the app once and making lightweight JSON requests (analogous to what SPAs are doing), they froze for seconds while the next page is rendered on the server while losing all of the local state that you had typed in. Sure would be a lot of hate for that when they have been working fine for a decade. You'd probably argue, that it sounds like that is just a bad implementation of SSR. Not all SSR is like that surely?

This is how silly this weekly SPA vs SSR debate is.

I hate everything that's mobile-first. And I prefer simple sites not bogged down by tons of JavaScript. Which is not so surprising considering this is my favorite website. In fact it's not so surprising to find a general desktop-centric view here at all, in my opinion.

I got to hate them when angularjs became the new version, which was nigh on impossible to upgrade from the original. They should have given it a different name.

Angularjs burned me so hard that i didn't even bother to look at react.

I’ve noticed that a lot of developers tend to hate things that they’ve tried building but they found it too hard. People enjoy doing things they’re good at and hate doing things they suck at.

There are a lot of SPAs that shouldn’t be SPAs, but that doensn’t mean all SPAs are bad. This isn’t your grandpa’s web browser anymore. We’ve moved on from the web being all about hyperlinked documents. The browser is also an app runtime, just like your smart phone.

If server-side rendering was the only good way to build web apps, then it stands to reason thay it’s the only good way to build phone apps with equivalent functionality. Maybe phone apps should also start re-rendering the entire UI on the server every time the user taps something.

It’s quite nice working on an SPA again after a few years working on a SSR site. Auth is simple, no sync issues between the client and the server, and never have to worry about caching

"Suddenly"? I don't know any users who liked them ever, and that has been a long time now. Designers and clients seemed to like them. Not users or developers.

To publish on social media or a blog, you need an angle/story, that will establish you as the expert.

To build, you just build.

The latter makes less noise online.

Q: why it matters? A: 90% SaaS product features you see is half baked, SPA's are the cure to the mess. Solving core problems requires rebirth of application but when ARR is big you can't go and rebase the code. Either you're born with it or your product will rebirth. (SAP's has it's own cons but the pros weighs more)

No one needs SSRs.

- The SEO argument is long dead.

- Client devices are sufficiently performant for anything you throw at it. Yes, even the $100 Chinese Android smartphones that taxi drivers in India use.

- The last argument I've heard is "I don't want to expose a JSON API to the world", but that's false security because scraping a web page is not difficult.

Why does everyone like skinny jeans and not bell bottoms? Light mode or dark mode? Fashion trends change. Cynically, there's also a measure of job security in chasing trends. Gotta keep up with the latest whizbang framework.

I'm not what we call in the Unix greybeard community a "webshitter" so I have no idea what this even is. What's an SPA?

The web has a huge anti- crowd all around it. People detest that there's this terrible awful wretched browser pretending like it can do code. Which is 98% gatekeeping sad-pants whiner-shit.

There's problems, but the amplification problem is uber for real, and most of the complaints just don't frigging matter; this is 98% a Bullshit Asymmetry problem: it takes vastly more energy to care about & refute troll-ish petty behavior than it takes to generate it. Positive behavior rarely gets amplified. There's an outsized representation for anger/negativity, as there almost always is, everywhere, forever.

Personally I think it's absurd to favor servers. AKA mainframes. Thick client web systems have a fundamental embrace of user-agency, in a way that thin-client systems are utterly unable to negotiate. It's cheap and easy to take digs on how bad things have been, and 100%, there's been a pretty poor developmental track record & much could & should be better in the client side universe. But it's still 100% better a RFC 8890 paradigm - The Internet Is For Users - than literally all the rest of computing, which has nothing for users & offers them diddly squat in terms of agency.

Alex's critique / pouring gas on the fire is wrong for a simple reason: we've been asleep at the wheel & embraced little change. URL routing, incremental loading, offline capability, & a host of interesting sprawling new web capabilities that could improve everything are still drastically unadopted. We have a lot of libraries for orthogonal concerns, but there have been essentially zero successful efforts in the last decade to define a system even as comprehensively cross-cutting as literally the first successful JavaScript framework was, Backbone. We have reduced scope since, and left orgs to cobble together orthogonal libraries, which has strengths, but makes it harder to adopt & leverage the high minded better potentials of what could happen. The web just hasn't evolved or advanced significantly, in spite of some churning iteration for how we all React.

SPAs are wonderful, but we've crashed against the limits of what we are willing to explore, and there's been a lack of way forward projected, and the upsurge in anti-SPA SSR is basically just an off-gassing, a pent up pressure to do anything other than what we've been up to, and while it has some virtue, I still ascribe most of it's interest to the fact that client-side systems have been at a standstill & real coherence & sensible integrative holistic imagining of how we might better do SPA's has been obviously absent for a while now.

GraphQL was some attempt to respin the front-end world but I think by now we know it's not really actually much different or better, but there's ideas captured there, where front-ends are not as hand-craft artisinally-made that we still are far from, and there's countless capabilities we should be tapping - like good Service Worker patterns, much more webworker and distributed computing ideas - that have made essentially no progress. At some point we need to upgrade & enhance what we expect of SPAs, but while the tooling has changed somewhat (React moving from classes, to HoC, to hooks, Redux to whatever), there's been little actual embrasure of real change, real web capabilities, that have been all about.

SPAs are still one of the greatest best option out there, even though their means-of-production are essentially unchanged for a decade & the hipsters are desperately hungry for cooler/bettter. Even though we've hit this kind of so so local maxima, there's just nothing anywhere as effective, and the whole SSR pitch may fit some roles, but for like 98% of systems, a SPA has a ton of advantages in being a more unified isolated independent thick client that just networks back to a bunch of dumb resources, which is a better/simpler & less overhead model - albeit one with some more loading cost - than the radically weirder & more complex models of splicing apart the baby & having part of the work happen one place & part of the work happen elsewhere. And none of that is good for the user anyways. I look forward to a new novel exciting future, but this is not the RFC 8890 way forwards. SPAs are kind of stuck, but still the best version of the web we have.

https://www.rfc-editor.org/rfc/rfc8890