SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.
Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolutely, if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.
But SPAs came about in the days of jQuery, not React. You'd have a complex app, and load up a giant pile of jQuery spaghetti, which would then treat each div of your app is its own little mini-app, with lots of small network requests keeping everything in sync. It solved a real problem, of not wanting to reload all that code every time a user on an old browser, with a slow connection, changed some data. jQuery made it feasible to do SPAs instead.
Later, React and other frameworks made it less spaghetti-like. And it really took off. Often, for sketchy reasons. But the strongest argument for SPAs remains using them as a solution to provide a single-load of a large code bundle, that can be cached, to provide minimal network traffic subsequent to the load when the expected session time of a user is long enough to be worth the trouble of the complexity of an SPA.
This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway.
What is the cause of this?
1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)?
2. Non-JS developers mystified and irritated at a bunch of practices they've never really internalised?
3. The undercurrent of "frontend is not real programming" prejudice that existed long before React etc al. and will continue to exist long after it?
I find myself agreeing with the article (although I also agree that it assumes you've chosen an SPA when you shouldn't have). To add my own perspective:
I work on an app, the front-end of which essentially consists of 6 nav tabs, 3 of which show an index of records with corresponding add/edit forms. We don't have any hyper-fancy interactive components that would require heavy JS libraries. And yet... we develop in React.
Yesterday, I needed to add 1 new field (representing by a checkbox input) to both our app and a corresponding back-end application we have, which uses Rails views.
I checked the git logs after to see how long each took. The Rails view took me literally 2 minutes to update (add field to model, add field to controller, add input to HAML with a class on the parent div). The React view took me 52 minutes, plus I later found out that I'd forgotten a damn type on some interface that's a shallow copy of our model.
Is this a problem with React itself? Not really. But it's a problem in the way that it's used, and our 6 nav tabs and 3 forms don't need all the overhead of React. So for people in a similar situation, this article really rings true.
> The React view took me 52 minutes, plus I later found out that I'd forgotten a damn type on some interface that's a shallow copy of our model.
This sounds like bad architecture, nothing about React would necessitate this. And if your typechecker isn't catching missing types, then it sounds like your types aren't adding much value.
Whenever someone presents an anecdote like this, there is always someone who says “but then you are doing react wrong”.
Ok, so why is it possible to do it so wrong so often then? That sounds like a downside of the tool. It is a sharp knife. That doesn’t mean there is no place for react, but it also doesn’t mean we have to wipe it under the rug and pretend like it is everybody else’s fault.
I never read a story about it taking an hour to add a field to a form in Rails and it only taking 2 minutes in react. I’ve experienced the other way around for years though. So there is some truth to it. Let’s embrace the truth and look for what react brings us despite this.
My objection is not that they are doing React wrong, it’s that their complaint is incoherent because there is literally nothing about React that could make this task take an hour. React isn’t a form library. You write the markup for an html input element, if it’s a controlled input you have a trivial one-line change event handler, and you have a submit event handler. Any additional complexity here isn’t coming from React, and managing to overcomplicate such a basic thing and misidentify the source of the complexity absolutely speaks to a skill issue.
This is especially funny in a thread where posters hold up Rails as a paragon of quality and efficiency.
IMHO it allows just the right amount of encapsulation and structure, whilst building on W3C web components and being highly interoperable with other javascript libraries/vanilla code. It's pretty much what web components should be out of the box.
People absolutely use technologies poorly and make things harder than they should be.
At the same time, the part of the program that interfaces with the physical world (e.g., people) is always going to be far more complex and thus harder than the bits that get to live entirely inside the computer world.
I'm sorry but that just sounds like a tooling and skill issue? Adding a new form field takes me a grand total of 5 minutes in the Vue app I maintain at work, and I'm a mostly backend focused fullstacker. We have the form/input components, adding a new field to a type is trivial (and we generate those automatically based on our BE schema anyway), error handling is handled by our form/input components.
Also, I'm not the biggest fan of React and think there are options that are a million times better like Vue & Svelte, but React is not heavy. Yes, JS frontends pull in a lot of libraries, but React (or any other framework except for probably Angular and Ember) is far from being the biggest or heaviest dependency in any project. In fact, especially React does this amazingly, React itself has 0 external dependencies. Usually people will also want react-dom, so for the simplest possible application, that's a grand total of 2 very lightweight dependencies, and for usecases like yours of a few forms, that's literally all you'd need.
Sure, maybe your 3 forms don't need React, but it sounds like you're actively adding stuff to it (and even caught a type issue from the sound of it). The non React version of this work would've entailed targeting a querySelector's inner `.value` key, and then having to parse it if it's not a simple string and safe guard against the element not being there, or targeting a shifting ID or class or all the other numerous and tedious problems that arise. Or, you stick a `v-model` on it, send it as JSON and call it a day, I categorically refuse to pretend the old universe pre-SPA frameworks was in any way a good way of working.
Just because you are comfortable with one technology and inexperienced or unfamiliar with another does not make one better than the other. How much rails have you written in your career? How much react?
I don't know that there's "real" programming, that seems like a hard fight to fight on either side, it's like arguing about whether animals are conscious or something. Are people? Who knows, pass the blunt.
But there's been this really sharp over-correction to where now an obvious thing that is just common knowledge and that was never taboo is now considered impolite to even allude to. Frontend programming is among the easier kinds of software work as measured by the number of people who can do it? I bet if I tried really hard, I could probably be pretty kickass at pickleball, small court, not a lot moving around. But to be like, that's the same thing as the NFL. No, no it's not. I would never have been able to try out for the NFL, not if I live a thousand times.
There's pickleball and pro football in programming too.
> as measured by the number of people who can do it
That’s a poor measure. It proves only that there’s a demand for such programming. I have programmed in tens of languages professionally and many more for fun.
Programming is programming. I haven’t found much difference in difficulty between any of the stacks I’ve worked with. Except, maybe C++, but that’s just C++ being garbage. I now happily use Zig as an alternative, and it’s no more difficult— easier in fact— than building a well-architected, complex UI application of any kind.
Front-end programming is easier in the sense that you can make little mistakes and your entire app doesn't fall down. As someone who's done decades of both, there's nothing conceptually easier about well-executed front-end programming over back-end. The stakes just aren't as high.
I think the argument might be that it takes less domain knowledge of hardware and all its abstractions, which does require a minimum threshold of reasoning and abstract thinking ability. I have high confidence someone who could built a database or kernel could also do front end work with a reasonable ramp up time.
I don’t share that confidence for the inverse in the nominal case
I have seen many backend developers with this mindset and approach, and;
1) Tricky parts of frontend are afaict equally tricky as building a DB/kernel/whatever.
2) A typical mistake is that a lack of knowledge about the hard parts of frontend makes backend'ers assume frontend is easy, while in reality it's their ignorance (and arrogance) rather than the subject being the issue
3) As with backend, most developers don't deal with the harder parts. Most backend developers I've talked to do simple CRUDing + minor business logic from a DB. Similarly very few developers try to write their own drag and drop library from scratch.
It's sad that so many seems to fall into the trap of 2).
(I've done both types of development for 20+ years)
I have no idea what backend developer means to this or that person. It seems to mean "not frontend", so like, directly interacting with a database and possibly using a compiled or even unmanaged language? But still often deploying through something that looks like:
Haswell <- Borg Hypervisor <- Borg Pod <- KVM Hypervisor <- QEMU guest <- docker-compose <- docker <- golang
?
I'm talking about hackers. I remember being like 24 and and a colleague of mine (legend) had never worked in JavaScript or really the web before was on our pod that got tasked with writing a browser for J2ME and BREW that implemented real web pages.
He goes home that weekend, and he comes back on Monday with a stack machine written in JavaScript (ECMA-262, we ran it on Rhino back then because Spidermonkey was a whole thing) that executed a very cute subset of JavaScript, including lambda closure and therefore Church encoding / untyped System 1. I was like whoa, why in JS? "If I have to implement it in a month, I'm already two months late to start learning it."
Is that guy a frontend developer? Backend? Full Stack? He had worked on DSPs and audio before, and on video codecs and embedded.
My comment above about some of this stuff is harder isn't a diss to anyone, it doesn't make me a millimeter shorter that Carmack is so tall, walking around in some rarefied air of genius I can't even formulate a picture of: it inspires me to work harder, try more ambitious things, push every day a little past yesterday's limit, and it has for more than 30 years now.
There's nothing wrong with programming be a job, it's a perfectly reasonable life choice and a very sensible one in light of life's other demands and opportunities. But some of us fucking love it, think about it all the time, live to be good at it. That's a different set of outcomes. And it does grate a bit to have everyone pushing this "it's all the same, we're all the same, it's one equivalent thing", that's my passion you're talking about, I take great pride in my life's singular ambition and pursuit. We're equal but we're not the same.
The backend has plenty of complexities, but frontend developers have to deal with something just as complex - the user.
Given ramp up time, most backend engineers could build a bad frontend, or build a good one if they have a really good UX team that thought through everything and are just implementing their work.
In the real world though where UX is understaffed and often focused on the wrong problems - I've had to rescue too many frontends built by backend focused teams to share your confidence.
It's also that you're at the top of the stack. If your stuff breaks, there's no layer above you whose stuff also breaks.
Well except the end user, but depending on the app they can often be low-priority (internal apps, apps with captive audiences like online banking or airline websites, etc.).
3. Weird writing and editing lapses in several posts
I am moderately confident this post was written with an AI. It may not be totally AI produced, I think the author has probably edited the work, but I think we are mostly debating synthetic content.
Most frontend development shouldn't be necessary as they're writing repetitive code that implements features that are missing from browsers. And it shouldn't be that hard to add those missing features to browsers. They're like half javascript at this point...
I started my career in FE and still consider myself a FE dev despite technically being a full stack dev.
Sometimes I'd be working with my team on something and they'd be like "why is this needed?" and I'm like "because javascript" or "because react."
While I agree with your sentiment that FE dev is certainly not simple, JS and front end architecture ad a whole does have its faults. That's why highly skilled FE devs who can build scalable, beautiful FE apps (whether using SPA or SSR) can be highly paid.
Note those are not mutually exclusive. It's entirely coherent to believe you find a tool hard to use for reasons relating to the tool itself, and that the task you're trying to accomplish is also difficult independently of that.
Analogy: imagine trying to give a good presentation with a horrible text-to-speech (or translation) system. Just because good presentations are hard that doesn't mean you don't get to complain about the program being terrible.
Yes, but now you're getting into "there are two types of languages, the ones people complain about and the ones nobody uses".
There are obviously flaws and issues and annoyances in js world, but a lot of those come from having to solve much harder problems (compared to say, do a sql query and turn the results into json).
I'll bite. In essence a user interface just presents the data it got from the server in some nice looking shape, and sends any edits and button presses back. Should be simple, right?
Think about the presenting data part of it. Perhaps you have a table of data, prices of tickets or some such. You could literally just wrap each item in a <td> tag and each row in a <tr> tag and that would indeed be easy.
But people generally want and expect more. How about color coding the rows to make them easier to scan left to right or sorting the table by each column or paginating through more data than can easily displayed on one screen or maybe you're doing "infinite scroll" instead.
None of these things are impossible of course, and people have done them so many times and in so many different ways that there are dozens of libraries you can use and hundreds of tutorials, but even so, compare that to the "select from table turn to json" equivalent.
The SQL can be more than a bit tricky, but aside from that, JSON is extremely well defined and specified, even without a library you can just read the specs and do it. Wrapping it in a HTTP response and returning it and so on is likewise very well specified and if you can read, you can follow the instructions on how to do it.
Creating a UI that works the way a user wants to is the opposite of all that.
Of course, one of the major differences here is that at any point you can just stop improving the UI. Maybe you stop after wrapping it in the table html. The UI will certainly work, for a very specific definition of work. JSON is considerably more boolean. It either is a valid JSON document or it isn't. You can ask a computer to check for you. You can't ask a computer to check if your users enjoy using your table.
I don’t know, I think reducing bundle sizes and bloated javascript in favor of built in support for view transitions warranted a blog post against one of the primary arguments for why SPA.
I agree with the author. I love React. I shouldn’t need two dozen more dependencies. We ditched server side for client side in 2010 for speed. Now that we have 200x more compute power, more powerful CSS, more robust html (with web components), we can go back to server side rendering and only send what’s required for the user at the time of action.
Are we aligned with the claims in the article that a SPA architecture is not a suitable baseline architecture for content-focused sites with shallow sessions (low number of interactions)?
You miss the whole point and the author is correct about this:
Modern CSS is powerful, and HTML is the way to deliver web content.
Every web framework is _literally_ a hack to make the web something it isn’t. People who haven’t seen the evolution often pick up the bad habits as best practice.
For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. And then once you realize that JavaScript sucks you’ll minimize it.
Laravel is fine. It's not amazing. Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system).
What I find interesting though is the assumption that web dev is done by "JavaScript people", that even the best "JavaScript people" have no technical breadth, and therefore fester in a cesspool of bad ideas, unlike your median backend dev who swims in the azure lakes of programming wisdom.
Now, I've done plenty of SPAs, but I've also done plenty of other things (distributed systems, WebVR apps, metaprogramming tools, DSLs, CLIs, STB software, mobile apps, a smidgeon of embedded and hobbyist PSOne games). Which gives me the benefit of a generalist perspective.
One thing I have observed is that in each silo, there are certain programmers who assume they are the only sane group in the industry. They aren't interested in what problems the other siloes are solving and they assume any solution "over there" they don't understand is bad / decadent / crazy.
These groups all regard each other with contempt, even though they are largely addressing similar fundamental issues in different guises.
It's a social dynamic as much as any technical one.
> One thing I have observed is that in each silo, there are certain programmers who assume they are the only sane group in the industry. They aren't interested in what problems the other siloes are solving and they assume any solution "over there" they don't understand is bad / decadent / crazy
A lot of coders have realized there's social credit in trashing other programmers. I regularly see comments from people claiming to have a singular custodial spirit for their craft, unrivaled by their peers. There's obviously advantages to telling people that everyone else is holding it wrong.
Then their advice is
- Some niche trick that's completely irrelevant to most situations
- Something that sounds obvious and uncontroversial, but is so broad and vague that it's not even worth arguing about.
And I realize the irony of me making this comment. But I wish we'd get over this phase where everyone thinks they're an expert, and that every bad codebase or slow app was the result of someone who didn't care. I have yet to work with someone who didn't care about their code.
> But I wish we'd get over this phase where everyone thinks they're an expert, and that every bad codebase or slow app was the result of someone who didn't care.
I can only speak to my own experience, but it’s been this way for the entire 18 years I’ve been doing this professionally and I can’t see it stopping anytime soon.
I just ignore it and write off people who openly think that way. It shows a lack of experience and empathy.
It’s connected with the questions around occupational licensing of programmers, unions, and similar structures which would not be so much about getting paid more but about getting quality up, squashing bullshit, and getting our quality of life up.
Without a cohesive community, mutual respect, and recognition of a shared body of knowledge, we don’t have the solidarity to make it happen.
As for Laravel, I’d say people were making complex applications (Ebay, Amazon, Yahoo) in 1999 —- Google Maps were better than Mapquest, which drew each image with a cgi-bin, but many SPA applications are form handling applications that could have been implemented with the IBM 360 and 3270 terminal.
The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw. You need two handfuls of helper functions, for instance
to make forms which can be populated based on what’s already in your database. People never wrote down “the 15 helper functions” because they were too busy writing frameworks like Laravel and Ruby-on-Rails that did 20x more than you really needed. So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built.
As for performance, web sites today really are bloated, it’s not just the ads and trackers, it’s shocking how big the <head/> of documents get when you are including three copies of the metadata. If you are just drawing a form and nothing else, it’s amazing how fast you can redraw the whole page —- if you are able to delete the junk, old school apps can be as fast as desktop apps on the LAN and still be snappy over mobile.
> The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw
Yes, I was there, I wrote and used these pages. It sucked. Things are better now.
> So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built.
Building a form with zero user affordances is not difficult. It just isn't good.
We absolutely know how the pyramids were built. You get a whole bunch of humans to move a very large amount of stone and then stack it up in a big pile. The reason nobody builds pyramids today is because we have better alternatives.
I've been in a happy place with React with some projects.
I've worked on some where it was valid choice but boy the annoyances, like not being able to test your components because you're on an old version of React where your test framework can never know when the last render happened because you depend on a large number of components which don't believe they'd run on the current react but probably would if you could just vendorize 30 or so packages and patch their package.json files.
Or depending on a test framework that refuses to look up components by class, id or selector because they want to force you to use aria, even when it doesn't make sense such as in three.js.
Or depending on a routing framework that doesn't get maintained, instead they've been through 7 incompatible versions of it which leaves me thinking that they didn't ever believe in what they were doing.
Or having to understand the internals of 5 CSS frameworks (including JS-heavy frameworks like Emotion) to handle all the components you've sucked in and still understand raw CSS through-and-through to fill the gaps.
I worked on one system which was frankly experimental at a startup that was doing two week sprints building a tool called "Themis" for building ML training sets. The thing was that we were always having to add new tasks and between Docker and an overengineered back end and front end it took 20 minutes to go from source code to being able to interact with the thing, so it took a 20 person team and lots of coordination between FE and BE engineers to do the simplest things.
I sketched out an alternative called "Nemesis" which grew into an HTMX-based system where it takes one programmer an hour to code a task and there is no build, and between Flask and the 15-or-so helpers it is easy. I've hacked it to be an RSS reader, an image sorter, and several other centaurs:
this feels like a desktop app when I am on the LAN and loads well under a second on a mobile hotspot the first time and every time. The key is that the tasks are nearly completely independent of each other, there are no builds and no dependencies, so writing a new task can't break old tasks. That system has plenty of screens that use d3.js for awesome visualizations and if I wanted to make a task that did something complicated which would really deserve React or Svelte or something I could do it, again, without breaking the the other tasks.
> I sketched out an alternative called "Nemesis" which grew into an HTMX-based system where it takes one programmer an hour to code a task and there is no build, and between Flask and the 15-or-so helpers it is easy
My argument here is basically creating that is really, really hard, and there's no framework or library that will make it easy.
React and friends are a mess because they're dealing with hard problems, kinda like systemd or kubernetes.
Writing code that lives entirely inside the machine is a lot easier than having to interface with the messy real world.
> Laravel is fine. It's not amazing. Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system).
As opposed to Javascript, the pinnacle of tight standards and high quality performative code...
The same arguments that can be made against PHP/Laravel absolutely apply to Javascript equaly, if not more so due to the pretty well know shiny object syndrome issues that many JS devs get caught up in.
You could maybe say "every framework is a hack to workaround protocols primarily designed in the 90's before we really understood the full application of the web"
The internet isn't the web, and there are plenty of applications who use those protocols just fine outside of the web browser. It's the html tech stack initially made for hypertext documents and resources that's been heavily upgraded to do web-based applications.
I would go as far as saying that the genius of the web is that it can grow, develop, be hacked, modified, expanded through technical and institutional means to be many things it wasn’t originally envisioned to be. Why is that a bad thing? Why is originalism a good thing?
Are you aware that nowadays you can write SPAs in dozens of languages?
It's an entirely different concept. It's certainly not the right technology for a news site, but days ago in a different place, there was for example the discussion about how an SPA and minimalistic API services fit a lot better with your average embedded device.
Even with Laravel you will write lots of Javascript unless you go for blade templates or that other templating thing. Javascript is also great for making the web interactive. Maybe the sheer amount of SPAs out there shows us what we really want from the web. Most things ppl use in their day to day life cant be built with HTML and CSS only
What 'other' templating thing? I'm assuming you're likely talking about either Intertia or Livewire. Inertia's more geared towards SPAs than Livewire though. Most Laravel devs tend to use JS sparingly - not everything needs JS.
Theres next to no reason why the vast majority of sites on the web would ever need to be heavily reliant on JS. Rendered HTML/CSS with JS being used sparingly for page functionality is a far better user experience. I'll never understand the obsession with JS for the sake of JS.
> You miss the whole point and the author is correct about this:
your comment is funny, because you are so wrong you aren't even aware how and why you are wrong. It's in "not even wrong" territory. I'll explain you why.
> Modern CSS is powerful, and HTML is the way to deliver web content.
Irrelevant. That's not why the world uses JavaScript frameworks. It seems you aren't even aware of the most basic reasons why the world migrated to SPAs. The most basic reasons are performance (and perceived performance), not only because the require less data to be moved around the internet but also every flow doesn't require full page reloads.
Also, classic old timey server-side rendered WebApps end up being far more complex to develop and maintain as you mix everything together and you are unable to have separation of concerns regarding how your platform is deployed and ran and how your frontend works. SPAs even allow your frontend team to go to the extent of handing your backend as if it was a third-party service, and some SPAs are even just that. There are plenty of CMSs out there which eliminate the need for a backend by providing all content needs through their commercial APIs. This makes webapppp projects greatly cheaper and simpler to finance and support as you can simply bother about developing and maintaining your SPA.
Lastly, those JavaScript frameworks you're trying to criticize also use CSS and HTML, by the way. So as you may understand your point is moot.
> Every web framework is _literally_ a hack to make the web something it isn’t.
You are clearly talking about things you have no understanding over. It matters nothing if you specify a DOM with a static file or procedurally. Updating only specific elements or branches of a DOM is a very basic usecases. In fact if you had any frontend experience at all you'd be aware that all mainstream GUI frameworks, including desktop, represent their UIs with a DOM.
So here you are trying to argue that frontend development is not frontend development just because you have an irrational axe to grind regarding a specific class of web development technologies?
> For thise JavaScript people, I recommend trying Laravel or Ruby/Rails.
If you hadn't already proven you are completely ignorant and detached from reality, this argument alone would leave no room for doubt.
> all mainstream GUI frameworks, including desktop, represent their UIs with a DOM.
If you call every hierarchy of visual items with some kind of layout manager(s) a DOM, then yes. Notably, the D doesn't really apply because GUIs aren't documents, and that's exactly why HTML is kind of awkward for GUI programming: it was initially designed for documents.
Edit: Sibling comment makes the good point that the main difference is that GUIs have mutable state while documents don't. I would add that GUIs also have controls to change that mutable state, which is a more superficial difference, but well, web-based GUIs are still extremely varied in their interaction styles, which not necessarily good.
Not the person you're replying to. I agree with a lot of what you are saying but:
> The most basic reasons are performance (and perceived performance), not only because the require less data to be moved around the internet but also every flow doesn't require full page reloads.
I can't keep a straight face at this one. If there's one thing the web isn't anymore, it's "fast." Presumably what you are getting at is server performance, because it's pushing all the work to the client.
> > Every web framework is _literally_ a hack to make the web something it isn’t.
> You are clearly talking about things you have no understanding over. It matters nothing if you specify a DOM with a static file or procedural
Don't be so dismissive. This is like the old anecdote about one fish saying to the other, "how's the water." The "something it isn't" is stateful. The web was not designed to be stateful, and every web framework is indeed a hack to work around that.
Thanks for dissecting all this nonsense. Although in all honesty, we may as well be dealing with comedy here: green account, recommending PHP and Rails in 2025 as if that's supposed to solve anything... we're being trolled.
> ...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.
Agreed. The article was a frustrating read. The author is an SEO consultant. SEO consultants likely have a heavy focus on marketing websites. Actual apps and not marketing websites do benefit significantly from SPA. Imagine building Google Maps without SPA. You can animate page transitions all you want, the experience will suck!
I agree with you. The author's point is that browsers have finally understood why some traditional sites were created as SPAs, which involves recreating some of the functionality browsers already offer today. But that doesn’t mean all SPAs should turn into MPAs now.
IMO it will be hard for some traditional sites to adapt to the new browser capabilities, since we've built an entire ecosystem around SPAs. The author's advice should've been: use the browser's built-in capabilities instead of client-side libraries whenever possible.
Also, keep in mind he's sharing his own experience, which might be different from ours. I've used some great SPAs and some terrible ones. The bad ones usually come down to inexperience from developers and hiring managers who don't understand performance, don't measure it, don't handle errors properly, and ignore edge cases.
Some devs build traditional sites as SPAs and leave behind a horrible UX and tech debt the size of Mount Everest. If you don't know much about software architecture, you're more likely to make mistakes, no matter what language or framework you're using.
I realised years ago there's no "better" language, framework, platform, or architecture, just different sets of problems. That's why developers spend so much time debating implementation details instead of focusing on the actual problems or ideas. And that's fine, debates can be useful as long as we don't lose sight of what we're trying to solve and why.
For example: Amazon's developers went with an MPA. Airbnb started as an MPA but now uses a hybrid approach. Google Maps was built as an SPA, while the team behind Search went with an MPA.
Even for basic sites, I tend to reach for an SPA because I never know when I'll be adding dynamic features, anything from basic showing / hiding of content, list / configuration-based rendering, or requesting data.
It's usually inevitable, so it's easier to scaffold a Vite template and get cracking without any additional setup. The time-to-deploy is fast using something like Netlify or Vercel, and then I have the peace of mind knowing I can add additional routes or features in a consistent, predictable way that fits the framework's patterns.
I'd hate to develop an MPA and realize after the fact that now I need complex, shared data across routes and for the UX to be less disrupted by page loads. Once you've dug that hole, you either have to live with it, or face a painful rewrite later.
The exception I often see is targeting mobile devices in low-bandwidth areas where larger application bundles take longer to load, but I have to wonder how often this is the target audience. I live in a place where mobile data speeds are horrible, and access to WiFi is abundant, but even so, I rarely have a situation where I *need* to load up a non-critical site on the go — and having apps pre-installed doesn't really help either when the data they're requesting is barely trickling in on mobile.
So this oft-used exception doesn't really make sense to me unless I learned why this is so critical for some people.
For scale, this is the easiest approach. Teams can focus on their roles and specialize more, which leads to higher efficiency as team members build their rhythm and stay focused on what they're great at.
At my company, our React SPA uses just over 500+ components across maybe ~30 views, with many smaller components alongside many of them in the same files. Our bundle size is obscene, but our customers are using fast PCs on fast connections. Once it's cached, they're good -- and each new release is roughly every 2-4 weeks, so fresh visits are painless.
As for server-side rendering from RSC, Next, Nuxt, and SvelteKit, I'd say they're overkill in most situations. The amount of people deploying simple sites on Vercel using Next.js, not really using its features, is just silly (and costly).
But this is exactly the point of the article. That'd be like if I needed to build a car, I started with a rocket blueprint in case I also need to go to space in the future.
The cost of speculating a highly interactive site that users will want to interact with is a suboptimal baseline experience until you get there. Provided you get there without losing users, it'll still be a subset of your audience that use your thing in a way that truly offsets all of these costs. If that works for your product/business, then awesome! But if these costs are too high and will hurt your product, then you need to be a lot more deliberate about how you engineer it.
I typically approach the problem first and see what tools work best to solve the problem, rather than work backwards from my preferred set of tools.
> Once you've dug that hole, you either have to live with it, or face a painful rewrite later.
Based on the tools you mentioned familiarity with, wouldn't something like Astro be a happy middle ground? You start as an MPA by default and only add complexity to parts (entire routes or parts of a page) of the application that require it? Also, this hole goes both ways. If you've built your site as a SPA, and you realise that your product just needs to be HTML to stay competitive, it's a painful road to unpick the layers of abstraction you've bought if you don't wanna rewrite it.
> dynamic features, anything from basic showing / hiding of content, list / configuration-based rendering, or requesting data
What would a highly dynamic feature be in your opinion and how does a SPA framework help you? All of the examples mentioned here, in my opinion, are fantastic candidates for server side templating and progressive enhancement. I don't need see the need for the SPA architecture here.
> mobile devices in low-bandwidth areas
Curious to know what kind of devices are present in your area? The implications of larger applications is both network and CPU [1], so if you live in a relatively wealthy area (say over 75% of users had iPhones) you'd notice the negative effects of too much JS less. If you're in the public sector or building for the public, then you can't get away with the excuse that people on slow devices and networks aren't your target audience; you need to meet everyone where they're at. A HTML-first architecture is a better and more inclusive baseline for all.
> wouldn't something like Astro be a happy middle ground?
Absolutely, but it is additional boilerplate I have to worry about that serves as another layer alongside whatever SPA framework I prefer; whereas spinning up a Vite template with Vue, writing a few routes + components, and getting it built + deployed is easier. It's at such a low cost (bundle size, time, boilerplate) that the optimizations gained from Astro aren't even in my purview unless I'm experiencing a significant enough scale that justifies static rendering.
When my apps are feeling and behaving perfectly already, why optimize? It only comes with increased scope and cost to bend around another layer.
> If you've built your site as a SPA, and you realize that your product just needs to be HTML to stay competitive
This does go both ways, yes, but with SPAs, I have more flexibility around client-side features like transitions, animations, pagination for smaller datasets, and state-based views that depend on a lot of different interactions, user selections, etc. that all drive what gets displayed instantly, without making a single network request just to complete the interaction. The Venn diagram between the two shows SPAs doing more out of the box, at such a low cost to commit.
Whereas with MPAs and server-side templating, a better-feeling UI isn't a luxury you can enjoy without some form of JavaScript to wire up page interactions. Given these are often a requirement, you'll find yourself haphazardly adding an SPA library to an existing MPA to enhance the perceived UX that it couldn't provide. Then you're not only juggling 2 scripting languages, but also reconciling the separation of concerns between your client/server now.
Although, happy-mediums have emerged: 37signals created Hotwire to help bridge this gap, Laravel has a similar library Intertia.js, and htmx+Alpine is another interesting solution.
Lastly on this point, Svelte's build step strips your SPA into the smallest possible runtime. Svelte was actually built for creating SPAs intended to run on low-power devices [1] typically seen in places like LATAM. React also has an official compiler that memoizes component data and callbacks. Preact is a 3kb alternative to React (40kb) for low-power devices, sharing the same APIs with only a few minor differences.
React, Vue, and Svelte all have server-side rendering where you can comfortably write sites/apps that serve up smaller bundles and stream updates to the client as needed, without sacrificing a pleasant UX. So, to answer your question "what if your SPA needs to be HTML to stay competitive?" -- these are all the most sustainable paths with the lowest costs.
>> You may be asking, "why don't you learn + use some of the alternatives you listed?"
As any reasonably tired, middle-aged engineer would say: I'm happy with the language(s), tools, libraries, and frameworks I'm comfortable using. The incessant drive to learn new tools that pretty much do the same thing with dubious (and likely negligible) benefit at smaller scale feels like a distraction when I could just be building and shipping something with familiar tech that thousands of other developers enjoy using. I also benefit from the community support as well, not to mention, AI tools are best used in TypeScript codebases currently.
Server-side templating requires dedicated hosting / VPS, which is a whole 'nother layer of deploying, managing, and debugging. Static sites and SPAs can be hosted with a static host for free (unless you scale like crazy), and any data-related needs are solved with serverless services like Supabase, Convex, lambdas/functions, and any number of others -- all with generous free plans and some level of portability.
In my case, I'm only developing SaaS applications not needing mobile support, that are only used by companies that buy decent computers for their employees. Otherwise I'm building small webapps for personal use and some that may become a hit among niche communities. Even my personal site is a tiny Vue app, and only because it's familiar and easy to change. The performance fiends can cry all they want that it isn't purely static, and in many ways, that amuses me.
My biggest gripe with Google Maps is when I pan to a specific area, hundreds, or even thousands of miles from my current location, then search for something like “restaurants” and it pans me back home and searches there, so I then have to go find my distant location again and click the search here button.
If this is an intentional choice, all in an effort to show me more local ads… ugh. I really hope this isn’t the case.
Google Maps makes it really hard to explore your travel destination, or I am holding it wrong. That and the lack of weather integration are my main issues with it.
The author states that MPA are not a solution for everything. Sure google maps don’t fit the MPA model but I’ve seen a lot of projects that would be much better using current browser features instead of react.
Google maps is a mess these days. Its glitchy, slow, has broken navigation, and is overloaded with unpredictable dynamic content. It's even worse in the native android app. Id totally go for the original version but with the more recent vector maps.
Being an SPA is certainly the cause of the glitchyness and slowness as complex content dynamically loads and shifts around. It's also certainly the cause of the broken navigation, just like the original article explains.
I'll have you know I spent time on organizing and structuring my code with early JS design patterns like IIFEs to limit scope, lazy loading of modules, and minification.
Anyway, in my experience, AngularJS was the biggest attempt at making structured front-end applications, and it really appealed / appeals (Angular is still very popular apparently) to Java developers; biggest ones was its modularization (which wasn't a thing in JS yet), dependency injection, and testability.
When we started out with an app in Backbone (to replace a Flex app because it wouldn't work on the ipad), I actually advocated against things like testing, thinking that the majority of functionality would be in the back-end. I was wrong, and the later AngularJS rebuild was a lot more intensive in front-end testing.
Of course, nowadays I'm repulsed by the verbosity, complexity and indirection of modern-day Angular code. or Java code for that matter.
Angular not only appeals to Java developers, it also appeals to .NET developers. TypeScript of course borrowed a lot from C# (having the same designer) and dependency injection, MVC patterns etc closely resemble .NET patterns.
Interestingly, new Angular is slowly moving away from these, introducing Signals for state management and standalone components, and I see these developers actually struggling a lot to adopt new Angular patterns.
Still, I believe Angular is a really great platform for building B2B or enterprise apps. It’s testing and forms handling is far ahead of every other SPA, and it actually fees like a cohesive framework where people have spent time designing things the right way; something I absolutely cannot say about react frameworks such as Next.js or Remix.
PS and I forgot to mention, new Angular patterns such as Signals and standalone components great cut down on the boilerplate and the verbosity. It’s not (and will never be) something like SolidJS, but each new version is clearly moving away from the heavy OO-based and multi layered patterns.
And GWT which allowed literally running Java on the web (without a plugin, it compiles Java to JS). It still exists and is maintained but not a Google project anymore despite the name.
Low-bandwidth/spotty connections (combined with aggressive caching) are one of the strongest cases in favor of SPAs (emphasis on the A for Application, not website). Visit (and cache) the entire frontend for the app when you have a good-enough connection, then further use of the app can proceed with minimal bandwidth usage.
It really depends. There’s a lot of SPAs which are practically unusable on a bad connection simply because it’s a challenge to even get the whole thing loaded in the first place. There’s been several occasions where I’ve had poor cell connectivity and a huge chunk of the web was effectively off limits due to this.
So in addition to aggressive caching, I’d say keeping the app’s file size down is also pretty important to making it useful on poor connections. That’s frequently something that’s barely optimized at all, unfortunately.
I work on an SPA with hundreds of screens. We package it using off the shelf tooling with barely any configuration. All of the code and styling is still far under a megabyte gzipped.
So unless it is an all text app, the size of the code bundle is probably going to be quickly dwarfed by the size of media like images, animated images, or videos.
If a site has an SPA with a, say, 3mb code bundle, I think in most cases, that’s not an architecture issue. It’s probably an issue of poor engineering and switching to a MPA is not suddenly going to make those engineers competent.
All three comments to this thread have missed the point that OP said installable SPA, not website SPA. This means the primary bundle is downloaded offline and only API network requests are necessary.
Sadly the art of error handling is often neglected by some SPA developers. I suspect that failures on the client are also less tracked this is tolerated by businesses.
I think with brotli over SSE you can do just fine with 3G and bad networks without needing to be a SPA. Keeping almost all state on the sever make realtime collaborative apps much simpler than data sync you need with SPA. This demo has zero client side state and handles concurrent interactions over a billion data points [1].
Latency might even be more relevant than bandwidth. Especially if it's a good SPA, that uses optimistic updates (or sync), and some kind of caching for fetching data (tanstack query or similar).
Anyone attending a major event, or in a disaster zone. Things are getting better, but if you live near a ball park or something, there will be periodic times when your cellular Internet is unusable
Crazy hills will do wireless in anywhere. In a rural area I am maybe a mile from the tower as the neutrino flies but a photon can’t make it. I have a bar of 5G in the pasture in front of the house but in the house it promises a bar of LTE but whether I can get out a text (w/o WiFi) depends on atmospheric conditions.
Out in Cali they have ring of fire conditions.
Too much crowding can do it too. A decade ago I was going to Cali a lot and thought it was funny to see so many ads for geospatial apps on TV that always showed a map of San Francisco when for me SF was where GIS went to die. Taking my Garmin handheld to the roof of the Moscone center because it was the only place it could get a clear view of the sky to sync up with GPS, so many twisty little streets that routing algorithms would struggle…. Being guided around to closed restaurant after closed restaurant and walking past 10+ open ones because a co-worker was using Yelp, etc.
Back around 2001 I visited South Carolina, and it was like being transported to the future of mobile internet. They had some kind of high-bandwidth cellular setup in the area that was far ahead of the rest of the country at the time, I think I recall it being around 20Mbit wireless. I was told the area was a testing ground for new tech. I was kind of shocked that somewhere that seemed so stuck in the past had such cutting edge tech deployed. I thought why is this not in SF??
I live in the middle of a major UK city, which is one of the most visited tourist destinations in the UK (if not the world). There are massive gaps of mobile coverage in the city - 5G is spotty at best, and it regularly falls back to much older protocols in the city. There are dead zones where you can literally walk 6 ft and drop to 0 coverage, and walk another 6ft and be on full blown 5G. Apps and sites like uber, twitter, Reddit, instagram all handle these awfully.
There are folks who work with US-based nonprofits, NGOs, and agencies who live all over the world, including regions where local internet access is either non-existent or very slow. Some US-based organizations they work with have had to set up low-bandwidth methods of communicating. Yes - sometimes geosynchronous satellites are the only connectivity available.
Often times my house. I live in one of the 20 largest metro areas in the US. There is a cellular dead spot around my house, seemingly from AT&T and Verizon. Phones work, but barely. Pages with high data demands become a problem.
There is this post about a experiment on google where they reduced the page weight and the traffic went up instead of down. That was because it open the site to countries with low internet bandwidth https://blog.chriszacharias.com/page-weight-matters
> in exchange for having really small network requests after the load.
I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire.
Most SPAs I've worked on/with end up making dozens of large calls after loading and are far far slower than just sending the equivalent final HTML across from the start. And you can't say that JSON magically compresses somehow better than HTML because HTML compresses incredibly well.
Most arguments about network concerns making SPAs a better choice are either propaganda or superstition that doesn't pan out in practice.
BREACH would be the relevant attack for content-encoding compression, it's only good for guessing the content of the response that can't actually be read otherwise, i.e. stealing a csrf token in cross-site requests, requires that the server echo back a chosen plaintext in the response (e.g. a provided query string), and takes thousands of requests to pull it off.
It's a vanishingly small number of things that are actually vulnerable to this attack, and I've never even heard of a successful real-world exploit (tho it's not like the attackers that might use this go and tell everyone).
With HTML you have to send both the template and the data. With json, it's just the data. So it's less information total. It should compress a little better, but I don't have stats to back that up.
Your comment then falls under my "superstition" label.
My experience has been that the HTML version will send overall less data since it contains precisely what is required by the UI and nothing more. The JSON APIs try to be "generic" across clients and either send more than the client needs or send less and cause the client to wait on a waterfall of requests to load everything.
You should always run benchmarks for your use case but the majority of web projects are not Figma or AutoCAD and benefit drastically from simpler approaches. A single compressed HTML response will beat a cascade of JSON ones every time.
Why does this have to be the baseline architecture when you can render the HTML on the server with the template and data? Why send the data and the JavaScript to parse that data and transform it into HTML in a users browser when you can do it on the server?
For requests after the first, you can still continue to send the rendered HTML to be placed into the document. Here's an example using HTMX: https://htmx.org/examples/lazy-load/
If your app is simple enough, go ahead and do that. In nearly every app I've worked on, I eventually need some dynamic piece of content. Like even a date picker, so you really want to call the server every time the use wants to go to the next month?
Why on earth would you drive a date picker from the server? No one is saying to do that. JS is absolutely fine to build custom UI controls. The form the date picker renders in doesn't need to be 100% JS though.
Use JS to patch over things the browser doesn't implement and let it handle the rest.
Ok, at least we agree on something. I think that's fine if your app is simple enough, but the more and more dynamic it gets, at a certain point, I think it makes sense to just render the whole darn thing in JS. At least for the DX.
> The idea is that you never have to send the template again after that.
This implies or assumes that sending the template again is a problem. In practice, it's not. HTML compresses well and the difference between the compressed JSON and HTML response is often on the order of hundreds of bytes. That assumes equivalent data content which, as I've said above, is often not the case. JSON payloads tend to be larger and we need more of them to render the same UI.
HTML templates are still text, text compressed well. As with all these discussions “it depends, profile it” is the only answer. People blindly assuming that X is better is why things are slow and shitty in the first place
Do browsers have trouble loading and rendering HTML in 2025? Page load should be blazing fast if it's not loaded down with a bunch of other stuff that hasn't already been cached.
They don't. The reason to do it is not to save bytes, but because you have a dynamic page that needs to respond to the user without doing a full page refresh on every minor interaction.
Why on earth would you do a full page refresh on every interaction? Browsers have native support for partial page updates and prefetching.
JS is fine to use too as needed. Generally, it's not needed. Small snippets to pop open modals or flyouts of whatever covers a huge number of use cases.
Languages... (is jQuery a language, I guess so, let's go with that)... live in a context... there is culture, tooling, libraries, frameworks. Some languages have good culture, some have bad culture. I guess it's not even so black and white: language have good or bad culture in different areas: testing, cleanliness, coding standards, security, etc. If jQuery is misused in the hands of bad programmers ALL THE TIME, that becomes the culture. Not much to do about it anymore once the concrete has set. You can't still be an exception to rules, good for you! But that doesn't change the culture...?
> If jQuery is misused in the hands of bad programmers ALL THE TIME, that becomes the culture.
My bet is that everyone here both agrees with you and is able to replace "jQuery" with "HTML", "CSS", and "JavaScript" to reach similar conclusions about the cultures of each. The problem is bad programmers, not the tech.
It drives me crazy when it used together with React —- I want to have one authoritative copy of the state of my app, and jQuery bypasses that, at least if I’m using controlled forms.
Now I used to hate uncontrolled forms but now I like react-hook-form.
If you work at a place that has a modern CI/CD pipeline then your multiple deployments per day are likely rebuilding that large bundle of JS on deploy and invalidating any cache.
HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant. SPA’s that use packaging of large bundles doesn’t leverage modern browser and server capabilities.
> HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant
H2 doesn’t make packing irrelevant… there’s still an IPC overhead with many small files… and larger bundles tend to compress better (though compression dictionaries might help here)
The real reason SPAs are popular is because JavaScript is the new Visual Basic and there are millions of developers that know nothing else.
Workforce market forces like that have a vastly greater effect than “bandwidth optimisation”.
My evidence for this is simple: every SPA app I’ve ever seen is two orders of magnitude slower than ordinary HTML would have been. There is almost never a bandwidth benefit in practice. Theoretically, sure, but every app I come across just dumps half the database down the wire and picks out a few dozen bytes in JS code. There's a comment right here in this discussion advocating for this! [1]
Another angle is this: if you had a top 100 site with massive bandwidth costs, then sure, converting your app to a SPA might make financial sense. But instead what I see is tiny projects start as a SPA from day one, and no chance that their bandwidth considerations — either cost or performance — will ever be a factor. Think internal apps accessed only over gigabit Ethernet.
I’ve seen static content presented as a SPA, which is just nuts to me.
Does a real-world example of bandwidth saving even exist for SPAs? It’s always the other way around where what could’ve been a single page load, ends up being 6 separate asynchronous calls to different APIs to fetch random bits and pieces while the user stares at spinners.
And the frontend-backend paradigm has seeped into the engineering culture and even the non-engineers on the team understand things in those terms. The main way we break apart work into tickets is API endpoints and client-side UI stuff.
This. The mental model of an API with a frontend deployed as static resources just happens to be very attractive. Even more so when the SPA isn't the only frontend, or when you don't know that the SPA will remain the only frontend forever. When you have an SPA sitting on top of an API, introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial.
If you have a huge org working on the project you might actually succeed in sticking to that architecture even when serving as plain old HTML, but smaller teams are likely to eventually write full stack spaghetti (which might still be fine for some use cases!). Once there was a fashionable term "progressive web app", with manifest workers optionally moving some backend stuff into the browser for offline-ish operation, and these days I also see a parallel pattern: progressively moving a browser UI into an electron-esque environment, where you can features requiring more local access than the browser would allow.
> introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial.
This never happens, for some values of never.
When a SPA app is initially developed, the "client" and the "API" are moulded to each other, like a bespoke piece of couture tailored to an individual's figure. Hand-in-glove. A puddle in a depression.
There is absolutely no way that some other category of platform can smoothly utilise such a specialised, single-purpose API without significant changes.
The reality is that most SPA apps are monoliths, even if the client app and the API app are in different Git repos in order to pretend that this is not the case.
That's absolutely not my experience from any of the SPAs I've worked on. If the API used by the SPA is so "specialised, single-purpose", then that isn't something inherent to SPAs, only inherent to developers (or architects) who are inexperienced or bad at their job.
>every SPA app I’ve ever seen is two orders of magnitude slower than ordinary HTML would have been.
I'd argue then you don't have an SPA. However I don't see how you could have a application like Figma or Discord and say "ordinary HTML is faster" (or even possible).
For ever one real "app" like Figma there are hundreds of web pages with some forms and light interactivity. Numerically there are far more enterprise LoB apps than there are true web applications that SPAs are well suited for.
"Every SPA app I've ever seen". I'm yet to see a fast one. Maybe they exist! I wouldn't know.
YouTube, for me, is unfathomably slow. It takes about a minute before I can get a specific song in one of my playlists playing. Every view change is 5-20 seconds, easily.
Facebook and the like now show polyfills for 10-30 characters of text, because hundreds of thousands of servers struggle to deliver half a line of text over terabits of fibre uplinks. Meanwhile my 2400 baud modem in the 1990s filled the screen with text faster!
Jira famously was so slow that this would never fail to be mentioned here any time it was mentioned. Service Now is better, but still slow for my tastes.
Etc...
If you disagree, link to me a fast SPA app that you use on a regular basis.
PS: Just after writing this, I opened a Medium article, which used -- I assume -- SSR to show me the text of the article quickly, then replaced it with grey polyfills, and then 6 full seconds later it re-rendered... the same static text with a client-side JavaScript SPA app. 100 requests, 7 MB, for 2 KB of plain text.
You mean a chat cliënt? That seems a good worse case scenario.
If you limit history to the most recent message (and have an link to the archive at the top) you could simply reload the entire page on some interval that declines with message frequency (and when you submit the form)
Since the html document is pretty much empty the reload happens so fast you won't see the flashing. With transitions it would be perfectly smooth.
With modern css you can put the elements out of order. You can simply append the new line to the end of the html document that represents the channel. (And to the archive) Purging a few old lines can be done less frequently.
I haven't tried it but it should work just fine. I will have to build it.
Initial load will be 100x faster. The page reloads will be larger but also insanely robust.
The things I was wondering about were: 1) can a non spa chat client be as good as a spa. 2) at what point is a spa justified. (is chat enough?)
Phone calls and live streams are things for which a tab needs to stay open. If you want to do other things simultaneously both the browser and the OS could facilitate it - but do so rather poorly.
SPAs are nice when your app requires complex state; multiple rows of nested tabs, modals, multiple interlinked select inputs which load data dynamically, charts or graphs which can lazy-load data and update on the fly in response to user actions.
There is a certain level of complexity beyond which you need to load data on the fly (instead of all up front on page load) and you literally cannot avoid an SPA. Choosing to build an SPA is not just some arbitrary whimsical decision that you can always avoid.
Sometimes people just go straight to SPA because they're unsure about the level of complexity of the app they're building and they build an SPA just to be sure it can handle all the requirements which might come up later.
One of my first jobs involved rebuilding a multi-page EdTech 'website' as an SPA, the multi-page site was extremely limiting, slow and not user-friendly for the complex use cases which had to be supported. There was a lot of overlay functionality which wouldn't make sense as separate pages. Also, complex state had to be maintained in the URL and the access controls were nuanced (more secure, easier enforce and monitor via remote API calls than serving up HTML which can mix and match data from a range of sources).
I think a lot of the critiques of SPAs are actually about specific front end frameworks like React. A lot of developers do not like React for many of the reasons mentioned like 'resetting scrollbars' etc... React is literally a hack to try to bypass the DOM. It was built on the assumption that the DOM would always be unwieldy and impossible to extend, but that did not turn out to the the case.
Nowadays, with custom web components, the DOM is actually pretty easy to work with directly but info about this seems to be suppressed due to React's popularity. Having worked with a wide range of front end frameworks including React for many years, the developer experience with Web Components is incomparably superior; it works exactly as you expect, there are no weird rendering glitches or timing issues or weird gotchas that you have to dig into to. You can have complex nested components; it's fast and you have full control over the rendering order... You can implement your own reactivity easily by watching attributes from inside a Web Component. The level of flexibility and reliability you get is incomparable to frameworks like React; also you don't need to download anything, you don't need to bundle any libraries (or if you do, you can choose how to bundle them and to what extent; you have fine-grained control over the pre-loading of scripts/modules), the code is idiomatic.
> there are no weird rendering glitches or timing issues or weird gotchas that you have to dig into to.
Ehm... define the Web Component render blocking in the head, because you want to prevent FOUCs.
Then try to access the .innerHTML of your Web Component in the connectedCallback
Interesting but I wouldn't call that a gotcha. Trying to read the DOM outside of the component is kind of an anti-pattern and I think this kind of behavior should be expected. You'd generally want the web component to be a black box and it works pretty well once you understand the rendering order and focus only on internal or slotted elements. I think the only real 'gotcha' I came across was the order of when the attribute changed callback gets called versus the connect callback but it's easy to adjust the logic internally to take this into account. I can make do with a custom render() method and sometimes additional methods to perform specific granular updates to the component's own DOM...
With React, the component either gets rendered or it doesn't get rendered; all or nothing and React fully controls this. With web components you can also just nit-pick a single element within the component's DOM and only update that one. It gives you more opportunities in terms of performance optimization and how you split up your components... But you can also achieve a similar result as React by just re-rendering the whole component if necessary.
The one difficulty which is actually an advantage IMO is that you cannot pass JavaScript object or function references to Web Components via HTML attributes; you have to pass primitive values... But IMO this a BENEFIT because it forces separation of concerns and it makes the DOM way easier to debug in the dev console. For advanced use cases you can still pass JS refs to a child component by calling methods on it but I try to avoid this because it makes it harder to understand the state of a component.
I like it when I can understand the state of a component just by looking at its attributes and I like those values to be as simple and human-readable as possible. I love opening up my dev console and just tweaking the HTML attributes directly and see the change happening. Makes debugging a breeze. Kind of tricky to do with React and you get into all sorts of weird situations where a render may not trigger when you expect when you change properties of an object without changing the reference itself. React adds a lot of unnecessary complexity there.
i remember seeing web components years ago, it sounds like they've improved a lot.
what do you do about the lack of (i assume) ecosystem? due to the ready ubiquity there's practically a library for everything. do you find that using WC you are having to hand roll a lot? i don't mean to be a package slave but for complex and tedious things like graphs / charts.
> SPAs make sense when your users have long sessions in your app.
SPAs also make sense when you want to decouple the front end from the back end, so that you have a stable interface like a RESTful API and once AngularJS gets deprecated you can move to something else, or that when your outdated Spring app needs to be updated, you'll have no server side rendering related dependencies to update (or that will realistically prevent you from doing updates, especially when JSF behavior has changed between versions, breaking your entire app when you update).
> When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.
The slight difference in user experience might not even enter the equation, compared to the pain that you'd have 5 years down the line maintaining the project. As for loading the app, bundle splitting is very much a thing and often times you also get the advantage of scoped CSS (e.g. works nicely in Vue) and a bunch of other things.
Not sure what kind of clients you work with, but in my experience this is actually accurate and you won’t believe how many times I had to put my hands and fix SPAs that should have been a static website to begin with.
I think this is a consequence of a generation of webdevs, especially front-end, that graduated from bootcamps teaching them only JS frameworks and React as if that’s the only way the Web works.
They were given a hammer, told how to use it, and everything then just looks like a nail.
I don't know if a bunch of sloppy jQuery modules were ever really a viable option for an SPA. People tried to do it, sure, but I'd say the SPA era really started with backbone.js
> SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.
Only for certain types of applications… the route change time for many SPA’s is way higher than for the equivalent MPA
Depends on the definition of SPA, but in the days of jquery, I hardly consider any of that single page app. For example, the server rendered page had most of the html initial rendered, jquery would attach a bunch of listeners, and then on an update it incrementally. If lucky, we had a duplicated x-template-mustache tag which had a logic-less template that we could use to update parts. Jquery and duplication was the “problem” which drove everyone to SPAs.
But you were talking about code, not data, hence my question. Also, Amazon doesn’t need to be that way (and wasn’t twenty years ago, the motivating period we are talking about).
> When it is worth the pain to load a large bundle in exchange for having really small network requests after the load
...and yet, i keep running into web (and even mobile apps) that load the bundle, and subsequent navigation is just as slow, or _even slower_. Many banking websites, checking T-Mobile balance... you wait for the bundle to load on their super-slow website, ok, React, Angular, hundreds of megs, whatever. Click then to check the balance, just one number pulled in as tiny JSON, right? No, the website starts flashing another skeleton forever, why? You could say, no true SPA that is properly built would do that, but I run into this daily, many websites and apps made by companies with thousands of developers each.
backend has many traps but no one totally dominating "load the slow bundle once, near-native subsequent page loads" narrative which is (for whatever the reason!!) a non-existent illusion on most average daily websites.
Java applets and ASP.Net did have a superficial answer to this, as well as Flash, but they varied in terms of their ability to actually function as raw web interfaces using the URL to navigate between sections.
Being able to reliably and programmatically interact with client-side storage and the url, as well as improvements in DOM apis and commodification of hardware with more ram and faster faster CPUs, among many others factors, seem to have contributed.
https://extjs.cachefly.net/ext-3.4.0/examples/ unfortunately most of the data examples don’t work, but I believe everyone browsing the web back then remembers this blue tinted interface.
oh man now THAT is a real blast from the past. oh man, pretty classic "where did all the time go?"... "oh yeah i forgot that i spent like 100s of hours battling with sencha back in the day". selective memory isn't always a bad thing, i guess.
The rule is either "uses html to render" or an even looser "renders in the browser". That doesn't seem like a deep constraint to me. You exclude a couple very popular but historical plugins where the browser set up a rectangle and handed it off to an external piece of code, and pretty much nothing else.
SPA is not only about seamless transitions but also being able to encapsulate a lot of user journey on the client side, without the need of bothering server too much.
Let me give you an example - one of my biggest gripes about web ux is the fact that in 2025 most shops still requires you to fully reload (and refetch) content when you change filters or drill down a category.
A common use case is when you come to a shop, click on "books" (request), then on "fantasy" subsection (another request), realize the book you're looking for is actually a "sci-fi", so you go back (request, hopefully cached) and go to "sci-fi" (another request).
It's much better ux when a user downloads the whole catalogue and then apply filters on the client without having to touch the server until he wants to get to the checkout.
But it's a lot of data - you may say - maybe on Amazon, but you can efficiently pack sections of most shops in data that will enable that pattern in less kilobytes that takes one product photo.
I've been building web apps like that since ca. 2005 and I still can't understand why it's not more common on the web.
I don't know, I think the most painful aspect of having to do a full reload is how I efficient the site is. The actual data is a few KB, but the page itself has to download 100 MB and the web browser is burning through a GB of RAM.
Like I don't find Hacker News to be egregious to navigate, and nearly every nav is a reload. It runs fine on my 2008 laptop with 4 GB of RAM.
But I go to DoorDash on the same device, and it takes 30s to load up a list of 50 items. They give you a countdown for a double dash, and I genuinely don't think it's possible to order some curry and get a 6 pack of soda in less than 3 minutes. And 2.5 minutes is waiting for it to render enough to give me the interface. Almost none of it is a full reload.
An SPA can be lean and fast. React is the prevailing Web framework today? Preact is like 5 KiB of code.
What makes SPAs unwieldy is not the technology but the lack of desire to optimize. It loads fine on yesteryear's Macbook Air? Enough, push it.
I very well remember heavy, slow-loading websites of, say, year 2000, without any SPA stuff, even though lightweight, quick-loading pages existed even then, in the epoch of dial-up internet. It's not the technology, it's the desire to cram in more, and to ship faster, with least thinking involved.
> I very well remember heavy, slow-loading websites of, say, year 2000, without any SPA stuff, even though lightweight, quick-loading pages existed even then, in the epoch of dial-up internet.
Sure, lightweight, quick-loading pages existed, but sometimes you want to see a picture.
Google appeared in 1998. It was very noticeable how fast it loaded compared to competitors like AltaVista and Yahoo. None of them featured large photos.
This was visible not only on a 33600 phone connection at home, but also on a megabit connection at work, because, shockingly, how fast your backend is also plays a major role.
Speaking of speed, don't forget when gmail and google maps first came out: With the data copied locally they could separate the UI from server requests for a lot of interactions so a lot of the UI was actually instant and you could keep doing things while the requests were handled in the background. This seems to have been missed by a lot of modern stuff that doesn't bother figuring out if this is even possible and opts to show a loading spinner instead.
Yeah, the enemy isn’t the need to reload, it’s reloading taking a long time due to too much garbage that’s not the content the user is interested in having to come down off the wire and render. A site that requires an occasional split second reload is always going to be preferred to a behemoth that doesn’t need reloading but has me staring at blank screens and loading spinners half the time I’m using it.
> But I go to DoorDash on the same device, and it takes 30s to load up a list of 50 items.
> And 2.5 minutes is waiting for it to render enough to give me the interface.
I have a very old MacBook Air (one of the painfully slow ones) that I use for development reference for what a slow machine looks like.
I just tried clicking around DoorDash and didn’t see anything nearly this bad. Not even close.
Every time there’s a Hacker News thread about how slow websites are, there are dozens of comments like this claiming extremely large latency numbers. I can’t tell how much of it is exaggeration for effect, or if some people have configurations with weird quirks that make them abnormally slow.
I suspect it’s a lot of this:
> on my 2008 laptop with 4 GB of RAM.
Sorry, but I don’t think it makes sense for companies to optimize their websites for computers that are nearly two decades old and don’t even have enough RAM to run a modern operating system.
The intersection between people who spend money on a expensive luxury service like food delivery to their door and people who won’t spend the cost of a couple DoorDash deliveries to upgrade from a 2008 laptop to a 2018 laptop in 2025 is negligibly small.
Hmm, I would say comparing Hacker News to DoorDash is not exactly apples to apples. There may also be ulterior motives to make a website slow(or at least not optimized) if the company wants to funnel people towards an app on the phone.
Navigating to a thread isn't much different than navigating to a store.
Upvoting isn't much different than adding to the cart.
Payment isn't much different than adding a comment.
I think the interaction levels are incredibly similar. The primary difference is the amount of images displayed, but that really isn't a significant aspect of web design or Internet traffic in 2025.
Document-centric, form-driven websites aren’t traditionally called apps. The Wikipedia website isn’t an app. Web forums aren’t apps. “App” implies that essential parts of the interaction logic are driven by client-side code (JS, not HTML) that couldn’t similarly be implemented by HTML forms.
Sure Wikipedia is an app, long as you think of static websites as a subset of web apps. One might say that makes the term meaningless, I say it's a deliberately vague term because people don't want or need to get cornered by fine distinctions. Otherwise it's endless quibbling over whether things like search do or do not count toward a site being a "real" app.
Thing is, and I believe it's a valuable example counterpoint, if I shift-click on a link, like sci-fi category, to open it in a new tab(very common thing people do), having a multi page application is zero work added, on an spa you have to manage that. If the link doesn't exist and categories can only be accessed by a select input then ux isn't that great
This is so annoying when SPAs break browser functionality like open link in new tab. Even if it works often it has to reload a bunch of JS again, which makes things veeery slow. This is why I really don't like Linear, I often open issues in separate tabs, which is every time a pain, browser freezes for seconds just to open a link in a tab...
I think it was not designed for your use case. It is conveniently running in the browser but not a collection of links to html pages. The people quarreling in this comment section seemingly ignore that life is complex, web browsers are complex, web development is complex. Maybe you should think about linear as a desktop app and call it a day :)
My use case is being productive at my work. If it was not designed for that, then not sure what is it for. It comes up fairly often in team chats, it's a resource hog with ridiculously high memory usage, poor browser utility, syntax highlighting selecting random languages,... I'm happy that it fits your desktop app use case, but there are also other people that see this as a limitation and sign of poor design. Web development is complex, but acknowledging that there are poor web apps and better web apps is part of that too. And from my experience and in my opinion (also shared in my team), Linear is an example of the bloated web app that is making the web worse for us, which is why I brought it up above.
EDIT: the parent I was replying to talked about the issue of opening links in new tabs and your answer - don't do it, use it like a desktop app - is basically the problem we are having with some of these web apps.
Modern SPA frameworks give you this by default. You can deep link and get the specific page with all the parameters/filters etc applied server rendered in remix/react-router, next, sveltekit and most other frameworks. I agree that too many apps have basic things like CMD+click broken
Please no. Whenever I see an online store as a SPA catalogue I shudder, because it usually breaks after browsing a bit in a weird state. And it resets to somewhere random should you hit back, refresh or try to send a link to somebody.
> It's much better ux when a user downloads the whole catalogue and then apply filters on the client without having to touch the server until he wants to get to the checkout.
This is what we[0] do too. We have a single JSON with a thousand over BOMs that's loaded directly into the browser. Previously we loaded the inventory data via an API as is usually expected. The fact that there's even an API meant requiring progress and loading bars, API unavailability scenarios, etc.
Having it all as a single preloaded JSON meant that all of the above goes away. Response is instantaneous.
HTMX (and similar) solves a lot of this. It so happens that we end up building two apps one frontend and one backend with SPAs as built today. I'd rather build a lot of it on the server side, and add some dumb interactivity on the client (show/hide, collapse/expand, effects). There is still a place for SPA though.
in addition to native html features like <details>, etc.
htmx can often decrease the number of trips to a server because in the hypermedia model you are encouraged to deliver all the content for a UI in one fell swoop, rather than in a series of chatty JSON requests that may be made due to opaque reactive hooks.
I find Datastar to be a better replacement for HTMX, especially now that it can also do plain requests instead of Server-Sent Events. You also don't need Alpine.js combined with HTMX anymore.
First time I've heard of Datastar. Not sure what to make of it yet, but the video on data-star.dev is certainly one of the cutest things I've seen all year!
Generally speaking, companies don't want you to download their entire catalog. They don't want competitors to be able to analyze it easily like that.
And if a store is selling books, it might have hundreds of thousands of them. No, it's not a good experience to transfer all that to the client, with all the bandwidth and memory usage that entails.
If it's one their website the competitors can write a simple crawler and create that catalog.
And you don't have to send every single field you have in your database.
Once the user selects a category you can send a metadata that enable the client to scaffold the UI. Then you cache the rest while user interacts with the site.
Barnes and Nobles - according to their FAQ - has 1 million unique items in their catalog. But they also have tons of different categories. A single book cover weights around 30kb.
I'll leave it as an excercise to figure out how much data you can fit into 30kb to make usable filtering system.
btw: opening their front page downloads 12.1MB already.
> SPA is not only about seamless transitions but also being able to encapsulate a lot of user journey on the client side, without the need of bothering server too much.
True, but as a user, I don't want you encapsulating my journey. You can wax poetic about hypothetical book categories, but the reality of SPAs is that they break back buttons, have terrible accessibility anti-patterns, attempt to control my attention, and expose my computer to all your bad security practices. SPAs usually contain half-assed implementations of half the features that ship standard in a modern browser, and the only motivation for all that effort is to make the site more favorable to the server's owner.
When a site is implemented with simple HTML and careful CSS, I can configure it to my needs in the browser quite easily. That's a site that favors me, not your opaque blob nonsense.
In almost all cases the back swipe in the spa resets you to the top of the page, navigating out of the app and back in doesn’t work, etc. It’s really hard to build a multi page spa that feels good.
It reminded me of the time when I joined Wikia (now Fandom) back in, I think it was 2006. One of the first things that landed on my desk was (I can't recall the context) deeplinking.
And I remember being completely flabergasted, as I came Flash/games background, and for us that problem was completely solved for at least 4 years at the time (asual swfaddress package). I felt kind of stupid having to introduce that concept to much more senior engineers that I was at the time.
I'm a self taught PHP/jQuery/bootstrap guy with a small saas.
I handle page scroll position by literally saving it into some session data cookie and when you go back I check where your scroll was and I fix it for you.
I'm not a genius or skilled... But I cared so I did it.
I write some of my thoughts on this sone years ago. The library described at the end is now fairly out of date but the ideas and suggestions are still good, I think.
In Tanstack Router it's a boolean you set when creating the router. The documentation nicely lays out what's being done under the hood, and it's quite a bit.[1] I wouldn't try that at home.
In React Router you just chuck a <ScrollRestoration /> somewhere in your DOM.[2]
In a similar use, a few of my hobby projects are hosted on static web servers. So instead of rendering out everything into individual pages, which would've been tens of thousands of pages, I have a JSON file that gets rendered by the client in a SPA. I have even used Github Pages for this
I'm playing around with a newer version that uses a sqlite database instead. Sqlite officially has wasm builds, and the database file is already built to be separated into pages. With HTTP Range Requests, I can grab only the pages I need to fulfill any queries.
Sqlite full text search even works! Though I'm hesitant to call that a success because you do end up grabbing the entire FTS table for shorter searches. Might be better to download the entire database and build the FTS table locally.
This wouldn't work for 90% of apps out there. While I would love that approach, it has so many problems that in practice it never worked out for me. First problem is that data change. Either you edit it, or you need updates from server applied to your copy. This is quite complex (although there are some solutions, I had little luck in making this work reliably). Second - you don't want to share the whole catalog in one request. Third - in most cases there is a lot of data. It's not uncommon to have tens of thousands of items and for each you likely need some kilobytes. Four - you are downloading the whole catalog even for deep links which might not care about all but a tiny fraction of that data.
In my experience, state is the devil, and the approach of filtering things on the client moves a bunch of state management from the back end to the browser, which is the worst place to handle state.
You can do that with checkbox selectors. e.g. see [0]. Note that I don't really do frontend and I asked chatgpt to vibe code it, so this may not be the best way to do it.
I don't know what universe this SEO-consultant author lives in. The author gives Next & Nuxt as an example of the kind of frameworks going against his prescription, but that is so wrong.
1. Next won the war in the west, big time. Very very big time. Whenever people talk about new React apps they inadvertently mean Next. On the Vue side Nuxt is the default winner, and Nuxt is just the Next of Vue. That means that by default, by reflexive instinct, people are choosing Next and MPA as their strategy. If you want to correct the overly extreme pendulum motion then you should be telling people to try out SPA. The last 8 years has been a feverish push for MPA. Even the Facebook docs point straight to Next, totally deprecating Create React App. This is also Facebook ceding their battle to Next.
2. Whenever people complain about the complexity of Next, they are complaining about the difficulties of cutting edge MPA strategy, which evolves on a year to year basis. SPA on the other hand is a story that has frozen in time for who knows how many years. Almost a decade?
3. Doing MPA is strictly harder than doing SPA, much much harder. You have to observe the server/client distinction much more closely, as the same page may be split down the middle in terms of server/client rendered.
4. If you're writing an SPA and want to be more like MPA and load data at the time of hitting a user-navigable endpoint, that's on you, benefits and costs and all. You can also load data with anticipation so the client navigation is basically instant.
5. For every sexy SEO-able front-facing property you're going to have many teams with internal apps or dashboards backing that front-facing property. That's where many React devs are employed. Do not unnecessarily take on burden because you're so eager to ship the first "frame" of your app in a perfect way.
How did next win the React framework war? Is it not few years already that see exodus from next to remix/react router, and more recently to tanstack start etc. because of unnecessary complexity, difficulty to run next on anything but vercel, misguided API changes etc.?
You mentioning facebook docs pointing to next, when they explicitly mention remix and other is quite misleading.
Well, you must know how to look at download stats, search metrics, GitHub activity, social media temperature, or job posts. I feel that seeing is believing with your own eyes is sufficient for anyone who wants to investigate the issue of whether there’s any winner in popularity.
To not be misleading I wouldn’t have brought up the existence of remix lest people think Microsoft belongs in the same discussion as my software consultancy.
By your logic PHP and Java won the programming language war.
And according to github stars, (which may be considered rough measure of overall usage, not of current trend) next.js has 4x more than remix. So if your sw consultancy is one fourth size of Microsoft, you are close to a trillion dollar business. Even if you exagerrated by few orders of magnitude, thats still very big achievement, so congrats.
When I choose things like Tanstack Start, I am very clear that this is beta software and an early bet. When I'm talking about winners in the ecosystem, I am not going to bring up Tanstack and most definitely not Remix. I don't want to confuse people into thinking they belong on the same table of discussion for ecosystem winners.
I think at some point there was more interest in framework as a startup, and there was indication that having a popular router (React Router) was a sufficient advantage in the race to at least try to win.
Then Shopify bought them up to maybe hedge against Hydrogen. Remix never went anywhere for Shopify, Shopify didn't buy React Router, only Remix. Now, as you say, Remix is being retired. My own Remix app was rewritten as I was tired of upgrading pains.
But what do you think of the argument that this is moreso Shopify folding their hand than Shopify realizing their bet via React Router?
> I don't know what universe this SEO-consultant author lives in.
After looking over the author's blog I can see
1. Very high output
2. Lots of AI images
3. Weird writing and editing lapses in several posts
I am moderately confident this post was written with an AI. It may not be totally AI produced, I think the author has probably edited the work, but I think we are mostly debating synthetic content.
There was a war? News to me. Saying Next won is like saying React won. Nothing won, everyone just latched on to what they thought the crowd vetted. The blind can't lead each other. Most people that stuck to Angular or minimal or no-frameworks are truly wondering what the fuck are all these people talking about?.
Even the Facebook docs point straight to Next
Startups and SV jerk each other off by promoting each other (think affiliates). None of it means shit.
Next is probably a garbage framework, but it's people's livelihoods. It's very hard to erase something that literally defines people (yes, your resume is YOU).
Kinda is a war unless you're working solo, cause you're gonna get forced to use something or another. When I tried a few solo web projects instead of just being a backend guy, I picked up React on my own because it was the only thing that makes sense. The page does what the code says. And that was after trying other things.
Now I gotta occasionally use Angular, and it's boilerplate hell. Adding one button involves editing 30 classes and files even if you don't use templates. I took a course at work where even the instructor got confused adding a button. Why would anyone ever use this besides Google, or do they even use it?
angular is a mess. it's the java of web frameworks. if you want up be enterprise(tm) go for it. I’m convinced it's only a thing because it gives people job security since nobody else chooses to touch it.
I don't know what you guys are doing with your Angular buttons, or if you haven't looked at it since AngularJS (which I never used, so I don't know what it took there).
Adding a button to Angular is just adding a <button> to your template. If you want to use Angular Material, that's one additional import in your component's code file, and one additional attribute for that template's <button> element.
import {MatButtonModule} from '@angular/material/button';
<button matButton (click)="onClick()">Click me!</button>
That's it. If your instructor got confused trying to achieve that, maybe that's why you were left with this weird impression of how verbose and complicated Angular is.
Just at least have a look at the documentation or tutorial before spreading fibs like that.
> Startups and SV jerk each other off by promoting each other (think affiliates). None of it means shit.
No, this is FB ceding the battle. They absolutely didn't want this. They dropped CRA because social media celebrities were shitting on CRA. Dan Abramov had to do a complete 180 in a single day, after writing a long thoughtful essay in defense of CRA.
Wars, battles, personalities on social media… I don’t want to sound too much like a grouchy old man but these frameworks are tools. Nothing more than that. I can’t understand why anyone would become emotionally invested in any of them.
When starting a project the right move to examine what best fits your project, not which one was recently victorious in a war. I’ve grown to dislike React because I see it being abused so often for a site where it isn’t necessary. There are plenty of projects where it is necessary too, but that’s not universal.
> I can’t understand why anyone would become emotionally invested in any of them.
I think that's simple: because they are financially invested in them. That's obvious for the developers working on the frameworks themselves or building libraries / plugins / UI-themes for them, but I believe it's also correct for "normal" developers who build things with these frameworks.
They know these frameworks and can use them, and they've made an investment in time to get to that point. Likely they're also making at least some of their money _because_ they know these frameworks. Emotional attachment follows the economic attachment, and then you'll get plenty of rationalizations.
You can ignore all the phrasings of wars or battles or winning and losing, and you can also ignore that social media has consequences.
We can agree that frameworks are just tools. And as tools we can coldly think about trends and other meta-facts, including questions on popularity. We don't need to think about popularity in terms of winning or losing either, just numbers that move around so we can use them as predictors of mindshare and career opportunities.
And in that sense, the right tool that fits the job often includes an analysis on popularity, especially because the best tool is often one that you and your colleagues already know.
The point of SPAs was never page transitions. I can’t name a single major SPA that does good page transitions, can you? They all just replace the content. And to take a popular SPA framework as an example, it’s almost impossible to do page transitions in Next.js because of the way routes are loaded. I know this because I added proper page transitions to Next.js and it has been an absolute nightmare.
There are two good reasons for SPAs that I can see:
1. Your app probably needs interactivity anyway; for most apps, it’s not just going to be HTML and CSS. Writing your app in some unholy combination of React and HTML is not fun especially when you need to do things like global state.
2. Loading the structure of pages up front so that subsequent data loads and requests are snappy. Getting a snappy loading screen is usually better than clicking and getting nothing for 500ms and then loading in; the opposite is true below I’d say 100ms. Not needing to replace the whole page results in better frontend performance, which can’t really be matched today with just the web platform.
Basecamp has probably invested the most in making a fairly complex webapp without going full SPA, but click around for like 30 seconds and you’ll see it can’t hold a candle in performance to SPAs, never mind native apps.
With that said, I agree that I’d want the web to work more like the web, instead of this weird layer on top. All the complexity that Next.js and SPAs have added over the years have resulted in more responsive but sometimes more tedious-to-build apps, and gigantic bundles. I just don’t think you can match the performance of SPAs yet with just HTML.
3. APIs. If you already have a client facing API for your iOS and Android apps, and maybe one for developers, a SPA is just another app to plug into that backend.
> Basecamp has probably invested the most in making a fairly complex webapp without going full SPA, but click around for like 30 seconds and you’ll see it can’t hold a candle in performance to SPAs
Really? I just started using it, and it feels fast. Most SPA's are slow and/or buggy (in the "fails to mimic real browser behaviour" kind of way)
Lots of pushback here in the comments. But I can't think of the last time I enjoyed using a SPA website over a multi-page one. The initial loading feels delayed, the page scrolling feels unnatural and jarring (completely opposite of how a native app feels).
Also, one of my banks recently changed their old website to a new SPA one. And it is now completely useless. It can't load information in time, so most of the forms are empty. You can't even go back because it is a SPA. So I can only log out, log in and try again. Kind of scary when you are handling a lot of money.
And it is not just one website. As I said I can't recall ever using a good SPA website. So yeah, I can't wait until they are all gone.
The toupee fallacy strikes again here. Gmail, slack[0], Netflix and Spotify are top tier examples - they actually work. Most are true garbage though.
[0] I am firmly on the slack-performance-is-a-disgrace train, but their web client is a great example of a well done SPA - it’s miles better than the app other than notifications.
Gmail really? The same one that takes 10-20 seconds on 5G to even show the loading page? What is it doing in that time? Loading emails or downloading an AAA game? It is not just a one time penalty either, you reload and get the same loading page again.
Just a few days ago I had to get an OTP via email and it was completely frustrating. No indication nothing, just a loading circle. The old MPA version was much better.
If it was built like we were in 1995, with tables and html 3.2 without JavaScript and just the old school inline attribute styles, it would be way more usable
Because less than 1% of actual SPAs use those things. Hell, look at HN's search page in the bottom if you want an example. You can load entire HN by the time it loads up and searches something.
Prefect example of the sufficiently advanced compiler argument.
HN's search is hosted on Algolia, and is not a part of the HN "App".
Hacker news is not a SPA.
Algolia's search is a SPA, but is perfectly utilizes the search so you can refresh a page (besides the error that they don't use page-based search), and is largely indistinguishable from a non-SPA site.
> You can load entire HN
You obviously have not context what so ever on how much content is hosted on HN.
I think this article is unfair to SPAs. SPAs are a lot more effort, but they are better. For a long time they have been the only way to "make it feel like an app." (I think the author says "make it feel like an app" because they know we all resent app fatigue, all the apps we have to download that should just be web sites, but I think we also all know that when something really is an application, it's rare for a "web app" to match the experience of a local native application, and an SPA is the only way to make a sincere attempt.)
The comparison of bloated SPAs with lean web sites is bogus. If someone takes the effort to make their web site lean, they'd do the same with an SPA. If someone makes a slow, bloated SPA with megabytes of Javascript, they'd make a slow, bloated web site with megabytes of Javascript. I think we've all seen enough of the web to know this is true.
I click on articles like these because I've seen the effort that goes into a good SPA, and I'm interested in anything that would allow people to deliver an equivalent experience with less effort. All I see here is a tiny bit of cosmetic polish. Polish is appreciated, but this doesn't seem like something that would tip the balance between building an SPA or not. Am I missing something?
I'm sorry but what!? Have you talked to your users? The ones that actually are forced to use your app day in and out? They want functional back buttons, they want to be able to open any action in a new tab. No one who actually uses your product would prefer an SPA once the flash wears off.
Let me tell you as a developer who has been on both sides of things, developing server rendered pages and not having to worry about the server disagreeing with the client is the ultimate developer experience. Build a competent app that can serve full pages in .1 seconds and no one will care that your site isn't an SPA. They want a fast reliable site.
We did an A/B test of an old SPA app, and a modern re-write using SSR and server-rendered pages.
By every performance metric, the new app was faster.
But we kept getting user feedback that the new site was "clunky" and "slow", even though we saw that the p90 was much lower on the new site. Most of our users asked us to enable a toggle to let them go back to the old "fast" site.
I'm not sure if this is a universal experience, but I think a lot of other sites that tried the CSR -> SSR move had similar experiences. It's just harder to talk about, since it goes against the usual narrative.
SSR can feel worse than SPA if you don't get the end-to-end latency under a certain threshold. If your SSR pages are taking upward of 100ms to render on average, it's going to start to feel like shit once you factor in the network latency.
My design goal for modern SSR pages is 500 microseconds render time on the server. A modern CPU can crank through several gigabytes of UTF8 text per second. There really isn't any excuse from a technology perspective. SSR pages being perceived as clunky & slow boils down to a skill / people / organizational problem. The computers and associated networks can definitely do it well.
Every single action should have no perceivable latency between the action and the feedback that the action was received. You can implement that with SSR but it is clunky and also requires a lot of JS generally.
Looked at the first one, and that's in a game setting? And they test 600 ms??
edit: The second one is more useful IMO. It's hard to get under 100 ms with a roundtrip, but < 300 ms should be doable, right? So you do lose the sense that you are directly manipulating data. In most cases I think that's a good trade-off. Exceptions would be things like Google docs, but that's also because it's a well made app I trust to actually sync my data without loss. Unlike most SPAs..
300ms for network latency both ways, with server potentially doing its own network calls for data to fulfill the request, interpolating the html, and then browser rerendering client seems like a stretch
I am curious to identify what your users are perceiving that isn't be being captured by your metric. If it is accurate and not just rhetoric that MOST of your users are asking for a rollback for purely performance reasons, that is a very extreme outcome.
Are your p90 metrics testing:
- navigation after first load?
- users who are going to the app after it is cached on their browser?
Are your actions going through server actions or rest apis? Do you have metrics on those?
What are you talking about. Majority of SPAs have abysmal performance compared to regular HTML rendered websites and that reflects poorly on user experiences.
I think if people remembered how productive you could be before the SPA frontend/backend split they'd reconsider. Being able to take a feature from A to Z without either context-switching between ecosystems or, even worse, involving other people, was incredibly productive and satisfying. Not to mention a much more streamlined dev env without a bloated js ecosystem of bundlers/compilers and whatnot.
I write an SPA for my day job. I write Postgres queries myself. I create endpoints and background workers and cron jobs myself, and I build out the UI myself. It’s all typescript with static types end-to-end. It’s a fantastic developer experience. Much, much better than I ever had in Rails or ASP.NET.
Also, I love components for UI as opposed to templates. And I don’t think I could ever really go back to the way I did things in my MPA days.
If there's no clear backend/frontend split wrt to language and roles in your particular project my point doesn't really apply for you. But it seems that you're lucky that you can use js on the backend to get closer to that. I would still prefer to not have to do a SPA unless obviously required for the job, but at least you got some of the fundamentals in place to be individually productive.
Performance - For pages that have different content for every user, the best performance will be reached by caching the app code on the client, only loading the data needed to render, and rendering once on the client. Rendering on an aws machine that is weaker than my 15 year old macbook is not a recipe for good performance.
User Experience - Every single user action should have no perceptible latency between the action and the feedback that that the action was received. This can't be done gracefully without javascript. Moreover, SPAs enable a better ux by enabling developers to build complex features that wouldn't be possible on traditional webpage.
This argument is tired and ignorant. Try building linear.app without a SPA framework. The idea that "Native CSS transitions have quietly killed the strongest argument for client-side routing," is dubious at best.
This doesn't seem fair to say. Linear is special even among SPAs; it's by far not the norm. No one said "ban SPAs and remove javascript from the browser".
Linear's speed comes from being "offline-first", but I challenge you to name almost any other product in common usage that does it that way. It's just not common. On the other hand if I want to buy tickets I'd rather most of that website be SSR and do SPA where you actually still need it. Or forums, news sites, blogs, and informational sites.
There is so much out there that would be better developed with SSR and then use CSS to make it feel SPA-like than to actually be a SPA.
SPA means single page app. For example, Google docs, Figma, Google calendar, etc. Apps that use web technologies instead of being native apps.
A long time ago some webdevs started abusing the SPA concept to build simple websites. However that is not within the original meaning of the term SPA, because simple websites are not web apps. The author assumed that everyone would just understand that they are talking about SP"A"s and not SPAs, because for a certain subset of webdevs working on websites, the antonym of SPA is MPA, and it's normal to refer to your website as an "app". However for a certain other subset of webdevs, the antonym of SPA is simple website, and what the author is talking about are not SPAs at all.
This article is getting a lot of pushback from the SPA champions, deservedly so, but it makes some good points to. I can’t be the only one, but I myself am getting very tired of the amount of websites where I have to sit and look at a skeleton loading for way too many seconds, then the data loads and it looks nothing like the skeleton. There is an over abundance of really crappy SPAs out there. Sorry not sorry
I thought about your comment, and IMO the reason some (or most) SPAs are badly built comes down to the inexperience of developers and hiring managers. They don't know much about performance, they don't measure it, they don't handle errors properly, they ignore edge cases, and some are learning as they go.
Bottom line: they build the SPA, but leave behind a terrible UX and tech debt the size of Mount Everest.
Yeah, of course. But I was thinking more from a user experience point of view. MPAs usually render pages server-side, which cuts down on frontend dependencies and expertise. That's why companies used to hire experienced engineers for the backend, and CSS/jQuery devs for the frontend. It used to make sense, but not anymore. These days, apps built with MACH architecture rely heavily on client-side code. This means companies are supposed to hire experienced engineers to architect apps on the client side but instead, they end up hiring JS devs with little to no software architecture experience. For example, I've seen SPAs that don't log any error messages from the app, which means developers have no idea what problems users are running into.
SPAs are not about view transitions. TFA implies that fancy transition is important between pages (wrong!) and blames a "CMO" or "brand manager" rather than challenging their own preconceptions and exploring the value an SPA does add:
- excellent frameworks for client side logic (interactivity)
- separation of concerns (presentation logic vs. backend)
- improved DevEx => inc. speed of development => happiness for all
The sad thing is that an article like this will get plenty of eyeballs due to comments like my own adding to the algo, but it should have never made it above the fold.
It's because it's catchy and repeatable, which really fits with this guy's broader claimed focus (SEO). I found it really ironic because I've built plenty of SPAs without page transitions of any kind (because it wasn't a relevant requirement) and only started adding them because view transitions made them easy.
For anyone looking to use this, I recommend using this CSS before the closing body tag. It disables the fade effect for visitors who prefer reduced motion, and the old page fades out while the new one fades in. (I've got an optional rule that keeps my header in place while the rest of the content fades out/in)
The View Transitions API is beautiful and I can't wait for it to become widely available.
I've soured on SPAs in the past few years. So much more can be done with standards than people realize. SPAs were best for specific use cases but we made them the default for everything. Marketing pages are built in React! Basic pages with marketing copy have a build step and require hundreds of megabytes of dependencies.
Like the author I've transitioned to a mantra of "let the web be the web."
But we have a whole generation of developers and designers that have come of age with SPA and mobile-like ux as standard. Getting everyone back to basics and understanding hypermedia, markup languages and cascading styles is a big ask.
I once worked at a place where (for involved reasons not worth rehashing for this conversation) some of the backoffice, admin pages got rewritten in SPA fashion, after they had already been written in server-side fashion. It was an accidental experiment that showed me that the backend code did not decrease in size, whereas the frontend ballooned up to the same size as the backend (for fairly simple functionality even).
Now, this means you will need approximately twice as many developers. On the plus side, more work gets done on the client-side, so you probably need fewer servers for your billion users, and you may save in servers (and sysadmins) more than it costs you in developers to handle approximately twice as much code.
Except...99.9% of the shops using SPAs don't (and never will) have enough traffic for that tradeoff to make sense. The devs want (or at least wanted, back in the day) to go work at a company that did, so they wanted to use tools that would make sense if you're Facebook-sized. But, for the great majority of shops that made SPAs, there was no good reason to do so. This isn't Facebook's fault, but it is a reason why SPA's are annoying to so many people; they are almost always used in places that don't need them, and shouldn't be using them, in order to pad out a resume.
Cost is one factor, but what about user experience? Rich front-ends that users spend a lot of time in can save them time and the company money. Case in point, I work at a company where one team works on the front-end for customer support employees. They have to run through certain legal processes from time to time, like sending customers emails with contracts and the like, or looking up various data from various services. Their efforts have helped save these agents a lot of time, and part of that is putting more and more into a rich, clear and convenient front-end.
Of course, a lot of the effort also went to tying together various systems, replacing outdated ones, developing smarter and better chatbots and voice bots to guide users towards answers or self-service, etc.
I completely agree that SPAs are overused, but I also disagree that they necessarily balloon in size. An SPA is supposed to be a view, it is only supposed to concern itself with view logic. People just overcomplicate them endlessly with unnecessary crap.
For me the promise of SPAs has nothing to do with fluidity and all to do with having a separate data API and separate frontend (that can be native or web or both)
That’s why I don’t like SSR mixed with client side rendering. Either do a website or an app.
I don’t want to write an article but I think when SPAs are called for they are the least worst option.
Usually I want to ship an app to customers, but for that I need an app the targets Apple platforms, hopefully I can built it to target iOS, iPadOS and MacOS but maybe those are three different apps. I need an app that targets Android. I also need an app that targets Windows, and I need a linux app.
Then I need to distribute all those apps, so I need to get onto the AppStore for MacOS, the play store for linux, and whatever Huawei/other Chinese manufacturers use, and whatever amazon uses, and probably have an “official” APK available for stuff like fdroid.
I need a windows installer, maybe a portable package for windows, and get onto MSStore (which will then cover winget).
I need to pick some collection of linux distros to target, usually targeting having a deb release and rpm can be good enough. And you can build an “installer” yourself if you are so inclined.
Or I could just ship an SPA, I had to build out the same servers if the data was not local anyway.
There's still value in web applications what can perform most of their operations client-side, when feasible. Lots of websites seemingly operate under the assumption of "If the client manages to connect to the server once, then surely it can maintain a stable, low-latency connection in perpetuity." This renders those websites unusable on flaky connections or with very high latency. Of course, plenty of SPAs are guilty of using 15 million unnecessary round-trips, but I worry that the current SSR-everywhere push will worsen this effect.
Consider also the origins of SPAs and their accompanying backends - mobile apps. I've worked with various projects where both web and mobile frontends would be using the same backend.
In theory you could build a SSR on top of that same backend, but for some reason that feels wrong, like an extra layer of indirection.
This works for some websites, not all. And often it results in significant loading times, because you're loading tons of unnecessary data. In many cases it is much better to send requests more frequently, similarly to how a server side rendered website would behave.
Instead of fetching 10,000 products, just fetch a page of products. Much faster. Have endpoints for filters and searches, also paginated. This can be fast if you do it right. Since you're only sending minimal amounts of data everything is fast. The server can handle lots of requests and clients don't need a powerful connection to have a good experience.
Network requests themselves are not slow. Even a computer with a bad connection and long distance will probably have less than 500ms round trip. More like 50 to a few hundred at most. Anything beyond that is not the client, it's the server. If you make the backend slow then it'll be slow. If you make the request really large then the bad connection will struggle.
It's also worth mentioning that I would much rather deliver a good service to most users than make everyone's experience worse just for the sake of allowing someone to load the page and continue using it offline. Most websites don't make much sense to use offline anyway. You need to send some requests, best approach is simply to make them fast and small.
> In many cases it is much better to send requests more frequently, similarly to how a server side rendered website would behave. Instead of fetching 10,000 products, just fetch a page of products. Much faster. Have endpoints for filters and searches, also paginated. This can be fast if you do it right. Since you're only sending minimal amounts of data everything is fast.
This is actually a great example of what I mentioned elsewhere about how people seem to have forgotten how to make a SPA responsive. These are both simpler implementations, but not really the best choice for user interaction. A better solution is to take the paginated version and pre-cache what the user might do next: When the results are loaded, return page 1 and 2, display page 1, and cache page 2 so it can be displayed immediately if clicked on. If they do, display it immediately and silently request and cache page 3 in the background, etc etc. This keeps the SPA responsive with few to no loading spinners if they take the happy path, and because it's happening in the background you can automatically do retries for a flaky connection without bothering the user.
This was how gmail and google maps blew peoples' minds when they were first released, by moving data to the frontend and pushing requests to the server into the background, the user could keep working without interruption while updates happened the background without interrupting their flow.
Yeah you can do that, but it's not necessary. You'll have to figure out a clever way to first wait for the data the user actually needs on the first load, then silently cache the other stuff in the background. Then you'll have the best of both worlds, but it complicates the application. It might make sense for Gmail and google maps, but there are a lot of web apps for which it does not make sense to put the work into this.
> Network requests themselves are not slow. Even a computer with a bad connection and long distance will probably have less than 500ms round trip. More like 50 to a few hundred at most. Anything beyond that is not the client, it's the server.
Not if the client is, e.g., constantly moving between cell towers, or right near the end of their range, a situation that frequently happens to me on road trips. Some combination of dropped packets and link-layer reconnections can make a roundtrip take 2 seconds at best, and upwards of 10 seconds at worst.
I don't at all disagree that too many tiny requests is the cause of many slow websites, nor that many SPAs have that issue. But it isn't a defining feature of the SPA model, and nothing's stopping you from thoughtfully batching the requests you do make.
What I mainly dislike is the idea of saving a bit of client effort at the cost of more roundtrips. E.g., one can write an SSR site where every form click takes a roundtrip for validation, and also rejects inputs until it gets a response. Many search forms in particular are guilty of this, and also run on an overloaded server. Bonus points if a few filter changes are enough to hit a 429.
That is to say, SSR makes sense for websites with little interaction, such as HN or old Reddit, which still run great on high-latency connections. But I get the sense it's being pushed into having the server respond to every minor redraw, which can easily drive up the number of roundtrips.
Personally, having learned web development only a few years ago, my impression is that roundtrips are nearly the costliest thing there is. A browser can do quite a lot in the span of 100,000 μs. Yet very few people seem to care about what's going over the wire. If done well, the SPA model seems to offer a great way to reduce this cost, but it's been tainted by the proliferation of overly massive JS blobs.
I guess the moral of the story is "people can write poorly-written websites in any rendering model, and there's no panacea except for careful optimization". Though I still don't get how JS blobs got so big in the first place.
> Not if the client is, e.g., constantly moving between cell towers, or right near the end of their range, a situation that frequently happens to me on road trips.
Right, but how often is a user both using my website and on a roadtrip with bad coverage? In the grand scheme of things, not very often. I also think this depends on what the round trip is for. Maybe the 10s round trip is simply because it's a rather large request.
> I don't at all disagree that too many tiny requests is the cause of many slow websites
That's not really what I was saying, though I don't disagree with it. If you're sending multiple small requests then there are two ways to go about it: You can send all of them at the same time, then wait for responses and handle them as they come back. The other option is to send a request, wait for a response, then send the next etc. The latter option causes slowness, because now you're stacking round trips on top of one another. The former option can be completely fine.
But I'm not saying the client should be sending lots of requests. I'm saying they should get the data they need rather than all the data they could possibly need. This can be done in one request that gets a few kilobytes of data, you can fit 64kb in a single tcp packet. That's quite a bit of data, easily enough space to do useful stuff. For example the front page of HN is 8kb. It loads fast.
I'm also not saying you should use SSR. I do think that SSR is a great way to build websites, but my previous comment was specifically about SPAs. You don't have to send requests for every little thing - you can validate forms on the frontend in both SPAs and SSR.
Round trips are costly but not that much. A lot of round trips are unavoidable, what I'm saying is that you should avoid making them slower by sending too much data. And also avoid stacking them serially.
It's worth noting that the Speculation Rules API and the View Transition API are not stable in Firefox and therefore aren't supported by all major browser.
This browser compatibility gap is a crucial point - without Firefox support, these APIs can't be considered production-ready for sites that need cross-browser consistency, undermining the article's central argument.
For me, this is the key takeaway from the article, leveraging experimental browser extensions for preloading future pages. In other words, exactly what a properly thought-out SPA does.
This reads more like "ditch Next.js" for traditional SSR.
A good SPA has a lot of benefits. Because it can be interactive like a native app. It can only use those benefits, if it is interactive to some extent (like gmail or google docs). Smooth navigation is a very bad reason for picking a SPA.
What do you mean by 'interactive like a native app'? The article is focusing on two main parts of making things feel like an app: page view transitions and speed/preloading. To me, those seem like a big part of what makes a site/app feel interactive. And letting the browser do the work and having real URLs has other huge benefits I appreciate.
But agree that for things like GMail, etc, a SPA approach definitely makes sense. I just think most SPA sites I come across aren't in that category.
Those aren't the main parts of feeling like an app. Feeling like an app means taking an action doesn't load a new page. Feeling like an app means the concept of a page mostly goes away.
I guess that's my point. With instant loading thanks to preload and smooth view transitions, taking an action, while actually loading a new page, shouldn't feel like loading a new page. Should be indistinguishable from a SPA action.
At least that's the theory. There might be other tells that degrade the experience, but not sure what they are?
Imagine Gmail, ChatGPT, Slack, and so on as server side rendered websites, but with smooth transitions. This wouldn't work at all.
Let's take slack as an example. We had those chat websites 20 years ago. The thread was in it's own frame and got periodically reloaded. It's just bad UX.
I think you're using "single-page app as opposed to no or limited JS on the client" while an alternative would be "single-page app as opposed to multi-page app". There's no reason you have to implement something like Slack by reloading an iframe.
I would argue that the line between an SPA and not is blurred. Consider progressive enhancement; or, per the Slack example, pages with content that's updated dynamically but which rely on reloading a whole page for navigation.
I would even argue that passing snippets of HTML around like e.g. Hotwire is still a middle ground.
I swear if I see another "SEO" guy or some rando web dev who joined the workforce after Covid complaining about SPAs by misrepresenting it, I'm gonna explode.
As someone who's been developing web apps since the 2000s, let me tell you the origin of SPA has few things to do with the "false promise of SPAs" he listed, but largely due to companies in the late 2000/early 2010s wanting to go "mobile first". This usually meant they still had a desktop second somewhere, which implied they were architecting the entire system to completely separate the frontends and the backend.
Before, what web devs meant by frontend was essentially server-side rendered HTML templates with perhaps a little bit of jQuery running on the client-side. Now, since mobile and desktop web apps are to share some business logic and the database somehow, people had to rediscover REST by reading Roy Fielding's Phd dissertation that inspired the original HTTP. This meant now every company was moving to service-oriented architecture and started exposing their backend APIs onto the open internet so their mobile apps and SPAs running in the browser can share the same APIs. This was a cost saving measure.
This period also coincided with the steady decline of full-stack webapp frameworks like Ruby on Rails and Django because for a couple of years, these frameworks had no good ways to support an API only applications. Django hadn't even reached 1.0 back then. This was a time when NodeJS was really starting to pick up momentum. Once people had started being more comfortable with JS on the server-side, lots of people suddenly realized they could push a lot of business logic to increasing powerful desktop browsers and phones, application hosts people now call "edge devices".
This is the true impetus of SPA. How is CSS going to kill this need?
I was completely unaware of view transitions and speculation rules. All of my products are server rendered for speed and simplicity. It’s amazing how snappy the interface is when your pages just load quickly because your software is performant. These seem like a great way to add an extra 10% of flavour.
SPAs are _applications_ folks. Just like app-apps are made -- spas are apps for the browser. SPAs in themselves are not complicated. State in an app is complicated. This is such a tired misunderstanding.
What counts as "SPA" and what's an "MPA"? I've got a NextJS site (my personal website, you can probably find it given you know my last name and that I'm in the UK) that renders pretty much everything server-side. Technically it's still an SPA because if you turn on Javascript it'll load RSC and do client-side navigation.
If you turn off Javascript? Pages with client-only components (like the 100% client-rendered QR code generator) will show their fallback, everything else will load and render perfectly -- if a little less quickly -- than if you let Next do its thing. It's all rendered into the HTML, and it's actually more effort to not render components on the server. Progressive enhancement for the win!
Sounds like the major complaint here is trying to make the web into something it's not. It's something like 17 years since the iPhone app store. Web apps were not comparable to native apps then, and while they've made progress, web UX is still much poorer than a good native app. The Youtube mobile app has its problems but is so much better than the web interface.
Native and web have different strengths, that's ok.
It's incredible to write an article about UX with a main argument of "this way is as good as that way" without visual examples to prove they actually behave the same.
Right, I would like to see some examples of what he is talking about considering his tone of voice - he is literally telliong people to change their ways and use modern CSS and the entire article is devoid of such css.
For who? In the modern day and age most devices can handle some JavaScript just fine. The DX provided by front end frameworks/libs is just unrivaled. Vanilla JS/jQuery work fine for small stuff, things quickly get out of hand in complex projects, when you have to bake in things like UX, validations, and have to program around the limitations of HTML. I'm confused as to why make such a claim as "Don't do SPAs for websites" and then throw in a dumb broad statement like "Just do vanilla". Yes, you can use CSS and achieve a lot of complex functionality. Yes you can use the existing HTML tags for a lot of things. Is it more maintainable than just using React? No.
You can't live in a silo. Yes, if plain HTML works for your website, why bother with anything else? Just do forms for any submit, input validation, there you go. But for a company competitive in the industry, particularly B2C SaaS, UI/UX does matter. And lagging behind, more than a trend, means customer perception.
We tend to be biased in our takes as tech-literate people (I do), but the average person gets lost if a button isn't emphasized enough.
A lot of website-in-spa break basic web stuff that simply works in old school HTML. It’s possible to do all that stuff correctly in react, but vast majority of people working on those simple websites seem to not give a damn.
Vast majority of information/portfolio websites have best UI/UX with classic HTML with some JavaScript sprinkled on top where it matters. Nothing says competitive-in-the-industry like contacts page that takes ages to load.
> The DX provided by front end frameworks/libs is just unrivaled
How? I spent 6 months exploring React, Vue, Node, Next,...
The DX for all of them sucks. The documentation sucks. Everything is wrappers of wrappers of npm scripts of wrappers of bootstrappers of boilerplate builders of...
Vite (build tool) + React is all you need, and a command line away from setting up React with TypeScript. If you don't like how "heavy" it is, you can use Preact. Similarly, for a Node (express) project, all you gotta do is `npm i express`, with additional setup if you want TS and other dev. niceties. Or just use a batteries included framework like Nest/Adonis and skip all that.
It's not that complicated, the frontend targets the browsers, so you have to transpile if you want to ensure compatibility, prevent theft, reduce the size, or not, and you could just wing it using the plain source code.
Again, it's the best for writing APPS. For an app, with complex navigation, features, UI states, it find it asinine that your biggest complains are about the packages.
A lot of people are responding with other technical considerations that may lead you to consider using an SPA pattern. But, note that the article is about responding to the stakeholder's request that it should 'feel like an app', and his point is that you can make it feel like an app without being an SPA. Non-technical stakeholders rarely bring up deep technical considerations, they almost always talk about what something should feel like. So, I think his argument, while unlikely to work on anybody, is valid.
I strongly disagree with this. SPA has its place and a very important one. It is not just about replacing JS animations with CSS animations. Of course it depends on the use case - SPA makes little sense in many cases and a lot of sense in few. But it still has it's stable place.
From my own point of view and experience, SPA makes the most sense when you do not want to bundle backend and frontend together in your server code. Having a separate FE and BE with clearly set API(json) is very important in many many many cases and it allows you to use the same BE for different FE, like desktop website, mobile website, desktop client(electron), mobile application... trying to do this on the server would be hell. Also worth mentioning is that if you want to make changes in your FE, you have to bring down you BE in order to deploy them, whereas if you have BE and FE separated, you can deploy the FE without any downtime.
There is a lot more that could be said but the main point is that moving data rendering into FE and letting BE just serve raw data is the way to go in many situations.
We have been moving computation between FE and BE for decades now, but I think the tech is now sufficient to not force us to pick one over the other but chose what works best.
Personally, I think that rendering the UI on BE is archaic and should be handled on the client via some bundled thin client code, ala SPA. So I will always prefer client-rendering over server-rendering, no matter the setup.
PS: You might be interested in https://data-star.dev/ which came out of dissatistfaction with HTMX and I think will be the way to go about bridging FE and BE in the future.
The main premise of this article is that SPA frameworks are primarily about transitions. This is yet another passionate argument built on a false foundation.
I agree. SSR that hydrates to an SPA is a pain in the butt and not necessary most of the time. This is why I favor something like Astro for websites... I can drop in a react embed when I need to. It's just a right-tool-for-the-right-job situation imo.
I absolutely love Astro, and it's my default for new projects. And I honestly feel like it's the only framework using React/Vue for their intended purposes; which is as an interactive layer on top of your SSR UI.
You're kind of already answering your own statement; websites should not be SPAs and vice-versa. Personally I think that an SPA should be something that lives behind a login.
I'm not a fan of the SPA, or at least in practice, but there is something very attractive about going with a solution that everybody knows.
At work we are building a new "website like" frontend and it is a SPA (that internally operates as a MPA) built with React. The main reasons are we: know this setup well and know when hiring we will find people who know this setup as well. Beyond that, it will allow us to build out more application like features in the future if needed.
This approach has been popular in the industry for over 10 years now. Whereas most of the current discussion and tech on the frontend feels like churn and betting on the next thing. A lot of people just want tools that are mature and can get the job done regardless of them being the best tool under specific criteria.
I support a lot of this, especially for sites that don't need to be applications... but SPAs aren't just about flashy transitions and persistent elements. If you've got a bunch of live data you want to change on interaction an SPA is still hard to beat.
I’d like to add to the reasons for why you want an SPA over something with SSR:
* You have a large number of users compared to your resources and you can’t afford for your user base to always hit your server. Comparatively, deploying API-only apps is far cheaper when you’re resource-starved (eg early stage startup).
* You don’t care about SEO, for example you’re building internal tooling. You then don’t need to care about hydration at all. Much simpler to separate concerns (again esp at the beginning).
* Offline mode (eg PWA or reusable code in Electron) or cases where you want to be resilient to network failures. In the case that your app is dependent on the server for basic functionality like navigation, you can’t support any type of offline mode.
It is possible to deliver a lite, PWA/SPA with vanilla JS and no loading spinners. Users can install it on their mobile device. I've done as much with blockchain dApp front ends. It isn't necessary to hijack the address bar or abuse the back button to achieve this. Modal dialogs, collapsible elements, tabs and simple anchor elements are enough. Yes, you can allow in-app back buttons to return to the previous modal's state, although that might suggest that the UI pattern should be simplified.
"State management" from a framework seems ridiculous. Developers should be able to handle their application's state with JSON objects representing reasonable abstractions of concerns. Typically, this would be similar to the data you query from the web. Therefore, upon launch, you can populate your document using <template> elements from cached data in localStorage or some of the newer options. When network connectivity is available, you can update the state using the same functions.
Perhaps this isn't something you would trust your large enterprisey team to do competently, but for a solo developer with a distaste for React and heavy frameworks, it seems like the obvious approach.
Interested to hear how others building sans frontend frameworks. If you love React and loading spinners by all means feel free to ignore this. To each their own.
On one hand, SPAs took off and became massively popular. On the other, I’m still curious why PWAs—especially the kind with service-worker-powered offline access—never really did. I don't like SPAs only if I find them bloated and with a messed up browser history that back button moves you out of the website.
Imagine an e-commerce site that lets you review your order history and product pages offline (even if a bit outdated). That kind of experience feels genuinely useful—much more so than the "you're offline, here’s a cute dog (I love the pictures though)" fallback most sites provide.
Over the weekend, I experimented with service workers for the first time (assisted by Vibe coding). My initial impression was honestly a bit magical—“this website works offline, unlike most mobile apps these days that are just WebView-wrapped SPAs and crash offline.” [1]
That said, debugging was rough. Vibe coding output had subtle issues I found hard to untangle as a newcomer, cache saved v/s cache matching was being done incorrectly in the code, which LLM wasn't able to point out (cors/non-cors requests had issue).And Chrome’s DevTools made debugging manageable, but Firefox’s service worker support felt clunky in comparison (personal take).
Curious if others feel the same—are PWAs underused because of DX hurdles, lack of awareness, or just industry momentum around SPAs?
Offline is good for things like your ball sort game or a calculator. But the developers of that sort of thing want to make money, so they sell apps in the app store.
Offline order history is only a marginal improvement on the e-commerce experience from a customer and business perspective, so it's more appealing to us engineers who appreciate it as a feat of engineering prowess.
In other words, offline isn't PWAs killer feature. Besides, native apps can do it too.
PWA's killer features are circumventing the app store and the app store tax and not maintaining two codebases for Android and iOS.
Another Hacker News client would be a good example of a good PWA that you might install to your phone. It could have niceties like "save for later" or special styles applied to your favorite commenters. Offline support would be useful too, of course but not the main reason to develop a PWA.
Uncensored, paid content is another significant use case.
> The reason SPAs became the default wasn’t because they were better. It was because, for a while, they were the only way to deliver something that felt fluid.
>The reason SPAs became the default wasn’t because they were better. It was because, for a while, they were the only way to deliver something that felt fluid – something that didn’t flash white between pages or jank the scroll position.
This was NOT the reason why.
SPAs are better because it offloads as much processing as possible to EDGE cpu's. The idle compute among all users aggregates to a massive amount so might as well use it and minimize html construction and routing on the server side.
I see some people claim that client-side routing isnt the strongest argument for SPA:s. And that is probably true from a technical point of view. However, lots of times users/clients want that even if they dont care about the rest (which is why I love how easy HTMX and Astro make it to add client side routing on top of a normal MPA).
The thing about SPAs is that computation can be done in the customer's machine. That usually makes it worse for everyone, both devs and users (although sometimes it doesn't). I personally believe that we can create better experiences routing more pages with more imagination, but at times this industry is quite vocal on what "user expectations" are.
My SPA navigation solution is just simple CSS toggle of display none/block and then force it on page load if there is a matching URL fragment. Total JavaScript to make this SPA navigation is about 20 or so lines of JS. Everything else is CSS and WebSockets. The state management is almost as simple.
But designers will always find a way to make our live miserably. They are told to never accept same behavior and always press users to there way of navigation and thinking. The bullshit they call design is there way of expression
Safari has supported this on both desktop and iOS since last year. But I had to look, because the article makes it sound like Chrome and its family are the only browsers that are modern enough for the feature. Safari uses WebKit, not Chromium.
"Modern browsers – specifically Chromium-based ones like Chrome and Edge – now support native, declarative page transitions. With the View Transitions API"
Not only SPAs are here to stay, but they're eating up native app on the desktop (with Electron et al., it's much easier to hire TS devs and write your app once rather than have different native codebases for Windows, Macos and Linux).
Now, I understand the argument that simple article-based websites shouldn't necessarily be SPAs. Page transitions are perfectly doable in pure HTML and CSS. But if you have less then trivial local state and complex + specific components, forcing the MPA pattern will only complicate your codebase.
It's time for sending HTML rendered on server with CSS, and JS for enhancement only to kill the SPA.
I'm not talking about this from a technical standpoint, though there are many reasons that in most cases this is the best technological fit.
I'm talking about this from the position of "what I want to use". I'm sick of loading and navigting overly JS heavy, overly styled, fragile "apps". When I encounter a "proper" website that loads fast, and I can understand easily it's like a breath of fresh air.
CSS, URLs, links, forms, POST-Redirect-GET, page reloads. Efficient and user friendly on the modern web. HTML & browsers have smoothed out a lot of rough edges.
Plus which, the author says that the next page will be conveniently pre-loaded when the user hovers over the link. Plenty of time there's ~0 hover time, especially for experienced users. So the user is still going to be looking at a spinner while the full page (which could be pretty beefy) is loaded in from the server.
it makes more sense than ever to deploy a semantically correct page with clearly distinguished templatnig, styling, animation logic and most importantly - data semantics. so that the robots and LLMs can slurp it without clicking too much. all the styling can follow in a very standards-compliant manner.
No, you found some tradeoffs and decided that the drawbacks are worse than the advantages. If industry disagrees, they tend to have their reasons, but as we love being tortured artists and really feeling our individualism, offbeat hot takes are always in demand.
Websites and apps that feel like quality are generally made by people who can achieve it. You'll get shit static sites or shit SPAs if you have shitty devs. It's not beyond reason. If you are shitty chef, your food is going be shitty. So yeah, here's the big secret about programmers:
They are mostly shitty
---
Interestingly, every landing page or website for recent AI apps have looked AMAZING. Designers and standard website developers are totally on point. It's just, crappy developers who can't create a rich experience on top of incredible design that's the issue. CSS is not going to fix what can't be fixed (some people are not supposed to be in this profession, but hey, it pays ... for another three or so years).
I don't know if CSS is underrated, but it's definitely a speciality that a lot of software developers don't (want to) specialize in. It's like the front-end equivalent of SQL; so much is possible in SQL, but most logic is built in application code because SQL is scary.
Most logic is built in application code because it makes it easy to structure, reason about, and test. Developers should be scared of code that is hard to test and reason about.
Most of my personal app projects are SPAs, because it’s easy to just pop some static files in my static file server and serve a whole app with routing and functionality without having any server logic. Way simpler to maintain, since I can just sync my ‘apps’ dir and all my mini-projects are deployed.
Not really... like sure if you want a static site, but I'm talking about static apps. Like if you want to handle /id/$id routes with data based on user-generated content saved in localStorage... you'll have to handle routing somewhere. Basically, what I'm saying is that if you have an stateful app that doesn't require server state, I think SPA+PWA is pretty ideal.
I agree. What is more, you can even use HTMZ instead of JS frameworks and Pure HTML Out-Of-Order Streaming using Declarative Web Components: https://github.com/niutech/phooos
what a nonsensical title, clearly written by people that only program skins around applications instead of applications themselves. CSS and SPA do not even solve the same problem.
I'm sure there exist (foolish) efforts to make CSS somehow able to do some UI logic, but that is never a good idea. CSS is a poorly made/overly complex spec that deserves to die. It's too late to make that argument unfortunately, but to want even more of CSS in the modern web stack is kinda lunatic.
If full page requests have an ability to persist complex state, cache to the point of imperceptibility parts of the page that aren’t changing and never blink, I guess?
SPAs and packaging your app inside a chrome container needs to die a hard death. Why is everything in 1 window. Why in 2025 can i not have multiple chat windows open?
i think this is good for websites but my current struggle with Astro is the long build times for a blog with many many pages. current build time is 10 minutes and it does not spark joy.
Everyone is completely missing the point of this article, which I find amusing and terrifying in equal measure.
He is _not_ talking about a SaaS dashboard SPA. He's talking about marketing sites and other content heavy stuff like blogs, landing pages, etc. It mentions this in many places if you go past the headline.
He is completely correct. SPAs should not be used for marketing sites full stop. Perhaps there are some edge cases where it may make sense (though I cannot think of any) but in general, if you are building anything that resembles a blog or landing page with nextjs et al you have done it wrong, close the code editor and start again. I'll give you a pass if you are developing an MVP of something and you need something up very quickly, but if you have any commercial traffic you will thank my later.
I have done a lot of audit work for this kind of stuff. Things I've seen:
10MB+ of React/JS libs to load a simple blog page
Putting images in the bundle, base64d. So badly that the page crashes OOM on many devices.
And my favourite of all time - shipping 120MB (!) of JSON down for a catalog. It literally loaded _the entire database_ to the front end to show _one_ product. It wasn't even an ecommerce site; it was literally a brochure of products you could browse for.
But even the most well optimized nextjs/react 'blog' or ecom site performs and order of magnitude worse than a SSR version, simply because you have to bring in runtime stuff? I'm giving extreme examples; but I've seen very very able development teams totally shoot themselves in the foot with this.
But even if you SSR them you still need to send at least 100KB (and probably far more) of JS down to the browser to hydrate state and handle any interactivity.
Fun fact: custom elements exist. They're just as hard to work with as React components (i.e. complete nonsense until you stop fighting them and do it right). Except they don't violate the browser model and don't require you to be married to a specific framework.
To be frank, I tried the cross-page fade transition on my Hugo static site, hosted on AWS ClousFront, and I couldn't see the difference. It's probably only relevant if your site is bloated to begin with.
> Native CSS transitions have quietly killed the strongest argument for client-side routing
Huh? We didn’t build my company’s product as a SPA because of transitions. We did so because it is a shared codebase with native and because it has an offline mode.
> Native CSS transitions have quietly killed the strongest argument for client-side routing
What? This guy wanted to show off how much he knew about CSS and decided the only way to do it was completely make stuff up about a hot-button topic in webdev.
Ok, now try to implement a tree component in an MPA. But not a crappy tree component that only opens one branch at a time, like in a page from 1998. A tree component that remembers the open/close state of each branch.
Before the SPA, these were common issues. That’s why there were a gazillion Java server pages frameworks to solve them. You also have frameworks that tried to encode the UI state in some way. My favorite was Seaside, which used continuations to store the UI state.
The following article should probably be titled “It’s time for modern bloggers to kill the clickbait titles” and discuss the trade-offs of each architectural decision more balancedly.
I wonder if my slop radar is oversensitive to em dashes and the construction: “it’s not just about foo, it’s about bar” because this post seems human written but the indicators are flashing
There are also many non sequiturs. The sentences only read fine if you don't think about what the author might be trying to say. I also think that this reads like the "author" was an LLM and, therefore, isn't trying to say anything.
À propos of nothing – I'm human and I like using special characters, including en dashes. ;)
Exactly. I remember the times when webmail clients were SSR applications. Roundcube and Gmail were game changers. Webmail finally felt smooth and usable.
Web shops are somewhere in the middle, they need a little bit of interactivity for the cart, especially if the user opens multiple tabs.
I was a JavaScript developer for about 15 years and I moved onto something else because most of the people doing the work can't program. Not at all. I got tired of being held hostage by people who couldn't function without more help than they needed.
I also get tired of the arguments from ignorance. The you don't know how hard life is type of bullshit arguments. I do know because I have done this work, probably much longer than you, and its not as challenging as you are claiming.
Add to it dev churn each 6 months one dev leaves an new joins full of fresh new ideas how to jquery. In the meantime also 2 freelancers adding their stuff.
Once again people totally miss the point of SPA. What does SPA stand for? Hint, there is no website in there.
Id argue all the grousing of spa is because people made websites as apps when they should have been websites instead.
Btw view transitions are pretty slick and require zero js to get snazzy transitions.
Edit: there are some significant limitations with view transitions around performance and a few other gochas I should mention when they are used with pure css. I still love em tho.
> Build a site like a site. Use HTML. Use navigation. Use the platform.
Sure, but what about all the other problems that aren't solved by View Transitions? There's some truth to the fact that frameworks like Next.js has jumped the shark. But they're not solving the problems of _just_ the SPA.
CSS is a mess for anything besides basic static layout. You can force it to do fancy things, but it's hacky and gives you code that doesn't really say what it does. You can do scss, sass, etc, but still eh.
TL;DR: article means traditional websites with server navigation (now dubbed MPAs, multi page applications) have evolved positively with better handling of page transitions. But they choose to frame this idea by trashing SPA, while both MPA and SPA have a role to play.
The problem is he's confidently wrong in believing Single Page Applications are about page transitions. Not at all. It's more about keeping state and an application-like experience. Like playing a song on spotify and changing to the search page and the song keeps playing... that type of thing.
Thank you for giving me a starting point to work with.
FFS, I have a degree in Civ Eng but if I start wittering on about bridges and roads I will define abbreviations. Its common courtesy.
With regards your analogy involving Spotify: I ripped all my CDs to FLAAC some years ago. The tapes and records took a little longer. No idea what a Spotify is. Well I do, I'm an IT consultant, but I don't actually care, I'm a 50 something IT consultant! I bought my music years ago and listen to it on my gear and from my gear alone.
This SPA thing sounds like it is getting out of hand and it also sounds like there are tribal divisions being drawn up. IT does love a tribe! We even have multiple internal tribes: devops, webdev and so on.
I tried something here: https://vtbag.dev
Took me a while to figure things out, but I'm happy to share what I learned.
That's why I asked: I would be glad to help with concrete problems.
SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.
Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolutely, if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.
But SPAs came about in the days of jQuery, not React. You'd have a complex app, and load up a giant pile of jQuery spaghetti, which would then treat each div of your app is its own little mini-app, with lots of small network requests keeping everything in sync. It solved a real problem, of not wanting to reload all that code every time a user on an old browser, with a slow connection, changed some data. jQuery made it feasible to do SPAs instead.
Later, React and other frameworks made it less spaghetti-like. And it really took off. Often, for sketchy reasons. But the strongest argument for SPAs remains using them as a solution to provide a single-load of a large code bundle, that can be cached, to provide minimal network traffic subsequent to the load when the expected session time of a user is long enough to be worth the trouble of the complexity of an SPA.
This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway.
What is the cause of this?
1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)?
2. Non-JS developers mystified and irritated at a bunch of practices they've never really internalised?
3. The undercurrent of "frontend is not real programming" prejudice that existed long before React etc al. and will continue to exist long after it?
I find myself agreeing with the article (although I also agree that it assumes you've chosen an SPA when you shouldn't have). To add my own perspective:
I work on an app, the front-end of which essentially consists of 6 nav tabs, 3 of which show an index of records with corresponding add/edit forms. We don't have any hyper-fancy interactive components that would require heavy JS libraries. And yet... we develop in React.
Yesterday, I needed to add 1 new field (representing by a checkbox input) to both our app and a corresponding back-end application we have, which uses Rails views.
I checked the git logs after to see how long each took. The Rails view took me literally 2 minutes to update (add field to model, add field to controller, add input to HAML with a class on the parent div). The React view took me 52 minutes, plus I later found out that I'd forgotten a damn type on some interface that's a shallow copy of our model.
Is this a problem with React itself? Not really. But it's a problem in the way that it's used, and our 6 nav tabs and 3 forms don't need all the overhead of React. So for people in a similar situation, this article really rings true.
> We don't have any hyper-fancy interactive components that would require heavy JS libraries. And yet... we develop in React.
Is React really a "heavy" library? https://bundlephobia.com/package/react@19.1.0
> The React view took me 52 minutes, plus I later found out that I'd forgotten a damn type on some interface that's a shallow copy of our model.
This sounds like bad architecture, nothing about React would necessitate this. And if your typechecker isn't catching missing types, then it sounds like your types aren't adding much value.
Whenever someone presents an anecdote like this, there is always someone who says “but then you are doing react wrong”.
Ok, so why is it possible to do it so wrong so often then? That sounds like a downside of the tool. It is a sharp knife. That doesn’t mean there is no place for react, but it also doesn’t mean we have to wipe it under the rug and pretend like it is everybody else’s fault.
I never read a story about it taking an hour to add a field to a form in Rails and it only taking 2 minutes in react. I’ve experienced the other way around for years though. So there is some truth to it. Let’s embrace the truth and look for what react brings us despite this.
> “but then you are doing react wrong”
My objection is not that they are doing React wrong, it’s that their complaint is incoherent because there is literally nothing about React that could make this task take an hour. React isn’t a form library. You write the markup for an html input element, if it’s a controlled input you have a trivial one-line change event handler, and you have a submit event handler. Any additional complexity here isn’t coming from React, and managing to overcomplicate such a basic thing and misidentify the source of the complexity absolutely speaks to a skill issue.
This is especially funny in a thread where posters hold up Rails as a paragon of quality and efficiency.
> Is this a problem with React itself?
React is far from the best tool for most jobs (if any), but it has a shitload of inertia.
I can highly recommend looking into Lit (used to be Polymer): https://lit.dev/docs/
IMHO it allows just the right amount of encapsulation and structure, whilst building on W3C web components and being highly interoperable with other javascript libraries/vanilla code. It's pretty much what web components should be out of the box.
People absolutely use technologies poorly and make things harder than they should be.
At the same time, the part of the program that interfaces with the physical world (e.g., people) is always going to be far more complex and thus harder than the bits that get to live entirely inside the computer world.
I'm sorry but that just sounds like a tooling and skill issue? Adding a new form field takes me a grand total of 5 minutes in the Vue app I maintain at work, and I'm a mostly backend focused fullstacker. We have the form/input components, adding a new field to a type is trivial (and we generate those automatically based on our BE schema anyway), error handling is handled by our form/input components.
Also, I'm not the biggest fan of React and think there are options that are a million times better like Vue & Svelte, but React is not heavy. Yes, JS frontends pull in a lot of libraries, but React (or any other framework except for probably Angular and Ember) is far from being the biggest or heaviest dependency in any project. In fact, especially React does this amazingly, React itself has 0 external dependencies. Usually people will also want react-dom, so for the simplest possible application, that's a grand total of 2 very lightweight dependencies, and for usecases like yours of a few forms, that's literally all you'd need.
Sure, maybe your 3 forms don't need React, but it sounds like you're actively adding stuff to it (and even caught a type issue from the sound of it). The non React version of this work would've entailed targeting a querySelector's inner `.value` key, and then having to parse it if it's not a simple string and safe guard against the element not being there, or targeting a shifting ID or class or all the other numerous and tedious problems that arise. Or, you stick a `v-model` on it, send it as JSON and call it a day, I categorically refuse to pretend the old universe pre-SPA frameworks was in any way a good way of working.
Just because you are comfortable with one technology and inexperienced or unfamiliar with another does not make one better than the other. How much rails have you written in your career? How much react?
I don't know that there's "real" programming, that seems like a hard fight to fight on either side, it's like arguing about whether animals are conscious or something. Are people? Who knows, pass the blunt.
But there's been this really sharp over-correction to where now an obvious thing that is just common knowledge and that was never taboo is now considered impolite to even allude to. Frontend programming is among the easier kinds of software work as measured by the number of people who can do it? I bet if I tried really hard, I could probably be pretty kickass at pickleball, small court, not a lot moving around. But to be like, that's the same thing as the NFL. No, no it's not. I would never have been able to try out for the NFL, not if I live a thousand times.
There's pickleball and pro football in programming too.
> as measured by the number of people who can do it
That’s a poor measure. It proves only that there’s a demand for such programming. I have programmed in tens of languages professionally and many more for fun.
Programming is programming. I haven’t found much difference in difficulty between any of the stacks I’ve worked with. Except, maybe C++, but that’s just C++ being garbage. I now happily use Zig as an alternative, and it’s no more difficult— easier in fact— than building a well-architected, complex UI application of any kind.
Front-end programming is easier in the sense that you can make little mistakes and your entire app doesn't fall down. As someone who's done decades of both, there's nothing conceptually easier about well-executed front-end programming over back-end. The stakes just aren't as high.
I think the argument might be that it takes less domain knowledge of hardware and all its abstractions, which does require a minimum threshold of reasoning and abstract thinking ability. I have high confidence someone who could built a database or kernel could also do front end work with a reasonable ramp up time.
I don’t share that confidence for the inverse in the nominal case
I have seen many backend developers with this mindset and approach, and; 1) Tricky parts of frontend are afaict equally tricky as building a DB/kernel/whatever. 2) A typical mistake is that a lack of knowledge about the hard parts of frontend makes backend'ers assume frontend is easy, while in reality it's their ignorance (and arrogance) rather than the subject being the issue 3) As with backend, most developers don't deal with the harder parts. Most backend developers I've talked to do simple CRUDing + minor business logic from a DB. Similarly very few developers try to write their own drag and drop library from scratch.
It's sad that so many seems to fall into the trap of 2).
(I've done both types of development for 20+ years)
I have no idea what backend developer means to this or that person. It seems to mean "not frontend", so like, directly interacting with a database and possibly using a compiled or even unmanaged language? But still often deploying through something that looks like:
Haswell <- Borg Hypervisor <- Borg Pod <- KVM Hypervisor <- QEMU guest <- docker-compose <- docker <- golang
?
I'm talking about hackers. I remember being like 24 and and a colleague of mine (legend) had never worked in JavaScript or really the web before was on our pod that got tasked with writing a browser for J2ME and BREW that implemented real web pages.
He goes home that weekend, and he comes back on Monday with a stack machine written in JavaScript (ECMA-262, we ran it on Rhino back then because Spidermonkey was a whole thing) that executed a very cute subset of JavaScript, including lambda closure and therefore Church encoding / untyped System 1. I was like whoa, why in JS? "If I have to implement it in a month, I'm already two months late to start learning it."
Is that guy a frontend developer? Backend? Full Stack? He had worked on DSPs and audio before, and on video codecs and embedded.
My comment above about some of this stuff is harder isn't a diss to anyone, it doesn't make me a millimeter shorter that Carmack is so tall, walking around in some rarefied air of genius I can't even formulate a picture of: it inspires me to work harder, try more ambitious things, push every day a little past yesterday's limit, and it has for more than 30 years now.
There's nothing wrong with programming be a job, it's a perfectly reasonable life choice and a very sensible one in light of life's other demands and opportunities. But some of us fucking love it, think about it all the time, live to be good at it. That's a different set of outcomes. And it does grate a bit to have everyone pushing this "it's all the same, we're all the same, it's one equivalent thing", that's my passion you're talking about, I take great pride in my life's singular ambition and pursuit. We're equal but we're not the same.
The backend has plenty of complexities, but frontend developers have to deal with something just as complex - the user.
Given ramp up time, most backend engineers could build a bad frontend, or build a good one if they have a really good UX team that thought through everything and are just implementing their work.
In the real world though where UX is understaffed and often focused on the wrong problems - I've had to rescue too many frontends built by backend focused teams to share your confidence.
It's also that you're at the top of the stack. If your stuff breaks, there's no layer above you whose stuff also breaks.
Well except the end user, but depending on the app they can often be low-priority (internal apps, apps with captive audiences like online banking or airline websites, etc.).
After looking over the author's blog I can see
1. Very high output
2. Lots of AI images
3. Weird writing and editing lapses in several posts
I am moderately confident this post was written with an AI. It may not be totally AI produced, I think the author has probably edited the work, but I think we are mostly debating synthetic content.
Most frontend development shouldn't be necessary as they're writing repetitive code that implements features that are missing from browsers. And it shouldn't be that hard to add those missing features to browsers. They're like half javascript at this point...
> Non-JS developers mystified and irritated at a bunch of practices they've never really internalised
My current explanation goes something like this:
"I'm a smart guy. Front end development looks simple. If I find it hard to do, that must be the fault of javascript somehow"
I started my career in FE and still consider myself a FE dev despite technically being a full stack dev.
Sometimes I'd be working with my team on something and they'd be like "why is this needed?" and I'm like "because javascript" or "because react."
While I agree with your sentiment that FE dev is certainly not simple, JS and front end architecture ad a whole does have its faults. That's why highly skilled FE devs who can build scalable, beautiful FE apps (whether using SPA or SSR) can be highly paid.
Note those are not mutually exclusive. It's entirely coherent to believe you find a tool hard to use for reasons relating to the tool itself, and that the task you're trying to accomplish is also difficult independently of that.
Analogy: imagine trying to give a good presentation with a horrible text-to-speech (or translation) system. Just because good presentations are hard that doesn't mean you don't get to complain about the program being terrible.
Yes, but now you're getting into "there are two types of languages, the ones people complain about and the ones nobody uses".
There are obviously flaws and issues and annoyances in js world, but a lot of those come from having to solve much harder problems (compared to say, do a sql query and turn the results into json).
I'll bite. In essence a user interface just presents the data it got from the server in some nice looking shape, and sends any edits and button presses back. Should be simple, right?
The "Just" is doing a lot of heavy lifting there.
Think about the presenting data part of it. Perhaps you have a table of data, prices of tickets or some such. You could literally just wrap each item in a <td> tag and each row in a <tr> tag and that would indeed be easy.
But people generally want and expect more. How about color coding the rows to make them easier to scan left to right or sorting the table by each column or paginating through more data than can easily displayed on one screen or maybe you're doing "infinite scroll" instead.
None of these things are impossible of course, and people have done them so many times and in so many different ways that there are dozens of libraries you can use and hundreds of tutorials, but even so, compare that to the "select from table turn to json" equivalent.
The SQL can be more than a bit tricky, but aside from that, JSON is extremely well defined and specified, even without a library you can just read the specs and do it. Wrapping it in a HTTP response and returning it and so on is likewise very well specified and if you can read, you can follow the instructions on how to do it.
Creating a UI that works the way a user wants to is the opposite of all that.
Of course, one of the major differences here is that at any point you can just stop improving the UI. Maybe you stop after wrapping it in the table html. The UI will certainly work, for a very specific definition of work. JSON is considerably more boolean. It either is a valid JSON document or it isn't. You can ask a computer to check for you. You can't ask a computer to check if your users enjoy using your table.
How does something like React help with any of the trickier UX problems you're describing?
I don’t know, I think reducing bundle sizes and bloated javascript in favor of built in support for view transitions warranted a blog post against one of the primary arguments for why SPA.
I agree with the author. I love React. I shouldn’t need two dozen more dependencies. We ditched server side for client side in 2010 for speed. Now that we have 200x more compute power, more powerful CSS, more robust html (with web components), we can go back to server side rendering and only send what’s required for the user at the time of action.
That is considering that front end dev is necessarily implying js, which is exactly the erroneous premise one should try to dodge.
Are we aligned with the claims in the article that a SPA architecture is not a suitable baseline architecture for content-focused sites with shallow sessions (low number of interactions)?
You miss the whole point and the author is correct about this:
Modern CSS is powerful, and HTML is the way to deliver web content.
Every web framework is _literally_ a hack to make the web something it isn’t. People who haven’t seen the evolution often pick up the bad habits as best practice.
For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. And then once you realize that JavaScript sucks you’ll minimize it.
Laravel is fine. It's not amazing. Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system).
What I find interesting though is the assumption that web dev is done by "JavaScript people", that even the best "JavaScript people" have no technical breadth, and therefore fester in a cesspool of bad ideas, unlike your median backend dev who swims in the azure lakes of programming wisdom.
Now, I've done plenty of SPAs, but I've also done plenty of other things (distributed systems, WebVR apps, metaprogramming tools, DSLs, CLIs, STB software, mobile apps, a smidgeon of embedded and hobbyist PSOne games). Which gives me the benefit of a generalist perspective.
One thing I have observed is that in each silo, there are certain programmers who assume they are the only sane group in the industry. They aren't interested in what problems the other siloes are solving and they assume any solution "over there" they don't understand is bad / decadent / crazy.
These groups all regard each other with contempt, even though they are largely addressing similar fundamental issues in different guises.
It's a social dynamic as much as any technical one.
> One thing I have observed is that in each silo, there are certain programmers who assume they are the only sane group in the industry. They aren't interested in what problems the other siloes are solving and they assume any solution "over there" they don't understand is bad / decadent / crazy
A lot of coders have realized there's social credit in trashing other programmers. I regularly see comments from people claiming to have a singular custodial spirit for their craft, unrivaled by their peers. There's obviously advantages to telling people that everyone else is holding it wrong.
Then their advice is
- Some niche trick that's completely irrelevant to most situations
- Something that sounds obvious and uncontroversial, but is so broad and vague that it's not even worth arguing about.
And I realize the irony of me making this comment. But I wish we'd get over this phase where everyone thinks they're an expert, and that every bad codebase or slow app was the result of someone who didn't care. I have yet to work with someone who didn't care about their code.
> But I wish we'd get over this phase where everyone thinks they're an expert, and that every bad codebase or slow app was the result of someone who didn't care.
I can only speak to my own experience, but it’s been this way for the entire 18 years I’ve been doing this professionally and I can’t see it stopping anytime soon.
I just ignore it and write off people who openly think that way. It shows a lack of experience and empathy.
It’s connected with the questions around occupational licensing of programmers, unions, and similar structures which would not be so much about getting paid more but about getting quality up, squashing bullshit, and getting our quality of life up.
Without a cohesive community, mutual respect, and recognition of a shared body of knowledge, we don’t have the solidarity to make it happen.
As for Laravel, I’d say people were making complex applications (Ebay, Amazon, Yahoo) in 1999 —- Google Maps were better than Mapquest, which drew each image with a cgi-bin, but many SPA applications are form handling applications that could have been implemented with the IBM 360 and 3270 terminal.
The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw. You need two handfuls of helper functions, for instance
to make forms which can be populated based on what’s already in your database. People never wrote down “the 15 helper functions” because they were too busy writing frameworks like Laravel and Ruby-on-Rails that did 20x more than you really needed. So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built.As for performance, web sites today really are bloated, it’s not just the ads and trackers, it’s shocking how big the <head/> of documents get when you are including three copies of the metadata. If you are just drawing a form and nothing else, it’s amazing how fast you can redraw the whole page —- if you are able to delete the junk, old school apps can be as fast as desktop apps on the LAN and still be snappy over mobile.
> The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw
Yes, I was there, I wrote and used these pages. It sucked. Things are better now.
> So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built.
Building a form with zero user affordances is not difficult. It just isn't good.
We absolutely know how the pyramids were built. You get a whole bunch of humans to move a very large amount of stone and then stack it up in a big pile. The reason nobody builds pyramids today is because we have better alternatives.
I've been in a happy place with React with some projects.
I've worked on some where it was valid choice but boy the annoyances, like not being able to test your components because you're on an old version of React where your test framework can never know when the last render happened because you depend on a large number of components which don't believe they'd run on the current react but probably would if you could just vendorize 30 or so packages and patch their package.json files.
Or depending on a test framework that refuses to look up components by class, id or selector because they want to force you to use aria, even when it doesn't make sense such as in three.js.
Or depending on a routing framework that doesn't get maintained, instead they've been through 7 incompatible versions of it which leaves me thinking that they didn't ever believe in what they were doing.
Or having to understand the internals of 5 CSS frameworks (including JS-heavy frameworks like Emotion) to handle all the components you've sucked in and still understand raw CSS through-and-through to fill the gaps.
I worked on one system which was frankly experimental at a startup that was doing two week sprints building a tool called "Themis" for building ML training sets. The thing was that we were always having to add new tasks and between Docker and an overengineered back end and front end it took 20 minutes to go from source code to being able to interact with the thing, so it took a 20 person team and lots of coordination between FE and BE engineers to do the simplest things.
I sketched out an alternative called "Nemesis" which grew into an HTMX-based system where it takes one programmer an hour to code a task and there is no build, and between Flask and the 15-or-so helpers it is easy. I've hacked it to be an RSS reader, an image sorter, and several other centaurs:
https://mastodon.social/@UP8/114887102728039235
this feels like a desktop app when I am on the LAN and loads well under a second on a mobile hotspot the first time and every time. The key is that the tasks are nearly completely independent of each other, there are no builds and no dependencies, so writing a new task can't break old tasks. That system has plenty of screens that use d3.js for awesome visualizations and if I wanted to make a task that did something complicated which would really deserve React or Svelte or something I could do it, again, without breaking the the other tasks.
> I sketched out an alternative called "Nemesis" which grew into an HTMX-based system where it takes one programmer an hour to code a task and there is no build, and between Flask and the 15-or-so helpers it is easy
My argument here is basically creating that is really, really hard, and there's no framework or library that will make it easy.
React and friends are a mess because they're dealing with hard problems, kinda like systemd or kubernetes.
Writing code that lives entirely inside the machine is a lot easier than having to interface with the messy real world.
> Laravel is fine. It's not amazing. Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system).
As opposed to Javascript, the pinnacle of tight standards and high quality performative code...
The same arguments that can be made against PHP/Laravel absolutely apply to Javascript equaly, if not more so due to the pretty well know shiny object syndrome issues that many JS devs get caught up in.
Every web framework is _literally_ a hack to make the web something it isn’t
This sentence is doing an awful lot of heavy lifting that doesn't fit with reality
Ya this is nonsense. The web is what it is.
You could maybe say "every framework is a hack to workaround protocols primarily designed in the 90's before we really understood the full application of the web"
The internet isn't the web, and there are plenty of applications who use those protocols just fine outside of the web browser. It's the html tech stack initially made for hypertext documents and resources that's been heavily upgraded to do web-based applications.
I would go as far as saying that the genius of the web is that it can grow, develop, be hacked, modified, expanded through technical and institutional means to be many things it wasn’t originally envisioned to be. Why is that a bad thing? Why is originalism a good thing?
Are you aware that nowadays you can write SPAs in dozens of languages?
It's an entirely different concept. It's certainly not the right technology for a news site, but days ago in a different place, there was for example the discussion about how an SPA and minimalistic API services fit a lot better with your average embedded device.
> Every web framework is _literally_ a hack to make the web something it isn't.
Not this old grumpy person take again.
Yes, the web is developing beyond delivering html content.
Even with Laravel you will write lots of Javascript unless you go for blade templates or that other templating thing. Javascript is also great for making the web interactive. Maybe the sheer amount of SPAs out there shows us what we really want from the web. Most things ppl use in their day to day life cant be built with HTML and CSS only
What 'other' templating thing? I'm assuming you're likely talking about either Intertia or Livewire. Inertia's more geared towards SPAs than Livewire though. Most Laravel devs tend to use JS sparingly - not everything needs JS.
Theres next to no reason why the vast majority of sites on the web would ever need to be heavily reliant on JS. Rendered HTML/CSS with JS being used sparingly for page functionality is a far better user experience. I'll never understand the obsession with JS for the sake of JS.
Yea Livewire, couldn't think of the name.
> Maybe the sheer amount of SPAs out there shows us what we really want from the web.
A distribution and installation system that works on almost any device?
Interactivity and a way to build experiences and applications. Not just passing documents back and forth
> You miss the whole point and the author is correct about this:
your comment is funny, because you are so wrong you aren't even aware how and why you are wrong. It's in "not even wrong" territory. I'll explain you why.
> Modern CSS is powerful, and HTML is the way to deliver web content.
Irrelevant. That's not why the world uses JavaScript frameworks. It seems you aren't even aware of the most basic reasons why the world migrated to SPAs. The most basic reasons are performance (and perceived performance), not only because the require less data to be moved around the internet but also every flow doesn't require full page reloads.
Also, classic old timey server-side rendered WebApps end up being far more complex to develop and maintain as you mix everything together and you are unable to have separation of concerns regarding how your platform is deployed and ran and how your frontend works. SPAs even allow your frontend team to go to the extent of handing your backend as if it was a third-party service, and some SPAs are even just that. There are plenty of CMSs out there which eliminate the need for a backend by providing all content needs through their commercial APIs. This makes webapppp projects greatly cheaper and simpler to finance and support as you can simply bother about developing and maintaining your SPA.
Lastly, those JavaScript frameworks you're trying to criticize also use CSS and HTML, by the way. So as you may understand your point is moot.
> Every web framework is _literally_ a hack to make the web something it isn’t.
You are clearly talking about things you have no understanding over. It matters nothing if you specify a DOM with a static file or procedurally. Updating only specific elements or branches of a DOM is a very basic usecases. In fact if you had any frontend experience at all you'd be aware that all mainstream GUI frameworks, including desktop, represent their UIs with a DOM.
So here you are trying to argue that frontend development is not frontend development just because you have an irrational axe to grind regarding a specific class of web development technologies?
> For thise JavaScript people, I recommend trying Laravel or Ruby/Rails.
If you hadn't already proven you are completely ignorant and detached from reality, this argument alone would leave no room for doubt.
> all mainstream GUI frameworks, including desktop, represent their UIs with a DOM.
If you call every hierarchy of visual items with some kind of layout manager(s) a DOM, then yes. Notably, the D doesn't really apply because GUIs aren't documents, and that's exactly why HTML is kind of awkward for GUI programming: it was initially designed for documents.
Edit: Sibling comment makes the good point that the main difference is that GUIs have mutable state while documents don't. I would add that GUIs also have controls to change that mutable state, which is a more superficial difference, but well, web-based GUIs are still extremely varied in their interaction styles, which not necessarily good.
Not the person you're replying to. I agree with a lot of what you are saying but:
> The most basic reasons are performance (and perceived performance), not only because the require less data to be moved around the internet but also every flow doesn't require full page reloads.
I can't keep a straight face at this one. If there's one thing the web isn't anymore, it's "fast." Presumably what you are getting at is server performance, because it's pushing all the work to the client.
Anyway there's a good talk on this - https://veryinteractive.net/pdfs/ceglowski-thewebsiteobesity...
> > Every web framework is _literally_ a hack to make the web something it isn’t.
> You are clearly talking about things you have no understanding over. It matters nothing if you specify a DOM with a static file or procedural
Don't be so dismissive. This is like the old anecdote about one fish saying to the other, "how's the water." The "something it isn't" is stateful. The web was not designed to be stateful, and every web framework is indeed a hack to work around that.
Thanks for dissecting all this nonsense. Although in all honesty, we may as well be dealing with comedy here: green account, recommending PHP and Rails in 2025 as if that's supposed to solve anything... we're being trolled.
Some of us have been building web apps since before Node.js existed, and we remember the problem that CSS was invented to solve.
> ...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.
Agreed. The article was a frustrating read. The author is an SEO consultant. SEO consultants likely have a heavy focus on marketing websites. Actual apps and not marketing websites do benefit significantly from SPA. Imagine building Google Maps without SPA. You can animate page transitions all you want, the experience will suck!
to be fair to both points:
he has a really warped view that SPAs are somehow purely about routing.
he does correctly point out that a lot of sites could and should be treated as sites not apps.
I agree with you. The author's point is that browsers have finally understood why some traditional sites were created as SPAs, which involves recreating some of the functionality browsers already offer today. But that doesn’t mean all SPAs should turn into MPAs now.
IMO it will be hard for some traditional sites to adapt to the new browser capabilities, since we've built an entire ecosystem around SPAs. The author's advice should've been: use the browser's built-in capabilities instead of client-side libraries whenever possible.
Also, keep in mind he's sharing his own experience, which might be different from ours. I've used some great SPAs and some terrible ones. The bad ones usually come down to inexperience from developers and hiring managers who don't understand performance, don't measure it, don't handle errors properly, and ignore edge cases.
Some devs build traditional sites as SPAs and leave behind a horrible UX and tech debt the size of Mount Everest. If you don't know much about software architecture, you're more likely to make mistakes, no matter what language or framework you're using.
I realised years ago there's no "better" language, framework, platform, or architecture, just different sets of problems. That's why developers spend so much time debating implementation details instead of focusing on the actual problems or ideas. And that's fine, debates can be useful as long as we don't lose sight of what we're trying to solve and why.
For example: Amazon's developers went with an MPA. Airbnb started as an MPA but now uses a hybrid approach. Google Maps was built as an SPA, while the team behind Search went with an MPA.
Even for basic sites, I tend to reach for an SPA because I never know when I'll be adding dynamic features, anything from basic showing / hiding of content, list / configuration-based rendering, or requesting data.
It's usually inevitable, so it's easier to scaffold a Vite template and get cracking without any additional setup. The time-to-deploy is fast using something like Netlify or Vercel, and then I have the peace of mind knowing I can add additional routes or features in a consistent, predictable way that fits the framework's patterns.
I'd hate to develop an MPA and realize after the fact that now I need complex, shared data across routes and for the UX to be less disrupted by page loads. Once you've dug that hole, you either have to live with it, or face a painful rewrite later.
The exception I often see is targeting mobile devices in low-bandwidth areas where larger application bundles take longer to load, but I have to wonder how often this is the target audience. I live in a place where mobile data speeds are horrible, and access to WiFi is abundant, but even so, I rarely have a situation where I *need* to load up a non-critical site on the go — and having apps pre-installed doesn't really help either when the data they're requesting is barely trickling in on mobile.
So this oft-used exception doesn't really make sense to me unless I learned why this is so critical for some people.
I agree. There's a rich ecosystem for building SPAs with MACH architecture. There’s no going back now, not even for basic apps.
For scale, this is the easiest approach. Teams can focus on their roles and specialize more, which leads to higher efficiency as team members build their rhythm and stay focused on what they're great at.
At my company, our React SPA uses just over 500+ components across maybe ~30 views, with many smaller components alongside many of them in the same files. Our bundle size is obscene, but our customers are using fast PCs on fast connections. Once it's cached, they're good -- and each new release is roughly every 2-4 weeks, so fresh visits are painless.
As for server-side rendering from RSC, Next, Nuxt, and SvelteKit, I'd say they're overkill in most situations. The amount of people deploying simple sites on Vercel using Next.js, not really using its features, is just silly (and costly).
But this is exactly the point of the article. That'd be like if I needed to build a car, I started with a rocket blueprint in case I also need to go to space in the future.
The cost of speculating a highly interactive site that users will want to interact with is a suboptimal baseline experience until you get there. Provided you get there without losing users, it'll still be a subset of your audience that use your thing in a way that truly offsets all of these costs. If that works for your product/business, then awesome! But if these costs are too high and will hurt your product, then you need to be a lot more deliberate about how you engineer it.
I typically approach the problem first and see what tools work best to solve the problem, rather than work backwards from my preferred set of tools.
> Once you've dug that hole, you either have to live with it, or face a painful rewrite later.
Based on the tools you mentioned familiarity with, wouldn't something like Astro be a happy middle ground? You start as an MPA by default and only add complexity to parts (entire routes or parts of a page) of the application that require it? Also, this hole goes both ways. If you've built your site as a SPA, and you realise that your product just needs to be HTML to stay competitive, it's a painful road to unpick the layers of abstraction you've bought if you don't wanna rewrite it.
> dynamic features, anything from basic showing / hiding of content, list / configuration-based rendering, or requesting data
What would a highly dynamic feature be in your opinion and how does a SPA framework help you? All of the examples mentioned here, in my opinion, are fantastic candidates for server side templating and progressive enhancement. I don't need see the need for the SPA architecture here.
> mobile devices in low-bandwidth areas
Curious to know what kind of devices are present in your area? The implications of larger applications is both network and CPU [1], so if you live in a relatively wealthy area (say over 75% of users had iPhones) you'd notice the negative effects of too much JS less. If you're in the public sector or building for the public, then you can't get away with the excuse that people on slow devices and networks aren't your target audience; you need to meet everyone where they're at. A HTML-first architecture is a better and more inclusive baseline for all.
[1] https://infrequently.org/2024/01/performance-inequality-gap-...
> wouldn't something like Astro be a happy middle ground?
Absolutely, but it is additional boilerplate I have to worry about that serves as another layer alongside whatever SPA framework I prefer; whereas spinning up a Vite template with Vue, writing a few routes + components, and getting it built + deployed is easier. It's at such a low cost (bundle size, time, boilerplate) that the optimizations gained from Astro aren't even in my purview unless I'm experiencing a significant enough scale that justifies static rendering.
When my apps are feeling and behaving perfectly already, why optimize? It only comes with increased scope and cost to bend around another layer.
> If you've built your site as a SPA, and you realize that your product just needs to be HTML to stay competitive
This does go both ways, yes, but with SPAs, I have more flexibility around client-side features like transitions, animations, pagination for smaller datasets, and state-based views that depend on a lot of different interactions, user selections, etc. that all drive what gets displayed instantly, without making a single network request just to complete the interaction. The Venn diagram between the two shows SPAs doing more out of the box, at such a low cost to commit.
Whereas with MPAs and server-side templating, a better-feeling UI isn't a luxury you can enjoy without some form of JavaScript to wire up page interactions. Given these are often a requirement, you'll find yourself haphazardly adding an SPA library to an existing MPA to enhance the perceived UX that it couldn't provide. Then you're not only juggling 2 scripting languages, but also reconciling the separation of concerns between your client/server now.
Although, happy-mediums have emerged: 37signals created Hotwire to help bridge this gap, Laravel has a similar library Intertia.js, and htmx+Alpine is another interesting solution.
Lastly on this point, Svelte's build step strips your SPA into the smallest possible runtime. Svelte was actually built for creating SPAs intended to run on low-power devices [1] typically seen in places like LATAM. React also has an official compiler that memoizes component data and callbacks. Preact is a 3kb alternative to React (40kb) for low-power devices, sharing the same APIs with only a few minor differences.
React, Vue, and Svelte all have server-side rendering where you can comfortably write sites/apps that serve up smaller bundles and stream updates to the client as needed, without sacrificing a pleasant UX. So, to answer your question "what if your SPA needs to be HTML to stay competitive?" -- these are all the most sustainable paths with the lowest costs.
>> You may be asking, "why don't you learn + use some of the alternatives you listed?"
As any reasonably tired, middle-aged engineer would say: I'm happy with the language(s), tools, libraries, and frameworks I'm comfortable using. The incessant drive to learn new tools that pretty much do the same thing with dubious (and likely negligible) benefit at smaller scale feels like a distraction when I could just be building and shipping something with familiar tech that thousands of other developers enjoy using. I also benefit from the community support as well, not to mention, AI tools are best used in TypeScript codebases currently.
Server-side templating requires dedicated hosting / VPS, which is a whole 'nother layer of deploying, managing, and debugging. Static sites and SPAs can be hosted with a static host for free (unless you scale like crazy), and any data-related needs are solved with serverless services like Supabase, Convex, lambdas/functions, and any number of others -- all with generous free plans and some level of portability.
In my case, I'm only developing SaaS applications not needing mobile support, that are only used by companies that buy decent computers for their employees. Otherwise I'm building small webapps for personal use and some that may become a hit among niche communities. Even my personal site is a tiny Vue app, and only because it's familiar and easy to change. The performance fiends can cry all they want that it isn't purely static, and in many ways, that amuses me.
[1] https://developer.mozilla.org/en-US/docs/Learn_web_developme...
SPAs are about APIs, and leaving the rendering entirely to the client.
It's a reimagination of ye Olde three tier approach. Perfect for apps.
I 100% would like to see an MPA Google Maps.
Being able to come back to a webpage with previous directions? I think it would be glorious.
You are mixing up linkability/history and being an MPA/SPA.
Many websites simply have some session/state dependent page.
Google Maps cant even preserve state in their iOS app.
They are either the worst developers in the world or it is not simple.
I don’t rule any of the two possibilities out.
Some things you get for free with the correct architecture. For whatever reason, SPA does not have a great track record with their users.
> They are either the worst developers in the world or it is not simple.
Or they have a good reason to not do it (in some PMs mind).
At a guess, resetting the view, and displaying the nearest Domino's Pizza sponsored highlight pin on the map, could be one of them.
My biggest gripe with Google Maps is when I pan to a specific area, hundreds, or even thousands of miles from my current location, then search for something like “restaurants” and it pans me back home and searches there, so I then have to go find my distant location again and click the search here button.
If this is an intentional choice, all in an effort to show me more local ads… ugh. I really hope this isn’t the case.
Google Maps makes it really hard to explore your travel destination, or I am holding it wrong. That and the lack of weather integration are my main issues with it.
I hate that too. Even when it is just across the one city, it is a major pain in the ass.
I have one of those!
https://datasette-tiles-demo.datasette.io/-/tiles/basemap?no...
I wish I could take full credit but it was a PR by dracos: https://github.com/simonw/datasette-tiles/pull/16
The author states that MPA are not a solution for everything. Sure google maps don’t fit the MPA model but I’ve seen a lot of projects that would be much better using current browser features instead of react.
the web app already supports history navigation.
that has nothing to do with an mpa
these days there's a "copy link" button for directions which you can save / share
Google maps is a mess these days. Its glitchy, slow, has broken navigation, and is overloaded with unpredictable dynamic content. It's even worse in the native android app. Id totally go for the original version but with the more recent vector maps.
The reasons it sucks are nothing to do with it being an SPA, though.
Being an SPA is certainly the cause of the glitchyness and slowness as complex content dynamically loads and shifts around. It's also certainly the cause of the broken navigation, just like the original article explains.
> Being an SPA is certainly the cause of the glitchyness and slowness as complex content dynamically loads and shifts around.
Incorrect.
> It's also certainly the cause of the broken navigation, just like the original article explains.
Also incorrect.
The Google Maps app is also total garbage. It’s not an SPA, so that’s clearly not the cause.
> and load up a giant pile of jQuery spaghetti
I'll have you know I spent time on organizing and structuring my code with early JS design patterns like IIFEs to limit scope, lazy loading of modules, and minification.
Anyway, in my experience, AngularJS was the biggest attempt at making structured front-end applications, and it really appealed / appeals (Angular is still very popular apparently) to Java developers; biggest ones was its modularization (which wasn't a thing in JS yet), dependency injection, and testability.
When we started out with an app in Backbone (to replace a Flex app because it wouldn't work on the ipad), I actually advocated against things like testing, thinking that the majority of functionality would be in the back-end. I was wrong, and the later AngularJS rebuild was a lot more intensive in front-end testing.
Of course, nowadays I'm repulsed by the verbosity, complexity and indirection of modern-day Angular code. or Java code for that matter.
Angular not only appeals to Java developers, it also appeals to .NET developers. TypeScript of course borrowed a lot from C# (having the same designer) and dependency injection, MVC patterns etc closely resemble .NET patterns.
Interestingly, new Angular is slowly moving away from these, introducing Signals for state management and standalone components, and I see these developers actually struggling a lot to adopt new Angular patterns.
Still, I believe Angular is a really great platform for building B2B or enterprise apps. It’s testing and forms handling is far ahead of every other SPA, and it actually fees like a cohesive framework where people have spent time designing things the right way; something I absolutely cannot say about react frameworks such as Next.js or Remix.
Angular was created so Java developers could create browser apps
Angular 1.x seems vastly different than Java. I doubt a Java developer would want to use it, so I'm not sure your claim is valid.
PS and I forgot to mention, new Angular patterns such as Signals and standalone components great cut down on the boilerplate and the verbosity. It’s not (and will never be) something like SolidJS, but each new version is clearly moving away from the heavy OO-based and multi layered patterns.
Wasn't there the Google closure compiler before angular?
And GWT which allowed literally running Java on the web (without a plugin, it compiles Java to JS). It still exists and is maintained but not a Google project anymore despite the name.
https://www.gwtproject.org/
Low-bandwidth/spotty connections (combined with aggressive caching) are one of the strongest cases in favor of SPAs (emphasis on the A for Application, not website). Visit (and cache) the entire frontend for the app when you have a good-enough connection, then further use of the app can proceed with minimal bandwidth usage.
It really depends. There’s a lot of SPAs which are practically unusable on a bad connection simply because it’s a challenge to even get the whole thing loaded in the first place. There’s been several occasions where I’ve had poor cell connectivity and a huge chunk of the web was effectively off limits due to this.
So in addition to aggressive caching, I’d say keeping the app’s file size down is also pretty important to making it useful on poor connections. That’s frequently something that’s barely optimized at all, unfortunately.
I work on an SPA with hundreds of screens. We package it using off the shelf tooling with barely any configuration. All of the code and styling is still far under a megabyte gzipped.
So unless it is an all text app, the size of the code bundle is probably going to be quickly dwarfed by the size of media like images, animated images, or videos.
If a site has an SPA with a, say, 3mb code bundle, I think in most cases, that’s not an architecture issue. It’s probably an issue of poor engineering and switching to a MPA is not suddenly going to make those engineers competent.
Check out how bloated is MS Teams web app, for instance.
All three comments to this thread have missed the point that OP said installable SPA, not website SPA. This means the primary bundle is downloaded offline and only API network requests are necessary.
This is not true. In practice SPAs break completely when some network request fails which happens a lot on bad connections.
Sadly the art of error handling is often neglected by some SPA developers. I suspect that failures on the client are also less tracked this is tolerated by businesses.
That has nothing to do with them being "SPA developers". They are just bad developers, lazy, or inexperienced.
Errors/messages/warnings is one of the first things I do in an app framework, since it's incredibly hard to "bolt that on" later.
I think with brotli over SSE you can do just fine with 3G and bad networks without needing to be a SPA. Keeping almost all state on the sever make realtime collaborative apps much simpler than data sync you need with SPA. This demo has zero client side state and handles concurrent interactions over a billion data points [1].
- [1] https://checkboxes.andersmurphy.com
Latency might even be more relevant than bandwidth. Especially if it's a good SPA, that uses optimistic updates (or sync), and some kind of caching for fetching data (tanstack query or similar).
Honest question: Where are the places with low-bandwidth internet? Are we talking about cruise ships and satellites internet use cases?
Anyone attending a major event, or in a disaster zone. Things are getting better, but if you live near a ball park or something, there will be periodic times when your cellular Internet is unusable
Also, anyone traveling on a train or motor vehicle will just sometimes have worse reception, particularly with anything like a tunnel.
TBH even in the SF Bay Area "tech capital of the world" you'll find areas with spotty reception.
https://www.reddit.com/r/bayarea/comments/1cqhr4i/what_is_up...
Crazy hills will do wireless in anywhere. In a rural area I am maybe a mile from the tower as the neutrino flies but a photon can’t make it. I have a bar of 5G in the pasture in front of the house but in the house it promises a bar of LTE but whether I can get out a text (w/o WiFi) depends on atmospheric conditions.
Out in Cali they have ring of fire conditions.
Too much crowding can do it too. A decade ago I was going to Cali a lot and thought it was funny to see so many ads for geospatial apps on TV that always showed a map of San Francisco when for me SF was where GIS went to die. Taking my Garmin handheld to the roof of the Moscone center because it was the only place it could get a clear view of the sky to sync up with GPS, so many twisty little streets that routing algorithms would struggle…. Being guided around to closed restaurant after closed restaurant and walking past 10+ open ones because a co-worker was using Yelp, etc.
Back around 2001 I visited South Carolina, and it was like being transported to the future of mobile internet. They had some kind of high-bandwidth cellular setup in the area that was far ahead of the rest of the country at the time, I think I recall it being around 20Mbit wireless. I was told the area was a testing ground for new tech. I was kind of shocked that somewhere that seemed so stuck in the past had such cutting edge tech deployed. I thought why is this not in SF??
I live in the middle of a major UK city, which is one of the most visited tourist destinations in the UK (if not the world). There are massive gaps of mobile coverage in the city - 5G is spotty at best, and it regularly falls back to much older protocols in the city. There are dead zones where you can literally walk 6 ft and drop to 0 coverage, and walk another 6ft and be on full blown 5G. Apps and sites like uber, twitter, Reddit, instagram all handle these awfully.
There are folks who work with US-based nonprofits, NGOs, and agencies who live all over the world, including regions where local internet access is either non-existent or very slow. Some US-based organizations they work with have had to set up low-bandwidth methods of communicating. Yes - sometimes geosynchronous satellites are the only connectivity available.
Often times my house. I live in one of the 20 largest metro areas in the US. There is a cellular dead spot around my house, seemingly from AT&T and Verizon. Phones work, but barely. Pages with high data demands become a problem.
All over the world, including the United States.
3 billions people live in places with low-bandwidth / unreliable / expensive internet
There is this post about a experiment on google where they reduced the page weight and the traffic went up instead of down. That was because it open the site to countries with low internet bandwidth https://blog.chriszacharias.com/page-weight-matters
Everywhere, my provider limits me to 32 kbit/s
> in exchange for having really small network requests after the load.
I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire.
Most SPAs I've worked on/with end up making dozens of large calls after loading and are far far slower than just sending the equivalent final HTML across from the start. And you can't say that JSON magically compresses somehow better than HTML because HTML compresses incredibly well.
Most arguments about network concerns making SPAs a better choice are either propaganda or superstition that doesn't pan out in practice.
> I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire.
There are complete CAD applications running in browsers for PCB and mechanical design with many layers, 3D view, thousands of components, etc.
For example: https://easyeda.com/ https://www.onshape.com
> because HTML compresses incredibly well
Haven't compression under TLS have been mostly disabled after CRIME and BREACH attack?
No, HTTP compression is widely used (brotli increasingly).
BREACH would be the relevant attack for content-encoding compression, it's only good for guessing the content of the response that can't actually be read otherwise, i.e. stealing a csrf token in cross-site requests, requires that the server echo back a chosen plaintext in the response (e.g. a provided query string), and takes thousands of requests to pull it off.
It's a vanishingly small number of things that are actually vulnerable to this attack, and I've never even heard of a successful real-world exploit (tho it's not like the attackers that might use this go and tell everyone).
With HTML you have to send both the template and the data. With json, it's just the data. So it's less information total. It should compress a little better, but I don't have stats to back that up.
> I don't have stats to back that up.
Your comment then falls under my "superstition" label.
My experience has been that the HTML version will send overall less data since it contains precisely what is required by the UI and nothing more. The JSON APIs try to be "generic" across clients and either send more than the client needs or send less and cause the client to wait on a waterfall of requests to load everything.
You should always run benchmarks for your use case but the majority of web projects are not Figma or AutoCAD and benefit drastically from simpler approaches. A single compressed HTML response will beat a cascade of JSON ones every time.
For first load, yes. The idea is that you never have to send the template again after that.
Cascading is a separate problem. You can bundle all the data into a single request if you want.
You can even send JSON along with the HTML in the first request.
Why does this have to be the baseline architecture when you can render the HTML on the server with the template and data? Why send the data and the JavaScript to parse that data and transform it into HTML in a users browser when you can do it on the server?
For requests after the first, you can still continue to send the rendered HTML to be placed into the document. Here's an example using HTMX: https://htmx.org/examples/lazy-load/
If your app is simple enough, go ahead and do that. In nearly every app I've worked on, I eventually need some dynamic piece of content. Like even a date picker, so you really want to call the server every time the use wants to go to the next month?
Why on earth would you drive a date picker from the server? No one is saying to do that. JS is absolutely fine to build custom UI controls. The form the date picker renders in doesn't need to be 100% JS though.
Use JS to patch over things the browser doesn't implement and let it handle the rest.
Ok, at least we agree on something. I think that's fine if your app is simple enough, but the more and more dynamic it gets, at a certain point, I think it makes sense to just render the whole darn thing in JS. At least for the DX.
> The idea is that you never have to send the template again after that.
This implies or assumes that sending the template again is a problem. In practice, it's not. HTML compresses well and the difference between the compressed JSON and HTML response is often on the order of hundreds of bytes. That assumes equivalent data content which, as I've said above, is often not the case. JSON payloads tend to be larger and we need more of them to render the same UI.
HTML templates are still text, text compressed well. As with all these discussions “it depends, profile it” is the only answer. People blindly assuming that X is better is why things are slow and shitty in the first place
Do browsers have trouble loading and rendering HTML in 2025? Page load should be blazing fast if it's not loaded down with a bunch of other stuff that hasn't already been cached.
They don't. The reason to do it is not to save bytes, but because you have a dynamic page that needs to respond to the user without doing a full page refresh on every minor interaction.
Why on earth would you do a full page refresh on every interaction? Browsers have native support for partial page updates and prefetching.
JS is fine to use too as needed. Generally, it's not needed. Small snippets to pop open modals or flyouts of whatever covers a huge number of use cases.
No, but doing the rendering through JavaScript in userland will be slower than letting the browser handle it
Side note, sick of jQuery being always associated with spaghetti in the tech lexicon.
Any Turing-complete system is spaghetti in the hands of bad programmers. And simple & clear in the hands of good ones who know how to design.
Jquery is good for dom manipulation, though most of the best ideas have become vanilla javascript standards.
It isn’t really equipped or opinionated on statefulness, which means that everybody was at one point kludging stuff onto it that didn’t make sense.
Languages... (is jQuery a language, I guess so, let's go with that)... live in a context... there is culture, tooling, libraries, frameworks. Some languages have good culture, some have bad culture. I guess it's not even so black and white: language have good or bad culture in different areas: testing, cleanliness, coding standards, security, etc. If jQuery is misused in the hands of bad programmers ALL THE TIME, that becomes the culture. Not much to do about it anymore once the concrete has set. You can't still be an exception to rules, good for you! But that doesn't change the culture...?
> If jQuery is misused in the hands of bad programmers ALL THE TIME, that becomes the culture.
My bet is that everyone here both agrees with you and is able to replace "jQuery" with "HTML", "CSS", and "JavaScript" to reach similar conclusions about the cultures of each. The problem is bad programmers, not the tech.
It drives me crazy when it used together with React —- I want to have one authoritative copy of the state of my app, and jQuery bypasses that, at least if I’m using controlled forms.
Now I used to hate uncontrolled forms but now I like react-hook-form.
If you work at a place that has a modern CI/CD pipeline then your multiple deployments per day are likely rebuilding that large bundle of JS on deploy and invalidating any cache.
HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant. SPA’s that use packaging of large bundles doesn’t leverage modern browser and server capabilities.
Lots of SPAs now are code-split too for what it's worth so you shouldn't really have large bundles to download if you're splitting things well.
Is this true everywhere? Isn't much of the world still on slow mobile networks?
Being on a slow mobile network and having to reload changing bundles multiple times a day to use SPAs would be an even worse UX.
> HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant
H2 doesn’t make packing irrelevant… there’s still an IPC overhead with many small files… and larger bundles tend to compress better (though compression dictionaries might help here)
Large Js bundles are a huge problem though
The real reason SPAs are popular is because JavaScript is the new Visual Basic and there are millions of developers that know nothing else.
Workforce market forces like that have a vastly greater effect than “bandwidth optimisation”.
My evidence for this is simple: every SPA app I’ve ever seen is two orders of magnitude slower than ordinary HTML would have been. There is almost never a bandwidth benefit in practice. Theoretically, sure, but every app I come across just dumps half the database down the wire and picks out a few dozen bytes in JS code. There's a comment right here in this discussion advocating for this! [1]
Another angle is this: if you had a top 100 site with massive bandwidth costs, then sure, converting your app to a SPA might make financial sense. But instead what I see is tiny projects start as a SPA from day one, and no chance that their bandwidth considerations — either cost or performance — will ever be a factor. Think internal apps accessed only over gigabit Ethernet.
I’ve seen static content presented as a SPA, which is just nuts to me.
[1] "It's much better ux when a user downloads the whole catalogue" from: https://news.ycombinator.com/item?id=44688834
Can’t hire for anything else. Competence in development no longer exists. And AI is making this march to idiocy worse.
Does a real-world example of bandwidth saving even exist for SPAs? It’s always the other way around where what could’ve been a single page load, ends up being 6 separate asynchronous calls to different APIs to fetch random bits and pieces while the user stares at spinners.
And the frontend-backend paradigm has seeped into the engineering culture and even the non-engineers on the team understand things in those terms. The main way we break apart work into tickets is API endpoints and client-side UI stuff.
This. The mental model of an API with a frontend deployed as static resources just happens to be very attractive. Even more so when the SPA isn't the only frontend, or when you don't know that the SPA will remain the only frontend forever. When you have an SPA sitting on top of an API, introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial.
If you have a huge org working on the project you might actually succeed in sticking to that architecture even when serving as plain old HTML, but smaller teams are likely to eventually write full stack spaghetti (which might still be fine for some use cases!). Once there was a fashionable term "progressive web app", with manifest workers optionally moving some backend stuff into the browser for offline-ish operation, and these days I also see a parallel pattern: progressively moving a browser UI into an electron-esque environment, where you can features requiring more local access than the browser would allow.
> introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial.
This never happens, for some values of never.
When a SPA app is initially developed, the "client" and the "API" are moulded to each other, like a bespoke piece of couture tailored to an individual's figure. Hand-in-glove. A puddle in a depression.
There is absolutely no way that some other category of platform can smoothly utilise such a specialised, single-purpose API without significant changes.
The reality is that most SPA apps are monoliths, even if the client app and the API app are in different Git repos in order to pretend that this is not the case.
That's absolutely not my experience from any of the SPAs I've worked on. If the API used by the SPA is so "specialised, single-purpose", then that isn't something inherent to SPAs, only inherent to developers (or architects) who are inexperienced or bad at their job.
>every SPA app I’ve ever seen is two orders of magnitude slower than ordinary HTML would have been.
I'd argue then you don't have an SPA. However I don't see how you could have a application like Figma or Discord and say "ordinary HTML is faster" (or even possible).
For ever one real "app" like Figma there are hundreds of web pages with some forms and light interactivity. Numerically there are far more enterprise LoB apps than there are true web applications that SPAs are well suited for.
You claimed "every SPA" app, now its down to "most". I'm not going to argue against the fact that some people have hammers and only see nails.
Every popular technology has been over implemented - these same enterprises probably have a 100-node Spark cluster to process 1GiB of data.
"Every SPA app I've ever seen". I'm yet to see a fast one. Maybe they exist! I wouldn't know.
YouTube, for me, is unfathomably slow. It takes about a minute before I can get a specific song in one of my playlists playing. Every view change is 5-20 seconds, easily.
Facebook and the like now show polyfills for 10-30 characters of text, because hundreds of thousands of servers struggle to deliver half a line of text over terabits of fibre uplinks. Meanwhile my 2400 baud modem in the 1990s filled the screen with text faster!
Jira famously was so slow that this would never fail to be mentioned here any time it was mentioned. Service Now is better, but still slow for my tastes.
Etc...
If you disagree, link to me a fast SPA app that you use on a regular basis.
PS: Just after writing this, I opened a Medium article, which used -- I assume -- SSR to show me the text of the article quickly, then replaced it with grey polyfills, and then 6 full seconds later it re-rendered... the same static text with a client-side JavaScript SPA app. 100 requests, 7 MB, for 2 KB of plain text.
You mean a chat cliënt? That seems a good worse case scenario.
If you limit history to the most recent message (and have an link to the archive at the top) you could simply reload the entire page on some interval that declines with message frequency (and when you submit the form)
Since the html document is pretty much empty the reload happens so fast you won't see the flashing. With transitions it would be perfectly smooth.
With modern css you can put the elements out of order. You can simply append the new line to the end of the html document that represents the channel. (And to the archive) Purging a few old lines can be done less frequently.
I haven't tried it but it should work just fine. I will have to build it.
Initial load will be 100x faster. The page reloads will be larger but also insanely robust.
>You mean a chat cliënt? That seems a good worse case scenario.
No, I mean discord. An application where you can chat, recieve phone calls and watch a live stream all at the same time.
A pure html chat client is uninteresting - there have been realtime html chat clients since I was teenager, even before the release of jquery.
The things I was wondering about were: 1) can a non spa chat client be as good as a spa. 2) at what point is a spa justified. (is chat enough?)
Phone calls and live streams are things for which a tab needs to stay open. If you want to do other things simultaneously both the browser and the OS could facilitate it - but do so rather poorly.
It's not why people make spa's it seems?
> You mean a chat cliënt?
Calling Discord "a chat cliënt [sic]" is barely one step removed from "I could build that in a weekend". So go ahead. Wait, what is stopping you?
No audience.
SPAs are nice when your app requires complex state; multiple rows of nested tabs, modals, multiple interlinked select inputs which load data dynamically, charts or graphs which can lazy-load data and update on the fly in response to user actions.
There is a certain level of complexity beyond which you need to load data on the fly (instead of all up front on page load) and you literally cannot avoid an SPA. Choosing to build an SPA is not just some arbitrary whimsical decision that you can always avoid.
Sometimes people just go straight to SPA because they're unsure about the level of complexity of the app they're building and they build an SPA just to be sure it can handle all the requirements which might come up later.
One of my first jobs involved rebuilding a multi-page EdTech 'website' as an SPA, the multi-page site was extremely limiting, slow and not user-friendly for the complex use cases which had to be supported. There was a lot of overlay functionality which wouldn't make sense as separate pages. Also, complex state had to be maintained in the URL and the access controls were nuanced (more secure, easier enforce and monitor via remote API calls than serving up HTML which can mix and match data from a range of sources).
I think a lot of the critiques of SPAs are actually about specific front end frameworks like React. A lot of developers do not like React for many of the reasons mentioned like 'resetting scrollbars' etc... React is literally a hack to try to bypass the DOM. It was built on the assumption that the DOM would always be unwieldy and impossible to extend, but that did not turn out to the the case.
Nowadays, with custom web components, the DOM is actually pretty easy to work with directly but info about this seems to be suppressed due to React's popularity. Having worked with a wide range of front end frameworks including React for many years, the developer experience with Web Components is incomparably superior; it works exactly as you expect, there are no weird rendering glitches or timing issues or weird gotchas that you have to dig into to. You can have complex nested components; it's fast and you have full control over the rendering order... You can implement your own reactivity easily by watching attributes from inside a Web Component. The level of flexibility and reliability you get is incomparable to frameworks like React; also you don't need to download anything, you don't need to bundle any libraries (or if you do, you can choose how to bundle them and to what extent; you have fine-grained control over the pre-loading of scripts/modules), the code is idiomatic.
> there are no weird rendering glitches or timing issues or weird gotchas that you have to dig into to.
Ehm... define the Web Component render blocking in the head, because you want to prevent FOUCs. Then try to access the .innerHTML of your Web Component in the connectedCallback
https://dev.to/dannyengelman/web-component-developers-do-not...
Interesting but I wouldn't call that a gotcha. Trying to read the DOM outside of the component is kind of an anti-pattern and I think this kind of behavior should be expected. You'd generally want the web component to be a black box and it works pretty well once you understand the rendering order and focus only on internal or slotted elements. I think the only real 'gotcha' I came across was the order of when the attribute changed callback gets called versus the connect callback but it's easy to adjust the logic internally to take this into account. I can make do with a custom render() method and sometimes additional methods to perform specific granular updates to the component's own DOM...
With React, the component either gets rendered or it doesn't get rendered; all or nothing and React fully controls this. With web components you can also just nit-pick a single element within the component's DOM and only update that one. It gives you more opportunities in terms of performance optimization and how you split up your components... But you can also achieve a similar result as React by just re-rendering the whole component if necessary.
The one difficulty which is actually an advantage IMO is that you cannot pass JavaScript object or function references to Web Components via HTML attributes; you have to pass primitive values... But IMO this a BENEFIT because it forces separation of concerns and it makes the DOM way easier to debug in the dev console. For advanced use cases you can still pass JS refs to a child component by calling methods on it but I try to avoid this because it makes it harder to understand the state of a component.
I like it when I can understand the state of a component just by looking at its attributes and I like those values to be as simple and human-readable as possible. I love opening up my dev console and just tweaking the HTML attributes directly and see the change happening. Makes debugging a breeze. Kind of tricky to do with React and you get into all sorts of weird situations where a render may not trigger when you expect when you change properties of an object without changing the reference itself. React adds a lot of unnecessary complexity there.
i remember seeing web components years ago, it sounds like they've improved a lot.
what do you do about the lack of (i assume) ecosystem? due to the ready ubiquity there's practically a library for everything. do you find that using WC you are having to hand roll a lot? i don't mean to be a package slave but for complex and tedious things like graphs / charts.
There is an ecosystem for Web Components: Polymer, Lit, WCB, ready-built web components at https://webcomponents.org
Latest blogpost on that site is from 2018
I presume Web Components are so great they haven't had anything happen since 2018
> SPAs make sense when your users have long sessions in your app.
SPAs also make sense when you want to decouple the front end from the back end, so that you have a stable interface like a RESTful API and once AngularJS gets deprecated you can move to something else, or that when your outdated Spring app needs to be updated, you'll have no server side rendering related dependencies to update (or that will realistically prevent you from doing updates, especially when JSF behavior has changed between versions, breaking your entire app when you update).
> When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.
The slight difference in user experience might not even enter the equation, compared to the pain that you'd have 5 years down the line maintaining the project. As for loading the app, bundle splitting is very much a thing and often times you also get the advantage of scoped CSS (e.g. works nicely in Vue) and a bunch of other things.
Not sure what kind of clients you work with, but in my experience this is actually accurate and you won’t believe how many times I had to put my hands and fix SPAs that should have been a static website to begin with. I think this is a consequence of a generation of webdevs, especially front-end, that graduated from bootcamps teaching them only JS frameworks and React as if that’s the only way the Web works. They were given a hammer, told how to use it, and everything then just looks like a nail.
I don't know if a bunch of sloppy jQuery modules were ever really a viable option for an SPA. People tried to do it, sure, but I'd say the SPA era really started with backbone.js
ExtJS/Sencha was quite powerful and complete. I’ve built tons of SPAs with it in the late 00s.
Wow, I remember Sencha! It’s been a while since I’d heard that name.
I mostly remember doing $(document).ready blocks in php templates :)
I wrote my first SPA, a knowledge graph editor, using GWT (Google Web Toolkit) which compiled a dialect of Java to JavaScript circa 2006 or so.
> SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.
Only for certain types of applications… the route change time for many SPA’s is way higher than for the equivalent MPA
> But SPAs came about in the days of jQuery, not React.
(viper.pl 2000, philips.pl 2001 .. - are.. 'unreal' ??
'µloJSON': https://web.archive.org/web/20020702120539js_/http://www.vip...
historised chained htmls restart onerror: https://web.archive.org/web/20020402025320js_/http://www.aut... )
jQuery 2006, React 2013
Depends on the definition of SPA, but in the days of jquery, I hardly consider any of that single page app. For example, the server rendered page had most of the html initial rendered, jquery would attach a bunch of listeners, and then on an update it incrementally. If lucky, we had a duplicated x-template-mustache tag which had a logic-less template that we could use to update parts. Jquery and duplication was the “problem” which drove everyone to SPAs.
A SPA also makes it much easier to package your site into an app that you can put on the stores.
> It solved a real problem, of not wanting to reload all that code every time a user on an old browser, with a slow connection, changed some data.
Why would the browser have to reload the code (JS files) on every page transition, with proper caching headers?
Click on a link on Amazon and take notice of all the kb of data in the head of every document that doesn't get cached.
But you were talking about code, not data, hence my question. Also, Amazon doesn’t need to be that way (and wasn’t twenty years ago, the motivating period we are talking about).
> When it is worth the pain to load a large bundle in exchange for having really small network requests after the load
...and yet, i keep running into web (and even mobile apps) that load the bundle, and subsequent navigation is just as slow, or _even slower_. Many banking websites, checking T-Mobile balance... you wait for the bundle to load on their super-slow website, ok, React, Angular, hundreds of megs, whatever. Click then to check the balance, just one number pulled in as tiny JSON, right? No, the website starts flashing another skeleton forever, why? You could say, no true SPA that is properly built would do that, but I run into this daily, many websites and apps made by companies with thousands of developers each.
Yeah, I see a lot of poorly written back-end APIs too.
backend has many traps but no one totally dominating "load the slow bundle once, near-native subsequent page loads" narrative which is (for whatever the reason!!) a non-existent illusion on most average daily websites.
Is this true? When I think of old SPAs I think of java apps running in a browser. Those are definitely older than jQuery.
(I love this silly site for downvoting this question.)
Java applets and ASP.Net did have a superficial answer to this, as well as Flash, but they varied in terms of their ability to actually function as raw web interfaces using the URL to navigate between sections.
Being able to reliably and programmatically interact with client-side storage and the url, as well as improvements in DOM apis and commodification of hardware with more ram and faster faster CPUs, among many others factors, seem to have contributed.
ExtJS came about in the late 00s, and it was possible to build SPAs with it, overlay/draggable windows, and had powerful grid/form components.
https://extjs.cachefly.net/ext-3.4.0/examples/ unfortunately most of the data examples don’t work, but I believe everyone browsing the web back then remembers this blue tinted interface.
oh man now THAT is a real blast from the past. oh man, pretty classic "where did all the time go?"... "oh yeah i forgot that i spent like 100s of hours battling with sencha back in the day". selective memory isn't always a bad thing, i guess.
Java applets are entirely distinct from SPAs, at least as that term is used in the webdev community.
Hm, alrighty then. Seems like an unnecessary distinction to me in that it deeply constrains what SPAs can be, but I'm not a webdev.
The rule is either "uses html to render" or an even looser "renders in the browser". That doesn't seem like a deep constraint to me. You exclude a couple very popular but historical plugins where the browser set up a rectangle and handed it off to an external piece of code, and pretty much nothing else.
Those apps came from an era when these terms weren't even coined yet.
I think of java applets as being more akin to wasm; SPAs were/are a collection of html that recreate the experience of a "plain old" html web site.
SPA is not only about seamless transitions but also being able to encapsulate a lot of user journey on the client side, without the need of bothering server too much.
Let me give you an example - one of my biggest gripes about web ux is the fact that in 2025 most shops still requires you to fully reload (and refetch) content when you change filters or drill down a category.
A common use case is when you come to a shop, click on "books" (request), then on "fantasy" subsection (another request), realize the book you're looking for is actually a "sci-fi", so you go back (request, hopefully cached) and go to "sci-fi" (another request).
It's much better ux when a user downloads the whole catalogue and then apply filters on the client without having to touch the server until he wants to get to the checkout.
But it's a lot of data - you may say - maybe on Amazon, but you can efficiently pack sections of most shops in data that will enable that pattern in less kilobytes that takes one product photo.
I've been building web apps like that since ca. 2005 and I still can't understand why it's not more common on the web.
I don't know, I think the most painful aspect of having to do a full reload is how I efficient the site is. The actual data is a few KB, but the page itself has to download 100 MB and the web browser is burning through a GB of RAM.
Like I don't find Hacker News to be egregious to navigate, and nearly every nav is a reload. It runs fine on my 2008 laptop with 4 GB of RAM.
But I go to DoorDash on the same device, and it takes 30s to load up a list of 50 items. They give you a countdown for a double dash, and I genuinely don't think it's possible to order some curry and get a 6 pack of soda in less than 3 minutes. And 2.5 minutes is waiting for it to render enough to give me the interface. Almost none of it is a full reload.
An SPA can be lean and fast. React is the prevailing Web framework today? Preact is like 5 KiB of code.
What makes SPAs unwieldy is not the technology but the lack of desire to optimize. It loads fine on yesteryear's Macbook Air? Enough, push it.
I very well remember heavy, slow-loading websites of, say, year 2000, without any SPA stuff, even though lightweight, quick-loading pages existed even then, in the epoch of dial-up internet. It's not the technology, it's the desire to cram in more, and to ship faster, with least thinking involved.
> I very well remember heavy, slow-loading websites of, say, year 2000, without any SPA stuff, even though lightweight, quick-loading pages existed even then, in the epoch of dial-up internet.
Sure, lightweight, quick-loading pages existed, but sometimes you want to see a picture.
Google appeared in 1998. It was very noticeable how fast it loaded compared to competitors like AltaVista and Yahoo. None of them featured large photos.
This was visible not only on a 33600 phone connection at home, but also on a megabit connection at work, because, shockingly, how fast your backend is also plays a major role.
Speaking of speed, don't forget when gmail and google maps first came out: With the data copied locally they could separate the UI from server requests for a lot of interactions so a lot of the UI was actually instant and you could keep doing things while the requests were handled in the background. This seems to have been missed by a lot of modern stuff that doesn't bother figuring out if this is even possible and opts to show a loading spinner instead.
Yeah, the enemy isn’t the need to reload, it’s reloading taking a long time due to too much garbage that’s not the content the user is interested in having to come down off the wire and render. A site that requires an occasional split second reload is always going to be preferred to a behemoth that doesn’t need reloading but has me staring at blank screens and loading spinners half the time I’m using it.
> But I go to DoorDash on the same device, and it takes 30s to load up a list of 50 items.
> And 2.5 minutes is waiting for it to render enough to give me the interface.
I have a very old MacBook Air (one of the painfully slow ones) that I use for development reference for what a slow machine looks like.
I just tried clicking around DoorDash and didn’t see anything nearly this bad. Not even close.
Every time there’s a Hacker News thread about how slow websites are, there are dozens of comments like this claiming extremely large latency numbers. I can’t tell how much of it is exaggeration for effect, or if some people have configurations with weird quirks that make them abnormally slow.
I suspect it’s a lot of this:
> on my 2008 laptop with 4 GB of RAM.
Sorry, but I don’t think it makes sense for companies to optimize their websites for computers that are nearly two decades old and don’t even have enough RAM to run a modern operating system.
The intersection between people who spend money on a expensive luxury service like food delivery to their door and people who won’t spend the cost of a couple DoorDash deliveries to upgrade from a 2008 laptop to a 2018 laptop in 2025 is negligibly small.
Hmm, I would say comparing Hacker News to DoorDash is not exactly apples to apples. There may also be ulterior motives to make a website slow(or at least not optimized) if the company wants to funnel people towards an app on the phone.
Gmail takes 3s to load. And HN is a website, not an app.
That's the discussion being had.
HN would've been considered an app if it was built as SPA
> Gmail takes 3s to load
On a 2008 device, in 2025? On a mobile connection?
How is HN not an app? All the content is user generated. Everything is interactive. What's the difference?
Most of the time spent is content consumption (viewing html documents), rather interaction (which is only 2 simple actions).
Navigating to a thread isn't much different than navigating to a store.
Upvoting isn't much different than adding to the cart.
Payment isn't much different than adding a comment.
I think the interaction levels are incredibly similar. The primary difference is the amount of images displayed, but that really isn't a significant aspect of web design or Internet traffic in 2025.
When you posit like that makes me think doordash shouldn’t be an app at first place.
I suppose that's valid. Feels fairly arbitrary though
Document-centric, form-driven websites aren’t traditionally called apps. The Wikipedia website isn’t an app. Web forums aren’t apps. “App” implies that essential parts of the interaction logic are driven by client-side code (JS, not HTML) that couldn’t similarly be implemented by HTML forms.
Sure Wikipedia is an app, long as you think of static websites as a subset of web apps. One might say that makes the term meaningless, I say it's a deliberately vague term because people don't want or need to get cornered by fine distinctions. Otherwise it's endless quibbling over whether things like search do or do not count toward a site being a "real" app.
Your definition of the term simply doesn’t match common usage.
Thing is, and I believe it's a valuable example counterpoint, if I shift-click on a link, like sci-fi category, to open it in a new tab(very common thing people do), having a multi page application is zero work added, on an spa you have to manage that. If the link doesn't exist and categories can only be accessed by a select input then ux isn't that great
This is so annoying when SPAs break browser functionality like open link in new tab. Even if it works often it has to reload a bunch of JS again, which makes things veeery slow. This is why I really don't like Linear, I often open issues in separate tabs, which is every time a pain, browser freezes for seconds just to open a link in a tab...
I think it was not designed for your use case. It is conveniently running in the browser but not a collection of links to html pages. The people quarreling in this comment section seemingly ignore that life is complex, web browsers are complex, web development is complex. Maybe you should think about linear as a desktop app and call it a day :)
My use case is being productive at my work. If it was not designed for that, then not sure what is it for. It comes up fairly often in team chats, it's a resource hog with ridiculously high memory usage, poor browser utility, syntax highlighting selecting random languages,... I'm happy that it fits your desktop app use case, but there are also other people that see this as a limitation and sign of poor design. Web development is complex, but acknowledging that there are poor web apps and better web apps is part of that too. And from my experience and in my opinion (also shared in my team), Linear is an example of the bloated web app that is making the web worse for us, which is why I brought it up above.
EDIT: the parent I was replying to talked about the issue of opening links in new tabs and your answer - don't do it, use it like a desktop app - is basically the problem we are having with some of these web apps.
Modern SPA frameworks give you this by default. You can deep link and get the specific page with all the parameters/filters etc applied server rendered in remix/react-router, next, sveltekit and most other frameworks. I agree that too many apps have basic things like CMD+click broken
Please no. Whenever I see an online store as a SPA catalogue I shudder, because it usually breaks after browsing a bit in a weird state. And it resets to somewhere random should you hit back, refresh or try to send a link to somebody.
Yes, SPAs should store simple user state in the URL as well.
> It's much better ux when a user downloads the whole catalogue and then apply filters on the client without having to touch the server until he wants to get to the checkout.
This is what we[0] do too. We have a single JSON with a thousand over BOMs that's loaded directly into the browser. Previously we loaded the inventory data via an API as is usually expected. The fact that there's even an API meant requiring progress and loading bars, API unavailability scenarios, etc.
Having it all as a single preloaded JSON meant that all of the above goes away. Response is instantaneous.
[0]: https://chubic.com
HTMX (and similar) solves a lot of this. It so happens that we end up building two apps one frontend and one backend with SPAs as built today. I'd rather build a lot of it on the server side, and add some dumb interactivity on the client (show/hide, collapse/expand, effects). There is still a place for SPA though.
HTMX does the opposite of this, it requires many more round trips to the server instead of using client side JS to do work.
htmx does not require many more round trips to the server, front end scripting is perfectly compatible with htmx:
https://hypermedia.systems/client-side-scripting/
in addition to native html features like <details>, etc.
htmx can often decrease the number of trips to a server because in the hypermedia model you are encouraged to deliver all the content for a UI in one fell swoop, rather than in a series of chatty JSON requests that may be made due to opaque reactive hooks.
I find Datastar to be a better replacement for HTMX, especially now that it can also do plain requests instead of Server-Sent Events. You also don't need Alpine.js combined with HTMX anymore.
First time I've heard of Datastar. Not sure what to make of it yet, but the video on data-star.dev is certainly one of the cutest things I've seen all year!
Many more round trips to the server is okay - it is the server after all and it is easy to scale it.
Does it matter how many round trips are made to the server if they're fast enough to be seamless?
I meant for the SPA-like experience.
Generally speaking, companies don't want you to download their entire catalog. They don't want competitors to be able to analyze it easily like that.
And if a store is selling books, it might have hundreds of thousands of them. No, it's not a good experience to transfer all that to the client, with all the bandwidth and memory usage that entails.
That's really weak argument.
If it's one their website the competitors can write a simple crawler and create that catalog.
And you don't have to send every single field you have in your database. Once the user selects a category you can send a metadata that enable the client to scaffold the UI. Then you cache the rest while user interacts with the site.
Barnes and Nobles - according to their FAQ - has 1 million unique items in their catalog. But they also have tons of different categories. A single book cover weights around 30kb.
I'll leave it as an excercise to figure out how much data you can fit into 30kb to make usable filtering system.
btw: opening their front page downloads 12.1MB already.
> I'll leave it as an excercise to figure out how much data you can fit into 30kb to make usable filtering system.
Into 30kb? That's just 300 items at 100 bytes each. So not a lot?
>I'll leave it as an excercise to figure out how much data you can fit into 30kb to make usable filtering system.
Not even 1 bit per item in the Barnes and nobles catalog? So not much.
> SPA is not only about seamless transitions but also being able to encapsulate a lot of user journey on the client side, without the need of bothering server too much.
True, but as a user, I don't want you encapsulating my journey. You can wax poetic about hypothetical book categories, but the reality of SPAs is that they break back buttons, have terrible accessibility anti-patterns, attempt to control my attention, and expose my computer to all your bad security practices. SPAs usually contain half-assed implementations of half the features that ship standard in a modern browser, and the only motivation for all that effort is to make the site more favorable to the server's owner.
When a site is implemented with simple HTML and careful CSS, I can configure it to my needs in the browser quite easily. That's a site that favors me, not your opaque blob nonsense.
Why is this being downvoted.
I agree, as user make it fast and don’t break the web. I see so many SPAs with bad usability, like back button not working.
A shopping site doesn’t need to be SPA.
A drawing app, 3D modeller, collaborative whiteboard, video chat, those type of apps fit the SPA model.
In almost all cases the back swipe in the spa resets you to the top of the page, navigating out of the app and back in doesn’t work, etc. It’s really hard to build a multi page spa that feels good.
It's funny you've mentioned that.
It reminded me of the time when I joined Wikia (now Fandom) back in, I think it was 2006. One of the first things that landed on my desk was (I can't recall the context) deeplinking.
And I remember being completely flabergasted, as I came Flash/games background, and for us that problem was completely solved for at least 4 years at the time (asual swfaddress package). I felt kind of stupid having to introduce that concept to much more senior engineers that I was at the time.
Never thought about scroll position (tho SPA I’ve built recently I think does it ok). How do you solve it?
I'm a self taught PHP/jQuery/bootstrap guy with a small saas. I handle page scroll position by literally saving it into some session data cookie and when you go back I check where your scroll was and I fix it for you. I'm not a genius or skilled... But I cared so I did it.
I’ve done it like that. It’s not a lot of code.
I write some of my thoughts on this sone years ago. The library described at the end is now fairly out of date but the ideas and suggestions are still good, I think.
https://dev.to/cyco130/how-to-get-client-side-navigation-rig...
Depends on what you're using for routing.
In Tanstack Router it's a boolean you set when creating the router. The documentation nicely lays out what's being done under the hood, and it's quite a bit.[1] I wouldn't try that at home.
In React Router you just chuck a <ScrollRestoration /> somewhere in your DOM.[2]
[1]: https://tanstack.com/router/v1/docs/framework/react/guide/sc...
[2]: https://reactrouter.com/6.30.1/components/scroll-restoration
In a similar use, a few of my hobby projects are hosted on static web servers. So instead of rendering out everything into individual pages, which would've been tens of thousands of pages, I have a JSON file that gets rendered by the client in a SPA. I have even used Github Pages for this
I'm playing around with a newer version that uses a sqlite database instead. Sqlite officially has wasm builds, and the database file is already built to be separated into pages. With HTTP Range Requests, I can grab only the pages I need to fulfill any queries.
Sqlite full text search even works! Though I'm hesitant to call that a success because you do end up grabbing the entire FTS table for shorter searches. Might be better to download the entire database and build the FTS table locally.
This wouldn't work for 90% of apps out there. While I would love that approach, it has so many problems that in practice it never worked out for me. First problem is that data change. Either you edit it, or you need updates from server applied to your copy. This is quite complex (although there are some solutions, I had little luck in making this work reliably). Second - you don't want to share the whole catalog in one request. Third - in most cases there is a lot of data. It's not uncommon to have tens of thousands of items and for each you likely need some kilobytes. Four - you are downloading the whole catalog even for deep links which might not care about all but a tiny fraction of that data.
In my experience, state is the devil, and the approach of filtering things on the client moves a bunch of state management from the back end to the browser, which is the worst place to handle state.
You can do that with checkbox selectors. e.g. see [0]. Note that I don't really do frontend and I asked chatgpt to vibe code it, so this may not be the best way to do it.
[0] https://html-preview.github.io/?url=https://gist.githubuserc...
Pjax was the goat.
I don't know what universe this SEO-consultant author lives in. The author gives Next & Nuxt as an example of the kind of frameworks going against his prescription, but that is so wrong.
1. Next won the war in the west, big time. Very very big time. Whenever people talk about new React apps they inadvertently mean Next. On the Vue side Nuxt is the default winner, and Nuxt is just the Next of Vue. That means that by default, by reflexive instinct, people are choosing Next and MPA as their strategy. If you want to correct the overly extreme pendulum motion then you should be telling people to try out SPA. The last 8 years has been a feverish push for MPA. Even the Facebook docs point straight to Next, totally deprecating Create React App. This is also Facebook ceding their battle to Next.
2. Whenever people complain about the complexity of Next, they are complaining about the difficulties of cutting edge MPA strategy, which evolves on a year to year basis. SPA on the other hand is a story that has frozen in time for who knows how many years. Almost a decade?
3. Doing MPA is strictly harder than doing SPA, much much harder. You have to observe the server/client distinction much more closely, as the same page may be split down the middle in terms of server/client rendered.
4. If you're writing an SPA and want to be more like MPA and load data at the time of hitting a user-navigable endpoint, that's on you, benefits and costs and all. You can also load data with anticipation so the client navigation is basically instant.
5. For every sexy SEO-able front-facing property you're going to have many teams with internal apps or dashboards backing that front-facing property. That's where many React devs are employed. Do not unnecessarily take on burden because you're so eager to ship the first "frame" of your app in a perfect way.
How did next win the React framework war? Is it not few years already that see exodus from next to remix/react router, and more recently to tanstack start etc. because of unnecessary complexity, difficulty to run next on anything but vercel, misguided API changes etc.?
You mentioning facebook docs pointing to next, when they explicitly mention remix and other is quite misleading.
Well, you must know how to look at download stats, search metrics, GitHub activity, social media temperature, or job posts. I feel that seeing is believing with your own eyes is sufficient for anyone who wants to investigate the issue of whether there’s any winner in popularity.
To not be misleading I wouldn’t have brought up the existence of remix lest people think Microsoft belongs in the same discussion as my software consultancy.
To be clear I’m using Tanstack Start right now.
By your logic PHP and Java won the programming language war.
And according to github stars, (which may be considered rough measure of overall usage, not of current trend) next.js has 4x more than remix. So if your sw consultancy is one fourth size of Microsoft, you are close to a trillion dollar business. Even if you exagerrated by few orders of magnitude, thats still very big achievement, so congrats.
https://npmtrends.com/next-vs-nuxt-vs-remix
Also look at trajectory. Oh my, don't you think?
When I choose things like Tanstack Start, I am very clear that this is beta software and an early bet. When I'm talking about winners in the ecosystem, I am not going to bring up Tanstack and most definitely not Remix. I don't want to confuse people into thinking they belong on the same table of discussion for ecosystem winners.
Your information are outdated. Let me correct your chart a little https://npmtrends.com/next-vs-nuxt-vs-react-router-vs-remix
Remix no longer exists as it was all migrated to react-router. react-router v7 is what remix v3 should have been.
I think at some point there was more interest in framework as a startup, and there was indication that having a popular router (React Router) was a sufficient advantage in the race to at least try to win.
Then Shopify bought them up to maybe hedge against Hydrogen. Remix never went anywhere for Shopify, Shopify didn't buy React Router, only Remix. Now, as you say, Remix is being retired. My own Remix app was rewritten as I was tired of upgrading pains.
But what do you think of the argument that this is moreso Shopify folding their hand than Shopify realizing their bet via React Router?
> I don't know what universe this SEO-consultant author lives in.
After looking over the author's blog I can see
1. Very high output
2. Lots of AI images
3. Weird writing and editing lapses in several posts
I am moderately confident this post was written with an AI. It may not be totally AI produced, I think the author has probably edited the work, but I think we are mostly debating synthetic content.
There was a war? News to me. Saying Next won is like saying React won. Nothing won, everyone just latched on to what they thought the crowd vetted. The blind can't lead each other. Most people that stuck to Angular or minimal or no-frameworks are truly wondering what the fuck are all these people talking about?.
Even the Facebook docs point straight to Next
Startups and SV jerk each other off by promoting each other (think affiliates). None of it means shit.
Next is probably a garbage framework, but it's people's livelihoods. It's very hard to erase something that literally defines people (yes, your resume is YOU).
Kinda is a war unless you're working solo, cause you're gonna get forced to use something or another. When I tried a few solo web projects instead of just being a backend guy, I picked up React on my own because it was the only thing that makes sense. The page does what the code says. And that was after trying other things.
Now I gotta occasionally use Angular, and it's boilerplate hell. Adding one button involves editing 30 classes and files even if you don't use templates. I took a course at work where even the instructor got confused adding a button. Why would anyone ever use this besides Google, or do they even use it?
in the world of frameworks it's obvious that
html in your JS > JS in your html.
angular is a mess. it's the java of web frameworks. if you want up be enterprise(tm) go for it. I’m convinced it's only a thing because it gives people job security since nobody else chooses to touch it.
There was also the actual Java of web frameworks, GWT
I don't know what you guys are doing with your Angular buttons, or if you haven't looked at it since AngularJS (which I never used, so I don't know what it took there).
Adding a button to Angular is just adding a <button> to your template. If you want to use Angular Material, that's one additional import in your component's code file, and one additional attribute for that template's <button> element.
That's it. If your instructor got confused trying to achieve that, maybe that's why you were left with this weird impression of how verbose and complicated Angular is.Just at least have a look at the documentation or tutorial before spreading fibs like that.
> Startups and SV jerk each other off by promoting each other (think affiliates). None of it means shit.
No, this is FB ceding the battle. They absolutely didn't want this. They dropped CRA because social media celebrities were shitting on CRA. Dan Abramov had to do a complete 180 in a single day, after writing a long thoughtful essay in defense of CRA.
Wars, battles, personalities on social media… I don’t want to sound too much like a grouchy old man but these frameworks are tools. Nothing more than that. I can’t understand why anyone would become emotionally invested in any of them.
When starting a project the right move to examine what best fits your project, not which one was recently victorious in a war. I’ve grown to dislike React because I see it being abused so often for a site where it isn’t necessary. There are plenty of projects where it is necessary too, but that’s not universal.
> I can’t understand why anyone would become emotionally invested in any of them.
I think that's simple: because they are financially invested in them. That's obvious for the developers working on the frameworks themselves or building libraries / plugins / UI-themes for them, but I believe it's also correct for "normal" developers who build things with these frameworks.
They know these frameworks and can use them, and they've made an investment in time to get to that point. Likely they're also making at least some of their money _because_ they know these frameworks. Emotional attachment follows the economic attachment, and then you'll get plenty of rationalizations.
> I can’t understand why anyone would become emotionally invested in any of them.
sure, but I suppose you can observe that they do? And hence
>Wars, battles, personalities on social media
become reasonable narratives to engage in to describe what is actually happening in the social activities that form around these tools
You can ignore all the phrasings of wars or battles or winning and losing, and you can also ignore that social media has consequences.
We can agree that frameworks are just tools. And as tools we can coldly think about trends and other meta-facts, including questions on popularity. We don't need to think about popularity in terms of winning or losing either, just numbers that move around so we can use them as predictors of mindshare and career opportunities.
And in that sense, the right tool that fits the job often includes an analysis on popularity, especially because the best tool is often one that you and your colleagues already know.
You are in your own little universe. Social media celebrities shitting on React? I don't even want to enter your world.
"Bro, you should see the celebrities shitting on React"
Like WHO!? What developer celebrity, what universe have I been missing out on?
Anyway, I do love me a good ol' fashioned "fuck SPAs, back to HTML" punching bag post on HN. It's always the same discussion over and over.
We're living in the same universe. When you read the documentation you see something. I'm just giving the story behind it.
You don't need generic answers about people wanking each other off for "think affiliates".
We are absolutely not living in the same universe. Please don't insult me. As a self-respecting developer, I do not understand the word "celebrity".
said celebrity is an AI-generated Peter Griffin
The point of SPAs was never page transitions. I can’t name a single major SPA that does good page transitions, can you? They all just replace the content. And to take a popular SPA framework as an example, it’s almost impossible to do page transitions in Next.js because of the way routes are loaded. I know this because I added proper page transitions to Next.js and it has been an absolute nightmare.
There are two good reasons for SPAs that I can see:
1. Your app probably needs interactivity anyway; for most apps, it’s not just going to be HTML and CSS. Writing your app in some unholy combination of React and HTML is not fun especially when you need to do things like global state.
2. Loading the structure of pages up front so that subsequent data loads and requests are snappy. Getting a snappy loading screen is usually better than clicking and getting nothing for 500ms and then loading in; the opposite is true below I’d say 100ms. Not needing to replace the whole page results in better frontend performance, which can’t really be matched today with just the web platform.
Basecamp has probably invested the most in making a fairly complex webapp without going full SPA, but click around for like 30 seconds and you’ll see it can’t hold a candle in performance to SPAs, never mind native apps.
With that said, I agree that I’d want the web to work more like the web, instead of this weird layer on top. All the complexity that Next.js and SPAs have added over the years have resulted in more responsive but sometimes more tedious-to-build apps, and gigantic bundles. I just don’t think you can match the performance of SPAs yet with just HTML.
3. APIs. If you already have a client facing API for your iOS and Android apps, and maybe one for developers, a SPA is just another app to plug into that backend.
> Basecamp has probably invested the most in making a fairly complex webapp without going full SPA, but click around for like 30 seconds and you’ll see it can’t hold a candle in performance to SPAs
Really? I just started using it, and it feels fast. Most SPA's are slow and/or buggy (in the "fails to mimic real browser behaviour" kind of way)
tiny correction Next is not an SPA (you can in theory write one using NextJS, but by default it's an MPA with aggressive prefetch)
Lots of pushback here in the comments. But I can't think of the last time I enjoyed using a SPA website over a multi-page one. The initial loading feels delayed, the page scrolling feels unnatural and jarring (completely opposite of how a native app feels).
Also, one of my banks recently changed their old website to a new SPA one. And it is now completely useless. It can't load information in time, so most of the forms are empty. You can't even go back because it is a SPA. So I can only log out, log in and try again. Kind of scary when you are handling a lot of money.
And it is not just one website. As I said I can't recall ever using a good SPA website. So yeah, I can't wait until they are all gone.
You think bad programming is restricted to SPAs?
If they botch the back button in an SPA they will botch other things in an MPA
But this bank's old MPA worked pretty well. By trying to modernize it they completely broke it instead.
I’d put big money on it not being the same team that made the new app.
Probably. The old website was several decades old.
Yeah, the worst thing is when parts of the same application are under the hood different SPAs.
First example that comes to my mind: web version of ProtonMail. Going to settings feels like loading a completely separate website. Or OVH dashboard.
if you're receiving jarring page scrolling, it is not the fault of the spa, it's something else at play. it is not they typical spa experience.
if the back button doesn't work, the site was poorly programmed, since any routing library will handle that for you.
The toupee fallacy strikes again here. Gmail, slack[0], Netflix and Spotify are top tier examples - they actually work. Most are true garbage though.
[0] I am firmly on the slack-performance-is-a-disgrace train, but their web client is a great example of a well done SPA - it’s miles better than the app other than notifications.
Gmail really? The same one that takes 10-20 seconds on 5G to even show the loading page? What is it doing in that time? Loading emails or downloading an AAA game? It is not just a one time penalty either, you reload and get the same loading page again.
Just a few days ago I had to get an OTP via email and it was completely frustrating. No indication nothing, just a loading circle. The old MPA version was much better.
If it was built like we were in 1995, with tables and html 3.2 without JavaScript and just the old school inline attribute styles, it would be way more usable
It is also possible to create fast and functional websites on modern tech. But for some reason some people go completely crazy with Javascript.
SPAs do not exist to benefit the user. They exist to benefit the developer who writes them.
I like the pushback because it means less competition in the native framework space
> But I can't think of the last time I enjoyed using a SPA website over a multi-page one.
You likely don't even notice that most of what you browse are SPAs.
The reason why there is pushback is because the article is straight up misinformation.
Actually the static address bar and the refresh button behavior makes it obvious.
What?
Most SPAs use full on routing. You can not distinguish refresh and address bar behavior between a SPA and static pages.
Furthermore, SPAs integrates perfectly with the browsers navigation stack.
Where does this bs come from?
Because less than 1% of actual SPAs use those things. Hell, look at HN's search page in the bottom if you want an example. You can load entire HN by the time it loads up and searches something.
Prefect example of the sufficiently advanced compiler argument.
HN's search is hosted on Algolia, and is not a part of the HN "App".
Hacker news is not a SPA.
Algolia's search is a SPA, but is perfectly utilizes the search so you can refresh a page (besides the error that they don't use page-based search), and is largely indistinguishable from a non-SPA site.
> You can load entire HN
You obviously have not context what so ever on how much content is hosted on HN.
Yes, I am well aware it is separate from HN. That is why I called it HN's search page.
You underestimate how fast modern internet is. With MPA website like HN there is no need to wait for any script to render first.
I think this article is unfair to SPAs. SPAs are a lot more effort, but they are better. For a long time they have been the only way to "make it feel like an app." (I think the author says "make it feel like an app" because they know we all resent app fatigue, all the apps we have to download that should just be web sites, but I think we also all know that when something really is an application, it's rare for a "web app" to match the experience of a local native application, and an SPA is the only way to make a sincere attempt.)
The comparison of bloated SPAs with lean web sites is bogus. If someone takes the effort to make their web site lean, they'd do the same with an SPA. If someone makes a slow, bloated SPA with megabytes of Javascript, they'd make a slow, bloated web site with megabytes of Javascript. I think we've all seen enough of the web to know this is true.
I click on articles like these because I've seen the effort that goes into a good SPA, and I'm interested in anything that would allow people to deliver an equivalent experience with less effort. All I see here is a tiny bit of cosmetic polish. Polish is appreciated, but this doesn't seem like something that would tip the balance between building an SPA or not. Am I missing something?
“But they are better”
By what measure?
Performance, developer experience, user experience
I'm sorry but what!? Have you talked to your users? The ones that actually are forced to use your app day in and out? They want functional back buttons, they want to be able to open any action in a new tab. No one who actually uses your product would prefer an SPA once the flash wears off.
Let me tell you as a developer who has been on both sides of things, developing server rendered pages and not having to worry about the server disagreeing with the client is the ultimate developer experience. Build a competent app that can serve full pages in .1 seconds and no one will care that your site isn't an SPA. They want a fast reliable site.
We did an A/B test of an old SPA app, and a modern re-write using SSR and server-rendered pages.
By every performance metric, the new app was faster.
But we kept getting user feedback that the new site was "clunky" and "slow", even though we saw that the p90 was much lower on the new site. Most of our users asked us to enable a toggle to let them go back to the old "fast" site.
I'm not sure if this is a universal experience, but I think a lot of other sites that tried the CSR -> SSR move had similar experiences. It's just harder to talk about, since it goes against the usual narrative.
SSR can feel worse than SPA if you don't get the end-to-end latency under a certain threshold. If your SSR pages are taking upward of 100ms to render on average, it's going to start to feel like shit once you factor in the network latency.
My design goal for modern SSR pages is 500 microseconds render time on the server. A modern CPU can crank through several gigabytes of UTF8 text per second. There really isn't any excuse from a technology perspective. SSR pages being perceived as clunky & slow boils down to a skill / people / organizational problem. The computers and associated networks can definitely do it well.
Every single action should have no perceivable latency between the action and the feedback that the action was received. You can implement that with SSR but it is clunky and also requires a lot of JS generally.
> should have no perceivable latency between the action and the feedback that the action was received.
Huh, according to who? I think a small delay is totally fine.
Often better than the SPA's that tried to fix this non-problem and introduced much worse problems.
Edit: For example HN: I press update and there's a small delay.. So what? Most sites and SPA's have a much worse user experience than this.
Because past delays of about 100ms, users lose the sensation of directly manipulating the page. The feel of a page is part of it's aesthetic.
Also, immediate feedback reduces anxiety and mistakes (for example duplicate submissions).
https://www.researchgate.net/publication/391230228_Cognitive...
https://www.nngroup.com/articles/response-times-3-important-...
Looked at the first one, and that's in a game setting? And they test 600 ms??
edit: The second one is more useful IMO. It's hard to get under 100 ms with a roundtrip, but < 300 ms should be doable, right? So you do lose the sense that you are directly manipulating data. In most cases I think that's a good trade-off. Exceptions would be things like Google docs, but that's also because it's a well made app I trust to actually sync my data without loss. Unlike most SPAs..
300ms for network latency both ways, with server potentially doing its own network calls for data to fulfill the request, interpolating the html, and then browser rerendering client seems like a stretch
I am curious to identify what your users are perceiving that isn't be being captured by your metric. If it is accurate and not just rhetoric that MOST of your users are asking for a rollback for purely performance reasons, that is a very extreme outcome.
Are your p90 metrics testing:
- navigation after first load?
- users who are going to the app after it is cached on their browser?
Are your actions going through server actions or rest apis? Do you have metrics on those?
the back button does work, if you use any basic routing library. opening in a new tab does work, with any basic routing library...
Developer experience - Yes, in most cases.
Performance - No, in most cases.
User experience - No, in most cases.
What are you talking about. Majority of SPAs have abysmal performance compared to regular HTML rendered websites and that reflects poorly on user experiences.
> Developer experience - Yes, in most cases.
I think if people remembered how productive you could be before the SPA frontend/backend split they'd reconsider. Being able to take a feature from A to Z without either context-switching between ecosystems or, even worse, involving other people, was incredibly productive and satisfying. Not to mention a much more streamlined dev env without a bloated js ecosystem of bundlers/compilers and whatnot.
I write an SPA for my day job. I write Postgres queries myself. I create endpoints and background workers and cron jobs myself, and I build out the UI myself. It’s all typescript with static types end-to-end. It’s a fantastic developer experience. Much, much better than I ever had in Rails or ASP.NET.
Also, I love components for UI as opposed to templates. And I don’t think I could ever really go back to the way I did things in my MPA days.
If there's no clear backend/frontend split wrt to language and roles in your particular project my point doesn't really apply for you. But it seems that you're lucky that you can use js on the backend to get closer to that. I would still prefer to not have to do a SPA unless obviously required for the job, but at least you got some of the fundamentals in place to be individually productive.
Performance - For pages that have different content for every user, the best performance will be reached by caching the app code on the client, only loading the data needed to render, and rendering once on the client. Rendering on an aws machine that is weaker than my 15 year old macbook is not a recipe for good performance.
User Experience - Every single user action should have no perceptible latency between the action and the feedback that that the action was received. This can't be done gracefully without javascript. Moreover, SPAs enable a better ux by enabling developers to build complex features that wouldn't be possible on traditional webpage.
This argument is tired and ignorant. Try building linear.app without a SPA framework. The idea that "Native CSS transitions have quietly killed the strongest argument for client-side routing," is dubious at best.
This doesn't seem fair to say. Linear is special even among SPAs; it's by far not the norm. No one said "ban SPAs and remove javascript from the browser".
Linear's speed comes from being "offline-first", but I challenge you to name almost any other product in common usage that does it that way. It's just not common. On the other hand if I want to buy tickets I'd rather most of that website be SSR and do SPA where you actually still need it. Or forums, news sites, blogs, and informational sites.
There is so much out there that would be better developed with SSR and then use CSS to make it feel SPA-like than to actually be a SPA.
The article's title is it's time to kill SPAs
No one said SPAs have no place, but 99% of websites out there don't need to be one.
SPA means single page app. For example, Google docs, Figma, Google calendar, etc. Apps that use web technologies instead of being native apps.
A long time ago some webdevs started abusing the SPA concept to build simple websites. However that is not within the original meaning of the term SPA, because simple websites are not web apps. The author assumed that everyone would just understand that they are talking about SP"A"s and not SPAs, because for a certain subset of webdevs working on websites, the antonym of SPA is MPA, and it's normal to refer to your website as an "app". However for a certain other subset of webdevs, the antonym of SPA is simple website, and what the author is talking about are not SPAs at all.
So you describe the 1%? Is this to refute the person you’re replying to?
Where is 1% coming from? None of the software jobs I've worked at or even interviewed to work could have functioned as a website
Can you link those?
Because I mostly built backoffices, chats, forums, ecommerces, all things that would've worked better as websites.
Here are some of the things I've worked on: - payroll and other hr software - educational software - shared workspace for realtors and homebuyers
I'm not going to doxx myself by naming all the companies, but here is an example of a page that has too many features to work as a website. https://www.compass.com/listing/7310-estrella-de-mar-road-un...
You've got to be kidding me, I think you're conflating SPAs with websites that provide advanced interactivity.
I don’t see anything on that site that wouldn’t work as a website. We were building this type of thing 15-20 years ago just fine.
1% of domains perhaps, not 1% of developers.
What does it's time to kill SPAs mean to you other than they have no place.
This article is getting a lot of pushback from the SPA champions, deservedly so, but it makes some good points to. I can’t be the only one, but I myself am getting very tired of the amount of websites where I have to sit and look at a skeleton loading for way too many seconds, then the data loads and it looks nothing like the skeleton. There is an over abundance of really crappy SPAs out there. Sorry not sorry
I thought about your comment, and IMO the reason some (or most) SPAs are badly built comes down to the inexperience of developers and hiring managers. They don't know much about performance, they don't measure it, they don't handle errors properly, they ignore edge cases, and some are learning as they go.
Bottom line: they build the SPA, but leave behind a terrible UX and tech debt the size of Mount Everest.
They would have done the same thing with a MPA too though.
Yeah, of course. But I was thinking more from a user experience point of view. MPAs usually render pages server-side, which cuts down on frontend dependencies and expertise. That's why companies used to hire experienced engineers for the backend, and CSS/jQuery devs for the frontend. It used to make sense, but not anymore. These days, apps built with MACH architecture rely heavily on client-side code. This means companies are supposed to hire experienced engineers to architect apps on the client side but instead, they end up hiring JS devs with little to no software architecture experience. For example, I've seen SPAs that don't log any error messages from the app, which means developers have no idea what problems users are running into.
This is not intrinsic to SPAs.
You'd likely have to wait an equal amount of time for a non SPA - just without any skeleton
SPAs are not about view transitions. TFA implies that fancy transition is important between pages (wrong!) and blames a "CMO" or "brand manager" rather than challenging their own preconceptions and exploring the value an SPA does add:
- excellent frameworks for client side logic (interactivity) - separation of concerns (presentation logic vs. backend) - improved DevEx => inc. speed of development => happiness for all
The sad thing is that an article like this will get plenty of eyeballs due to comments like my own adding to the algo, but it should have never made it above the fold.
It's because it's catchy and repeatable, which really fits with this guy's broader claimed focus (SEO). I found it really ironic because I've built plenty of SPAs without page transitions of any kind (because it wasn't a relevant requirement) and only started adding them because view transitions made them easy.
What does TFA stand for?
Among others (e.g.: "trans fatty acid"), in this particular case either "today's featured article" or "the f**ing article". I guess the latter.
For anyone looking to use this, I recommend using this CSS before the closing body tag. It disables the fade effect for visitors who prefer reduced motion, and the old page fades out while the new one fades in. (I've got an optional rule that keeps my header in place while the rest of the content fades out/in)
The View Transitions API is beautiful and I can't wait for it to become widely available.
I've soured on SPAs in the past few years. So much more can be done with standards than people realize. SPAs were best for specific use cases but we made them the default for everything. Marketing pages are built in React! Basic pages with marketing copy have a build step and require hundreds of megabytes of dependencies.
Like the author I've transitioned to a mantra of "let the web be the web."
But we have a whole generation of developers and designers that have come of age with SPA and mobile-like ux as standard. Getting everyone back to basics and understanding hypermedia, markup languages and cascading styles is a big ask.
"The View Transitions API is beautiful and I can't wait for it to become widely available."
a few comments below
"The view transitions API is a disaster."
I love HN.
i hate it.
Less is more, usually.
I once worked at a place where (for involved reasons not worth rehashing for this conversation) some of the backoffice, admin pages got rewritten in SPA fashion, after they had already been written in server-side fashion. It was an accidental experiment that showed me that the backend code did not decrease in size, whereas the frontend ballooned up to the same size as the backend (for fairly simple functionality even).
Now, this means you will need approximately twice as many developers. On the plus side, more work gets done on the client-side, so you probably need fewer servers for your billion users, and you may save in servers (and sysadmins) more than it costs you in developers to handle approximately twice as much code.
Except...99.9% of the shops using SPAs don't (and never will) have enough traffic for that tradeoff to make sense. The devs want (or at least wanted, back in the day) to go work at a company that did, so they wanted to use tools that would make sense if you're Facebook-sized. But, for the great majority of shops that made SPAs, there was no good reason to do so. This isn't Facebook's fault, but it is a reason why SPA's are annoying to so many people; they are almost always used in places that don't need them, and shouldn't be using them, in order to pad out a resume.
Cost is one factor, but what about user experience? Rich front-ends that users spend a lot of time in can save them time and the company money. Case in point, I work at a company where one team works on the front-end for customer support employees. They have to run through certain legal processes from time to time, like sending customers emails with contracts and the like, or looking up various data from various services. Their efforts have helped save these agents a lot of time, and part of that is putting more and more into a rich, clear and convenient front-end.
Of course, a lot of the effort also went to tying together various systems, replacing outdated ones, developing smarter and better chatbots and voice bots to guide users towards answers or self-service, etc.
I completely agree that SPAs are overused, but I also disagree that they necessarily balloon in size. An SPA is supposed to be a view, it is only supposed to concern itself with view logic. People just overcomplicate them endlessly with unnecessary crap.
For me the promise of SPAs has nothing to do with fluidity and all to do with having a separate data API and separate frontend (that can be native or web or both)
That’s why I don’t like SSR mixed with client side rendering. Either do a website or an app.
Not just for you, but for most people.
The author of this article is making shit up to justify writing an article where they can show of their CSS skills. It's lame and dumb.
I don’t want to write an article but I think when SPAs are called for they are the least worst option.
Usually I want to ship an app to customers, but for that I need an app the targets Apple platforms, hopefully I can built it to target iOS, iPadOS and MacOS but maybe those are three different apps. I need an app that targets Android. I also need an app that targets Windows, and I need a linux app.
Then I need to distribute all those apps, so I need to get onto the AppStore for MacOS, the play store for linux, and whatever Huawei/other Chinese manufacturers use, and whatever amazon uses, and probably have an “official” APK available for stuff like fdroid.
I need a windows installer, maybe a portable package for windows, and get onto MSStore (which will then cover winget).
I need to pick some collection of linux distros to target, usually targeting having a deb release and rpm can be good enough. And you can build an “installer” yourself if you are so inclined.
Or I could just ship an SPA, I had to build out the same servers if the data was not local anyway.
There's still value in web applications what can perform most of their operations client-side, when feasible. Lots of websites seemingly operate under the assumption of "If the client manages to connect to the server once, then surely it can maintain a stable, low-latency connection in perpetuity." This renders those websites unusable on flaky connections or with very high latency. Of course, plenty of SPAs are guilty of using 15 million unnecessary round-trips, but I worry that the current SSR-everywhere push will worsen this effect.
Consider also the origins of SPAs and their accompanying backends - mobile apps. I've worked with various projects where both web and mobile frontends would be using the same backend.
In theory you could build a SSR on top of that same backend, but for some reason that feels wrong, like an extra layer of indirection.
This works for some websites, not all. And often it results in significant loading times, because you're loading tons of unnecessary data. In many cases it is much better to send requests more frequently, similarly to how a server side rendered website would behave. Instead of fetching 10,000 products, just fetch a page of products. Much faster. Have endpoints for filters and searches, also paginated. This can be fast if you do it right. Since you're only sending minimal amounts of data everything is fast. The server can handle lots of requests and clients don't need a powerful connection to have a good experience.
Network requests themselves are not slow. Even a computer with a bad connection and long distance will probably have less than 500ms round trip. More like 50 to a few hundred at most. Anything beyond that is not the client, it's the server. If you make the backend slow then it'll be slow. If you make the request really large then the bad connection will struggle.
It's also worth mentioning that I would much rather deliver a good service to most users than make everyone's experience worse just for the sake of allowing someone to load the page and continue using it offline. Most websites don't make much sense to use offline anyway. You need to send some requests, best approach is simply to make them fast and small.
> In many cases it is much better to send requests more frequently, similarly to how a server side rendered website would behave. Instead of fetching 10,000 products, just fetch a page of products. Much faster. Have endpoints for filters and searches, also paginated. This can be fast if you do it right. Since you're only sending minimal amounts of data everything is fast.
This is actually a great example of what I mentioned elsewhere about how people seem to have forgotten how to make a SPA responsive. These are both simpler implementations, but not really the best choice for user interaction. A better solution is to take the paginated version and pre-cache what the user might do next: When the results are loaded, return page 1 and 2, display page 1, and cache page 2 so it can be displayed immediately if clicked on. If they do, display it immediately and silently request and cache page 3 in the background, etc etc. This keeps the SPA responsive with few to no loading spinners if they take the happy path, and because it's happening in the background you can automatically do retries for a flaky connection without bothering the user.
This was how gmail and google maps blew peoples' minds when they were first released, by moving data to the frontend and pushing requests to the server into the background, the user could keep working without interruption while updates happened the background without interrupting their flow.
Yeah you can do that, but it's not necessary. You'll have to figure out a clever way to first wait for the data the user actually needs on the first load, then silently cache the other stuff in the background. Then you'll have the best of both worlds, but it complicates the application. It might make sense for Gmail and google maps, but there are a lot of web apps for which it does not make sense to put the work into this.
> Network requests themselves are not slow. Even a computer with a bad connection and long distance will probably have less than 500ms round trip. More like 50 to a few hundred at most. Anything beyond that is not the client, it's the server.
Not if the client is, e.g., constantly moving between cell towers, or right near the end of their range, a situation that frequently happens to me on road trips. Some combination of dropped packets and link-layer reconnections can make a roundtrip take 2 seconds at best, and upwards of 10 seconds at worst.
I don't at all disagree that too many tiny requests is the cause of many slow websites, nor that many SPAs have that issue. But it isn't a defining feature of the SPA model, and nothing's stopping you from thoughtfully batching the requests you do make.
What I mainly dislike is the idea of saving a bit of client effort at the cost of more roundtrips. E.g., one can write an SSR site where every form click takes a roundtrip for validation, and also rejects inputs until it gets a response. Many search forms in particular are guilty of this, and also run on an overloaded server. Bonus points if a few filter changes are enough to hit a 429.
That is to say, SSR makes sense for websites with little interaction, such as HN or old Reddit, which still run great on high-latency connections. But I get the sense it's being pushed into having the server respond to every minor redraw, which can easily drive up the number of roundtrips.
Personally, having learned web development only a few years ago, my impression is that roundtrips are nearly the costliest thing there is. A browser can do quite a lot in the span of 100,000 μs. Yet very few people seem to care about what's going over the wire. If done well, the SPA model seems to offer a great way to reduce this cost, but it's been tainted by the proliferation of overly massive JS blobs.
I guess the moral of the story is "people can write poorly-written websites in any rendering model, and there's no panacea except for careful optimization". Though I still don't get how JS blobs got so big in the first place.
> Not if the client is, e.g., constantly moving between cell towers, or right near the end of their range, a situation that frequently happens to me on road trips.
Right, but how often is a user both using my website and on a roadtrip with bad coverage? In the grand scheme of things, not very often. I also think this depends on what the round trip is for. Maybe the 10s round trip is simply because it's a rather large request.
> I don't at all disagree that too many tiny requests is the cause of many slow websites
That's not really what I was saying, though I don't disagree with it. If you're sending multiple small requests then there are two ways to go about it: You can send all of them at the same time, then wait for responses and handle them as they come back. The other option is to send a request, wait for a response, then send the next etc. The latter option causes slowness, because now you're stacking round trips on top of one another. The former option can be completely fine.
But I'm not saying the client should be sending lots of requests. I'm saying they should get the data they need rather than all the data they could possibly need. This can be done in one request that gets a few kilobytes of data, you can fit 64kb in a single tcp packet. That's quite a bit of data, easily enough space to do useful stuff. For example the front page of HN is 8kb. It loads fast.
I'm also not saying you should use SSR. I do think that SSR is a great way to build websites, but my previous comment was specifically about SPAs. You don't have to send requests for every little thing - you can validate forms on the frontend in both SPAs and SSR.
Round trips are costly but not that much. A lot of round trips are unavoidable, what I'm saying is that you should avoid making them slower by sending too much data. And also avoid stacking them serially.
It's worth noting that the Speculation Rules API and the View Transition API are not stable in Firefox and therefore aren't supported by all major browser.
This browser compatibility gap is a crucial point - without Firefox support, these APIs can't be considered production-ready for sites that need cross-browser consistency, undermining the article's central argument.
yeah, if it's not in firefox it doesn't count.
https://bugzilla.mozilla.org/show_bug.cgi?id=1823896
also mobile safari so basically all iphones.
It does appear to be supported by iOS Safari 18.2+, which is the majority of iOS users.
https://caniuse.com/?search=view%20transitions
Basically it is supported just in Chromium & derivates then. Hard pass.
For me, this is the key takeaway from the article, leveraging experimental browser extensions for preloading future pages. In other words, exactly what a properly thought-out SPA does.
This reads more like "ditch Next.js" for traditional SSR.
A good SPA has a lot of benefits. Because it can be interactive like a native app. It can only use those benefits, if it is interactive to some extent (like gmail or google docs). Smooth navigation is a very bad reason for picking a SPA.
What do you mean by 'interactive like a native app'? The article is focusing on two main parts of making things feel like an app: page view transitions and speed/preloading. To me, those seem like a big part of what makes a site/app feel interactive. And letting the browser do the work and having real URLs has other huge benefits I appreciate.
But agree that for things like GMail, etc, a SPA approach definitely makes sense. I just think most SPA sites I come across aren't in that category.
Those aren't the main parts of feeling like an app. Feeling like an app means taking an action doesn't load a new page. Feeling like an app means the concept of a page mostly goes away.
I guess that's my point. With instant loading thanks to preload and smooth view transitions, taking an action, while actually loading a new page, shouldn't feel like loading a new page. Should be indistinguishable from a SPA action.
At least that's the theory. There might be other tells that degrade the experience, but not sure what they are?
Imagine Gmail, ChatGPT, Slack, and so on as server side rendered websites, but with smooth transitions. This wouldn't work at all.
Let's take slack as an example. We had those chat websites 20 years ago. The thread was in it's own frame and got periodically reloaded. It's just bad UX.
I think you're using "single-page app as opposed to no or limited JS on the client" while an alternative would be "single-page app as opposed to multi-page app". There's no reason you have to implement something like Slack by reloading an iframe.
Not reloading the document via HTTP while updating the content is the definition of a SPA.
I would argue that the line between an SPA and not is blurred. Consider progressive enhancement; or, per the Slack example, pages with content that's updated dynamically but which rely on reloading a whole page for navigation.
I would even argue that passing snippets of HTML around like e.g. Hotwire is still a middle ground.
You are extremely confused, you can absolutely have client side JavaScript in a website and poll or stream whatever you want like chats.
It has nothing to do with being a static website or an SPA, nothing.
I swear if I see another "SEO" guy or some rando web dev who joined the workforce after Covid complaining about SPAs by misrepresenting it, I'm gonna explode.
As someone who's been developing web apps since the 2000s, let me tell you the origin of SPA has few things to do with the "false promise of SPAs" he listed, but largely due to companies in the late 2000/early 2010s wanting to go "mobile first". This usually meant they still had a desktop second somewhere, which implied they were architecting the entire system to completely separate the frontends and the backend.
Before, what web devs meant by frontend was essentially server-side rendered HTML templates with perhaps a little bit of jQuery running on the client-side. Now, since mobile and desktop web apps are to share some business logic and the database somehow, people had to rediscover REST by reading Roy Fielding's Phd dissertation that inspired the original HTTP. This meant now every company was moving to service-oriented architecture and started exposing their backend APIs onto the open internet so their mobile apps and SPAs running in the browser can share the same APIs. This was a cost saving measure.
This period also coincided with the steady decline of full-stack webapp frameworks like Ruby on Rails and Django because for a couple of years, these frameworks had no good ways to support an API only applications. Django hadn't even reached 1.0 back then. This was a time when NodeJS was really starting to pick up momentum. Once people had started being more comfortable with JS on the server-side, lots of people suddenly realized they could push a lot of business logic to increasing powerful desktop browsers and phones, application hosts people now call "edge devices".
This is the true impetus of SPA. How is CSS going to kill this need?
I was completely unaware of view transitions and speculation rules. All of my products are server rendered for speed and simplicity. It’s amazing how snappy the interface is when your pages just load quickly because your software is performant. These seem like a great way to add an extra 10% of flavour.
SPAs are _applications_ folks. Just like app-apps are made -- spas are apps for the browser. SPAs in themselves are not complicated. State in an app is complicated. This is such a tired misunderstanding.
Page transitions aren't the reason we're creating single page web apps
What counts as "SPA" and what's an "MPA"? I've got a NextJS site (my personal website, you can probably find it given you know my last name and that I'm in the UK) that renders pretty much everything server-side. Technically it's still an SPA because if you turn on Javascript it'll load RSC and do client-side navigation.
If you turn off Javascript? Pages with client-only components (like the 100% client-rendered QR code generator) will show their fallback, everything else will load and render perfectly -- if a little less quickly -- than if you let Next do its thing. It's all rendered into the HTML, and it's actually more effort to not render components on the server. Progressive enhancement for the win!
> What counts as "SPA" and what's an "MPA"?
By how many times the Window's load event fire for your app.
Sounds like the major complaint here is trying to make the web into something it's not. It's something like 17 years since the iPhone app store. Web apps were not comparable to native apps then, and while they've made progress, web UX is still much poorer than a good native app. The Youtube mobile app has its problems but is so much better than the web interface.
Native and web have different strengths, that's ok.
I'm against bloat as anyone, but to see a wildly different perspective check out what people working on local-first have been doing.
You can pay some upfront cost and have wildly more performant apps.
It's incredible to write an article about UX with a main argument of "this way is as good as that way" without visual examples to prove they actually behave the same.
Right, I would like to see some examples of what he is talking about considering his tone of voice - he is literally telliong people to change their ways and use modern CSS and the entire article is devoid of such css.
"It’s faster, simpler, and better for everyone."
For who? In the modern day and age most devices can handle some JavaScript just fine. The DX provided by front end frameworks/libs is just unrivaled. Vanilla JS/jQuery work fine for small stuff, things quickly get out of hand in complex projects, when you have to bake in things like UX, validations, and have to program around the limitations of HTML. I'm confused as to why make such a claim as "Don't do SPAs for websites" and then throw in a dumb broad statement like "Just do vanilla". Yes, you can use CSS and achieve a lot of complex functionality. Yes you can use the existing HTML tags for a lot of things. Is it more maintainable than just using React? No.
You can't live in a silo. Yes, if plain HTML works for your website, why bother with anything else? Just do forms for any submit, input validation, there you go. But for a company competitive in the industry, particularly B2C SaaS, UI/UX does matter. And lagging behind, more than a trend, means customer perception.
We tend to be biased in our takes as tech-literate people (I do), but the average person gets lost if a button isn't emphasized enough.
A lot of website-in-spa break basic web stuff that simply works in old school HTML. It’s possible to do all that stuff correctly in react, but vast majority of people working on those simple websites seem to not give a damn.
Vast majority of information/portfolio websites have best UI/UX with classic HTML with some JavaScript sprinkled on top where it matters. Nothing says competitive-in-the-industry like contacts page that takes ages to load.
> The DX provided by front end frameworks/libs is just unrivaled
How? I spent 6 months exploring React, Vue, Node, Next,...
The DX for all of them sucks. The documentation sucks. Everything is wrappers of wrappers of npm scripts of wrappers of bootstrappers of boilerplate builders of...
Seriously. The worst.
Sucks compared to what?
Vite (build tool) + React is all you need, and a command line away from setting up React with TypeScript. If you don't like how "heavy" it is, you can use Preact. Similarly, for a Node (express) project, all you gotta do is `npm i express`, with additional setup if you want TS and other dev. niceties. Or just use a batteries included framework like Nest/Adonis and skip all that.
It's not that complicated, the frontend targets the browsers, so you have to transpile if you want to ensure compatibility, prevent theft, reduce the size, or not, and you could just wing it using the plain source code.
Again, it's the best for writing APPS. For an app, with complex navigation, features, UI states, it find it asinine that your biggest complains are about the packages.
A lot of people are responding with other technical considerations that may lead you to consider using an SPA pattern. But, note that the article is about responding to the stakeholder's request that it should 'feel like an app', and his point is that you can make it feel like an app without being an SPA. Non-technical stakeholders rarely bring up deep technical considerations, they almost always talk about what something should feel like. So, I think his argument, while unlikely to work on anybody, is valid.
I strongly disagree with this. SPA has its place and a very important one. It is not just about replacing JS animations with CSS animations. Of course it depends on the use case - SPA makes little sense in many cases and a lot of sense in few. But it still has it's stable place.
From my own point of view and experience, SPA makes the most sense when you do not want to bundle backend and frontend together in your server code. Having a separate FE and BE with clearly set API(json) is very important in many many many cases and it allows you to use the same BE for different FE, like desktop website, mobile website, desktop client(electron), mobile application... trying to do this on the server would be hell. Also worth mentioning is that if you want to make changes in your FE, you have to bring down you BE in order to deploy them, whereas if you have BE and FE separated, you can deploy the FE without any downtime.
There is a lot more that could be said but the main point is that moving data rendering into FE and letting BE just serve raw data is the way to go in many situations.
We have been moving computation between FE and BE for decades now, but I think the tech is now sufficient to not force us to pick one over the other but chose what works best.
Personally, I think that rendering the UI on BE is archaic and should be handled on the client via some bundled thin client code, ala SPA. So I will always prefer client-rendering over server-rendering, no matter the setup.
PS: You might be interested in https://data-star.dev/ which came out of dissatistfaction with HTMX and I think will be the way to go about bridging FE and BE in the future.
The main premise of this article is that SPA frameworks are primarily about transitions. This is yet another passionate argument built on a false foundation.
I'm fully convinced that it's time to kill SPAs on 99% of websites and that the community is too defensive on the topic.
It’s because the people that built and maintain the SPAs were beat into submission with the “SSR” bad message. Now people want them to do SSR again.
I agree. SSR that hydrates to an SPA is a pain in the butt and not necessary most of the time. This is why I favor something like Astro for websites... I can drop in a react embed when I need to. It's just a right-tool-for-the-right-job situation imo.
I absolutely love Astro, and it's my default for new projects. And I honestly feel like it's the only framework using React/Vue for their intended purposes; which is as an interactive layer on top of your SSR UI.
You're kind of already answering your own statement; websites should not be SPAs and vice-versa. Personally I think that an SPA should be something that lives behind a login.
Props for teaching me about View Transition API.
Absolute disagree with the way you're arguing though.
I'm not a fan of the SPA, or at least in practice, but there is something very attractive about going with a solution that everybody knows.
At work we are building a new "website like" frontend and it is a SPA (that internally operates as a MPA) built with React. The main reasons are we: know this setup well and know when hiring we will find people who know this setup as well. Beyond that, it will allow us to build out more application like features in the future if needed.
This approach has been popular in the industry for over 10 years now. Whereas most of the current discussion and tech on the frontend feels like churn and betting on the next thing. A lot of people just want tools that are mature and can get the job done regardless of them being the best tool under specific criteria.
I support a lot of this, especially for sites that don't need to be applications... but SPAs aren't just about flashy transitions and persistent elements. If you've got a bunch of live data you want to change on interaction an SPA is still hard to beat.
I’d like to add to the reasons for why you want an SPA over something with SSR:
* You have a large number of users compared to your resources and you can’t afford for your user base to always hit your server. Comparatively, deploying API-only apps is far cheaper when you’re resource-starved (eg early stage startup).
* You don’t care about SEO, for example you’re building internal tooling. You then don’t need to care about hydration at all. Much simpler to separate concerns (again esp at the beginning).
* Offline mode (eg PWA or reusable code in Electron) or cases where you want to be resilient to network failures. In the case that your app is dependent on the server for basic functionality like navigation, you can’t support any type of offline mode.
It is possible to deliver a lite, PWA/SPA with vanilla JS and no loading spinners. Users can install it on their mobile device. I've done as much with blockchain dApp front ends. It isn't necessary to hijack the address bar or abuse the back button to achieve this. Modal dialogs, collapsible elements, tabs and simple anchor elements are enough. Yes, you can allow in-app back buttons to return to the previous modal's state, although that might suggest that the UI pattern should be simplified.
"State management" from a framework seems ridiculous. Developers should be able to handle their application's state with JSON objects representing reasonable abstractions of concerns. Typically, this would be similar to the data you query from the web. Therefore, upon launch, you can populate your document using <template> elements from cached data in localStorage or some of the newer options. When network connectivity is available, you can update the state using the same functions.
Perhaps this isn't something you would trust your large enterprisey team to do competently, but for a solo developer with a distaste for React and heavy frameworks, it seems like the obvious approach.
Interested to hear how others building sans frontend frameworks. If you love React and loading spinners by all means feel free to ignore this. To each their own.
This article would benefit from an example page to show how these "feel".
Here are a series of demos. They work in Chrome or Safari.
https://view-transitions.chrome.dev/
Here's an older, more designed demo that only works in Chrome.
https://live-transitions.pages.dev
Run this snippet from TFA in the console on GitHub:
Then try to update the attribute manually instead, and compare the butter-smooth transition with view transitions vs. without.On one hand, SPAs took off and became massively popular. On the other, I’m still curious why PWAs—especially the kind with service-worker-powered offline access—never really did. I don't like SPAs only if I find them bloated and with a messed up browser history that back button moves you out of the website.
Imagine an e-commerce site that lets you review your order history and product pages offline (even if a bit outdated). That kind of experience feels genuinely useful—much more so than the "you're offline, here’s a cute dog (I love the pictures though)" fallback most sites provide.
Over the weekend, I experimented with service workers for the first time (assisted by Vibe coding). My initial impression was honestly a bit magical—“this website works offline, unlike most mobile apps these days that are just WebView-wrapped SPAs and crash offline.” [1]
That said, debugging was rough. Vibe coding output had subtle issues I found hard to untangle as a newcomer, cache saved v/s cache matching was being done incorrectly in the code, which LLM wasn't able to point out (cors/non-cors requests had issue).And Chrome’s DevTools made debugging manageable, but Firefox’s service worker support felt clunky in comparison (personal take).
Curious if others feel the same—are PWAs underused because of DX hurdles, lack of awareness, or just industry momentum around SPAs?
[1]: https://ball-sort-game.vercel.app/
Offline is good for things like your ball sort game or a calculator. But the developers of that sort of thing want to make money, so they sell apps in the app store.
Offline order history is only a marginal improvement on the e-commerce experience from a customer and business perspective, so it's more appealing to us engineers who appreciate it as a feat of engineering prowess.
In other words, offline isn't PWAs killer feature. Besides, native apps can do it too.
PWA's killer features are circumventing the app store and the app store tax and not maintaining two codebases for Android and iOS.
Another Hacker News client would be a good example of a good PWA that you might install to your phone. It could have niceties like "save for later" or special styles applied to your favorite commenters. Offline support would be useful too, of course but not the main reason to develop a PWA.
Uncensored, paid content is another significant use case.
> PWA's killer features are circumventing the app store and the app store tax and not maintaining two codebases for Android and iOS.
Agreed, I wish we lived in world where PWAs had atleast an equal share compared to mobile apps. Apps winning, mostly have been a suicide for privacy.
Coincidentally, there's another HN story with even more relevance to our discussion. [1]
[1]: https://news.ycombinator.com/item?id=44689059
> The reason SPAs became the default wasn’t because they were better. It was because, for a while, they were the only way to deliver something that felt fluid.
So they were better.
>The reason SPAs became the default wasn’t because they were better. It was because, for a while, they were the only way to deliver something that felt fluid – something that didn’t flash white between pages or jank the scroll position.
This was NOT the reason why.
SPAs are better because it offloads as much processing as possible to EDGE cpu's. The idle compute among all users aggregates to a massive amount so might as well use it and minimize html construction and routing on the server side.
If this wasn’t written by Claude then Claude was trained on the authors posts!
As others have noted this guy isn't qualified to write about this topic as he doesn't understand the difference between MPA and SPA.
I see some people claim that client-side routing isnt the strongest argument for SPA:s. And that is probably true from a technical point of view. However, lots of times users/clients want that even if they dont care about the rest (which is why I love how easy HTMX and Astro make it to add client side routing on top of a normal MPA).
Astro is a breath of fresh air in this space really.
The thing about SPAs is that computation can be done in the customer's machine. That usually makes it worse for everyone, both devs and users (although sometimes it doesn't). I personally believe that we can create better experiences routing more pages with more imagination, but at times this industry is quite vocal on what "user expectations" are.
"It is a couple MB payload, so its bad" never really reasonated with me.
YouTube serves hundreds of MB payloads to serve information. Even a bloated SPA is tiny in comparison.
Although, I think YouTube is also an SPA.
Some websites serve hundred MB payloads to show a hero video.
Why is JS optimization the great evil when there is often so much more waste in media or design choices?
This is the biggest mess of an article I have read for a long while.
The concerns of SPAs and CSS are completely orthogonal.
I completely agree.
My SPA navigation solution is just simple CSS toggle of display none/block and then force it on page load if there is a matching URL fragment. Total JavaScript to make this SPA navigation is about 20 or so lines of JS. Everything else is CSS and WebSockets. The state management is almost as simple.
But designers will always find a way to make our live miserably. They are told to never accept same behavior and always press users to there way of navigation and thinking. The bullshit they call design is there way of expression
I looked up the compatibility table: https://caniuse.com/cross-document-view-transitions
Safari has supported this on both desktop and iOS since last year. But I had to look, because the article makes it sound like Chrome and its family are the only browsers that are modern enough for the feature. Safari uses WebKit, not Chromium.
"Modern browsers – specifically Chromium-based ones like Chrome and Edge – now support native, declarative page transitions. With the View Transitions API"
Not only SPAs are here to stay, but they're eating up native app on the desktop (with Electron et al., it's much easier to hire TS devs and write your app once rather than have different native codebases for Windows, Macos and Linux).
Now, I understand the argument that simple article-based websites shouldn't necessarily be SPAs. Page transitions are perfectly doable in pure HTML and CSS. But if you have less then trivial local state and complex + specific components, forcing the MPA pattern will only complicate your codebase.
It's time for sending HTML rendered on server with CSS, and JS for enhancement only to kill the SPA.
I'm not talking about this from a technical standpoint, though there are many reasons that in most cases this is the best technological fit.
I'm talking about this from the position of "what I want to use". I'm sick of loading and navigting overly JS heavy, overly styled, fragile "apps". When I encounter a "proper" website that loads fast, and I can understand easily it's like a breath of fresh air.
The SPA test should be: can you keep a picture-in-picture video element playing while navigating between pages?
If the vanilla web can't do this easily, then it's not a good solution to your need for a SPA.
CSS, URLs, links, forms, POST-Redirect-GET, page reloads. Efficient and user friendly on the modern web. HTML & browsers have smoothed out a lot of rough edges.
If you think SPA's became the dominated architecture because of page-to-page transitions, I'm not sure how to have a productive conversation with you.
Plus which, the author says that the next page will be conveniently pre-loaded when the user hovers over the link. Plenty of time there's ~0 hover time, especially for experienced users. So the user is still going to be looking at a spinner while the full page (which could be pretty beefy) is loaded in from the server.
it makes more sense than ever to deploy a semantically correct page with clearly distinguished templatnig, styling, animation logic and most importantly - data semantics. so that the robots and LLMs can slurp it without clicking too much. all the styling can follow in a very standards-compliant manner.
lol who even used SPAs because of “smooth transitions”? I’ve never noticed anything resembling a transition on any React/Vue site
might wanna consider redesigning your site, it looks like AI spam
Yeah, it's really missing the charm you'd expect from a AI-free spam site. Maybe more flashing text?
It's time for...
No, you found some tradeoffs and decided that the drawbacks are worse than the advantages. If industry disagrees, they tend to have their reasons, but as we love being tortured artists and really feeling our individualism, offbeat hot takes are always in demand.
That's all I see in quite a few HN titles ;D
Websites and apps that feel like quality are generally made by people who can achieve it. You'll get shit static sites or shit SPAs if you have shitty devs. It's not beyond reason. If you are shitty chef, your food is going be shitty. So yeah, here's the big secret about programmers:
They are mostly shitty
---
Interestingly, every landing page or website for recent AI apps have looked AMAZING. Designers and standard website developers are totally on point. It's just, crappy developers who can't create a rich experience on top of incredible design that's the issue. CSS is not going to fix what can't be fixed (some people are not supposed to be in this profession, but hey, it pays ... for another three or so years).
CSS is uderrated and almost never even discussed in front end interviews. Its all javascript javascript javascript.
Javascript is over-rated.
CSS > JS
I don't know if CSS is underrated, but it's definitely a speciality that a lot of software developers don't (want to) specialize in. It's like the front-end equivalent of SQL; so much is possible in SQL, but most logic is built in application code because SQL is scary.
Most logic is built in application code because it makes it easy to structure, reason about, and test. Developers should be scared of code that is hard to test and reason about.
Most of my personal app projects are SPAs, because it’s easy to just pop some static files in my static file server and serve a whole app with routing and functionality without having any server logic. Way simpler to maintain, since I can just sync my ‘apps’ dir and all my mini-projects are deployed.
Can do all that without a SPA.
Not really... like sure if you want a static site, but I'm talking about static apps. Like if you want to handle /id/$id routes with data based on user-generated content saved in localStorage... you'll have to handle routing somewhere. Basically, what I'm saying is that if you have an stateful app that doesn't require server state, I think SPA+PWA is pretty ideal.
Any website that is an app is going to need SPA like features.
Especially if they have some kind of AI integration feature.
SPA was primarily about reducing ajax-type calls to make the page more responsive, not CSS-type transitions.
(I do agree that SPA is waaaaaay overused and most of them would work just as well with server side logic with less complexity.)
I agree. What is more, you can even use HTMZ instead of JS frameworks and Pure HTML Out-Of-Order Streaming using Declarative Web Components: https://github.com/niutech/phooos
what a nonsensical title, clearly written by people that only program skins around applications instead of applications themselves. CSS and SPA do not even solve the same problem.
I'm sure there exist (foolish) efforts to make CSS somehow able to do some UI logic, but that is never a good idea. CSS is a poorly made/overly complex spec that deserves to die. It's too late to make that argument unfortunately, but to want even more of CSS in the modern web stack is kinda lunatic.
If full page requests have an ability to persist complex state, cache to the point of imperceptibility parts of the page that aren’t changing and never blink, I guess?
SPAs and packaging your app inside a chrome container needs to die a hard death. Why is everything in 1 window. Why in 2025 can i not have multiple chat windows open?
SPAs are good for making offline-available apps/sites. Not everyone has (or wants to have) an internet connection all the time.
Some people download mobile apps everyday but are afraid all of a sudden of SPAs which is a similar development model. Doesn't make sense.
The author is living in some crazy land bubble... or I am.
I can't relate to the situations, problems, or solutions this article seems to just take for granted.
The site feels so laggy on my mobile browser that I had to stop reading. Looks like CSS is not inherently performant.
This guys is really on a mission. Is there really a war against SPAs? Well designed SPAs can be incredible.
Speculation rules works the same as instant.page, by prefetching the url onhover. Right?
Ie4 had these. It was pretty cool. I forget how they implemented it. Maybe active x?
i think this is good for websites but my current struggle with Astro is the long build times for a blog with many many pages. current build time is 10 minutes and it does not spark joy.
The author looks like Edward Norton.
"I am Jack's native declarative transition."
Everyone is completely missing the point of this article, which I find amusing and terrifying in equal measure.
He is _not_ talking about a SaaS dashboard SPA. He's talking about marketing sites and other content heavy stuff like blogs, landing pages, etc. It mentions this in many places if you go past the headline.
He is completely correct. SPAs should not be used for marketing sites full stop. Perhaps there are some edge cases where it may make sense (though I cannot think of any) but in general, if you are building anything that resembles a blog or landing page with nextjs et al you have done it wrong, close the code editor and start again. I'll give you a pass if you are developing an MVP of something and you need something up very quickly, but if you have any commercial traffic you will thank my later.
I have done a lot of audit work for this kind of stuff. Things I've seen:
10MB+ of React/JS libs to load a simple blog page
Putting images in the bundle, base64d. So badly that the page crashes OOM on many devices.
And my favourite of all time - shipping 120MB (!) of JSON down for a catalog. It literally loaded _the entire database_ to the front end to show _one_ product. It wasn't even an ecommerce site; it was literally a brochure of products you could browse for.
You of course don’t need 10MB of JS for a React blog or 120MB for an e-commerce site.
You’re not mad at SPAs, you’re mad at bad developers.
But even the most well optimized nextjs/react 'blog' or ecom site performs and order of magnitude worse than a SSR version, simply because you have to bring in runtime stuff? I'm giving extreme examples; but I've seen very very able development teams totally shoot themselves in the foot with this.
Next/React sites can be SSRd just fine. If a db call is slow it's going to be just as slow for a PHP page as for a React page.
But even if you SSR them you still need to send at least 100KB (and probably far more) of JS down to the browser to hydrate state and handle any interactivity.
You need JS to handle interactivity no matter what. And 100KB is nothing, a single image is larger.
Yeah… Let’s see how less terrible those MPAs with CSS tricks are.
I like how client side state is managed in a SPA more than an MPA
SPA = single page app
One of the reasons people like SPA so much is componentization.
Here's my header component, and all its scoped CSS, and here are the 5 subcomponents that make it up, and all their individual scoped CSS.
Page transitions are 0.001% of the desire to go the SPA route.
Fun fact: custom elements exist. They're just as hard to work with as React components (i.e. complete nonsense until you stop fighting them and do it right). Except they don't violate the browser model and don't require you to be married to a specific framework.
Honestly, I never used an SPA because of transitions. I recently decided to use one because of the persistent state. Not sure how CSS solves this.
To be frank, I tried the cross-page fade transition on my Hugo static site, hosted on AWS ClousFront, and I couldn't see the difference. It's probably only relevant if your site is bloated to begin with.
Good article. But could have shown some examples.
> Native CSS transitions have quietly killed the strongest argument for client-side routing
Huh? We didn’t build my company’s product as a SPA because of transitions. We did so because it is a shared codebase with native and because it has an offline mode.
Great post. Didn’t know about these new features.
> Native CSS transitions have quietly killed the strongest argument for client-side routing
What? This guy wanted to show off how much he knew about CSS and decided the only way to do it was completely make stuff up about a hot-button topic in webdev.
Ok, now try to implement a tree component in an MPA. But not a crappy tree component that only opens one branch at a time, like in a page from 1998. A tree component that remembers the open/close state of each branch.
Before the SPA, these were common issues. That’s why there were a gazillion Java server pages frameworks to solve them. You also have frameworks that tried to encode the UI state in some way. My favorite was Seaside, which used continuations to store the UI state.
The following article should probably be titled “It’s time for modern bloggers to kill the clickbait titles” and discuss the trade-offs of each architectural decision more balancedly.
i see "SPA" and my mind immediately reads that as "special purpose account" lol.
I wonder if my slop radar is oversensitive to em dashes and the construction: “it’s not just about foo, it’s about bar” because this post seems human written but the indicators are flashing
There are also many non sequiturs. The sentences only read fine if you don't think about what the author might be trying to say. I also think that this reads like the "author" was an LLM and, therefore, isn't trying to say anything.
À propos of nothing – I'm human and I like using special characters, including en dashes. ;)
Rolling eyes
Another person mixing up web apps with web sites.
We do need frameworks for web apps. Yes people were wrongly making websites using frameworks.
But I am busy building web apps and without frameworks it is not feasible to build one.
Exactly. I remember the times when webmail clients were SSR applications. Roundcube and Gmail were game changers. Webmail finally felt smooth and usable.
Web shops are somewhere in the middle, they need a little bit of interactivity for the cart, especially if the user opens multiple tabs.
But static websites should never be SPAs.
You really don’t need the frameworks for web apps either.
I guess you never worked on a complicated web app that was 100% jQuery, because web frameworks were not a thing yet.
I was a JavaScript developer for about 15 years and I moved onto something else because most of the people doing the work can't program. Not at all. I got tired of being held hostage by people who couldn't function without more help than they needed.
I also get tired of the arguments from ignorance. The you don't know how hard life is type of bullshit arguments. I do know because I have done this work, probably much longer than you, and its not as challenging as you are claiming.
What if I told you that you didn't need jQuery either.
Using the DOM APIs directly? Please do that. Have fun!
I do it and its just not significant. You should try it before evoking a holy war against it.
What if I told you that you didn’t even really need javascript for most things - even more involved web apps. HTML and CSS is plenty for many things.
I did, around 15 years ago. It was honestly not that bad.
How many people did you have on your team? What was employee turn over on the project? How long was the development?
Second that.
Add to it dev churn each 6 months one dev leaves an new joins full of fresh new ideas how to jquery. In the meantime also 2 freelancers adding their stuff.
there's lots of SPAs that look like normal web pages. Twitter for instance.
Once again people totally miss the point of SPA. What does SPA stand for? Hint, there is no website in there.
Id argue all the grousing of spa is because people made websites as apps when they should have been websites instead.
Btw view transitions are pretty slick and require zero js to get snazzy transitions.
Edit: there are some significant limitations with view transitions around performance and a few other gochas I should mention when they are used with pure css. I still love em tho.
When SPA framework in CSS?
I don't know how I feel about this one, honestly.
> Build a site like a site. Use HTML. Use navigation. Use the platform.
Sure, but what about all the other problems that aren't solved by View Transitions? There's some truth to the fact that frameworks like Next.js has jumped the shark. But they're not solving the problems of _just_ the SPA.
is the author secretly the ceo of htmx?
CSS is a mess for anything besides basic static layout. You can force it to do fancy things, but it's hacky and gives you code that doesn't really say what it does. You can do scss, sass, etc, but still eh.
is this a growth hack article trying to get attention on SPA hate on HN?
but is it ever going to be time to kill the CSS ?
Single-page Application
TL;DR: article means traditional websites with server navigation (now dubbed MPAs, multi page applications) have evolved positively with better handling of page transitions. But they choose to frame this idea by trashing SPA, while both MPA and SPA have a role to play.
"... someone says the words. A CMO. A digital lead. A brand manager. ... it’ll be an SPA."
Why not spell out CMO and SPA and a civilian such as myself will not have to toddle off and dig out a search engine?
If you are going to get all assertive and pissed off, please be inclusive too.
The problem is he's confidently wrong in believing Single Page Applications are about page transitions. Not at all. It's more about keeping state and an application-like experience. Like playing a song on spotify and changing to the search page and the song keeps playing... that type of thing.
Thank you for giving me a starting point to work with.
FFS, I have a degree in Civ Eng but if I start wittering on about bridges and roads I will define abbreviations. Its common courtesy.
With regards your analogy involving Spotify: I ripped all my CDs to FLAAC some years ago. The tapes and records took a little longer. No idea what a Spotify is. Well I do, I'm an IT consultant, but I don't actually care, I'm a 50 something IT consultant! I bought my music years ago and listen to it on my gear and from my gear alone.
This SPA thing sounds like it is getting out of hand and it also sounds like there are tribal divisions being drawn up. IT does love a tribe! We even have multiple internal tribes: devops, webdev and so on.
I'm nominally a PHB ...
The view transitions API is a disaster.
I spent weeks trying to get it to behave predictably and failed entirely.
Don’t use this api if you value your sanity it’s the worst api I’ve used in a browser.
What particular issues have you experienced?
It’s extremely hard to use reliably.
Anyone enthusing about this API hasn’t done much with it.
What exactly hurt the reliability? Early on, I often ran into false starts because I did not pay enough attention to proper render blocking.
It’s a ridiculous API that is way too complex.
Try using it and you'll see.
It takes huge amount of setup which it then seems to pay attention to or not, depending on his knows what factors.
Go ahead try it for something beyond basic usage then tell me how reliable and easy it was.
I tried something here: https://vtbag.dev Took me a while to figure things out, but I'm happy to share what I learned. That's why I asked: I would be glad to help with concrete problems.