Why I hate your Single Page App (2016)(freecodecamp.org)
freecodecamp.org
Why I hate your Single Page App (2016)
https://www.freecodecamp.org/news/why-i-hate-your-single-page-app-f08bb4ff9134/
35 comments
Angular is the most productive platform I've worked with. I'm finishing projects in half the time it took before adopting angular. I highly recommend pairing Angular with Akita or Elf for state management.
The article author has valid complaints about SPAs and the devs only focus on how easy it is for them.
1. I wasn't replying to OP. 2. Angular has full support for server side rendering which eliminates all of the authors complaints. 3. When I started developing SPAs there were no frameworks,and it was significantly more work.
Looking at your login, you probably gone through a lot more before cgi-bin. Nice.
Yep, I've seen a few things :)
From 2016. SPAs have become much more annoying since then.
I opened this expecting the normal grungy tirade of intolerance & an general small & petty disdain for JavaScript. But there was the authors name and I knew this would be something different and higher class! And how!
I feel like the essence of this page needs some kind of rallying flag, some moniker. "Web first SPAs" or "browsing-compatible SPAs," something that can be made recognizable where the web dev tech hipsters can start pressuring each other & companies into doing the right things and not letting their SPAs break the web! This should be critical & visible drive in all web architecture, but its not notable as it's own thing, only seen in the absence of normal good functioning; having a good name to rally around & hype up in the noosphere feels needed.
> Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab. They offer no way to link to something that I look at. (Oh, I know there are exceptions to this rule, but they typically require effort — a lot more than many developers are prepared to invest).
> My main beef with single page apps, or SPAs for short, is that they’re not "on the web".
I do see a decent amount of reasonably well built apps, albeit most handle one or two pieces not perfectly. But there's also plenty of dark world dark pattern apps where things you click on aren't links.
(Subrant: this is also one of the things that drives me the most up the wall about PWAs. PWAs throw away most of the best parts of the web! Urls are quasi invisible, there's no tabs (unless the app builder specifically builds around Tabbed Application Mode), there's no forward/back buttons, nor bookmarks. PWAs ironically are as regressively anti-web as it possibly can come! They happen to be built with web technology, but obfuscate all web faculties the user might have. Piss on you PWAs, you are trash.)
I feel like the essence of this page needs some kind of rallying flag, some moniker. "Web first SPAs" or "browsing-compatible SPAs," something that can be made recognizable where the web dev tech hipsters can start pressuring each other & companies into doing the right things and not letting their SPAs break the web! This should be critical & visible drive in all web architecture, but its not notable as it's own thing, only seen in the absence of normal good functioning; having a good name to rally around & hype up in the noosphere feels needed.
> Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab. They offer no way to link to something that I look at. (Oh, I know there are exceptions to this rule, but they typically require effort — a lot more than many developers are prepared to invest).
> My main beef with single page apps, or SPAs for short, is that they’re not "on the web".
I do see a decent amount of reasonably well built apps, albeit most handle one or two pieces not perfectly. But there's also plenty of dark world dark pattern apps where things you click on aren't links.
(Subrant: this is also one of the things that drives me the most up the wall about PWAs. PWAs throw away most of the best parts of the web! Urls are quasi invisible, there's no tabs (unless the app builder specifically builds around Tabbed Application Mode), there's no forward/back buttons, nor bookmarks. PWAs ironically are as regressively anti-web as it possibly can come! They happen to be built with web technology, but obfuscate all web faculties the user might have. Piss on you PWAs, you are trash.)
I feel that this argument is pretty outdated at this point.
Most new SPAs people build use frameworks like NextJS that solve all of the big complaints.
Sure, there's plenty of old, crufty SPAs from the pre-react-router days still out there. I also dislike those apps.
I guess my point is... there was a time when you could blanketly hate SPAs and be mostly right about the category. And you could be mad at a company for even daring to try because they were very likely to screw it up. But I think we are now past that period. SPAs are now pretty awesome and fast and good!
Edit: ah, this article is from 2016. Which actually was a very valid time to hate SPAs! Maybe this is a good moment to applaud the hard work of folks at Vercel for fixing the problem :-)
Most new SPAs people build use frameworks like NextJS that solve all of the big complaints.
Sure, there's plenty of old, crufty SPAs from the pre-react-router days still out there. I also dislike those apps.
I guess my point is... there was a time when you could blanketly hate SPAs and be mostly right about the category. And you could be mad at a company for even daring to try because they were very likely to screw it up. But I think we are now past that period. SPAs are now pretty awesome and fast and good!
Edit: ah, this article is from 2016. Which actually was a very valid time to hate SPAs! Maybe this is a good moment to applaud the hard work of folks at Vercel for fixing the problem :-)
The question is why? Sometimes SPAs are justified, like for a webmail, but in many cases, what is the point? For example, I see the Washington Post on the front page of NextJS. It is a newspaper, serving articles is what the web does best, you really don't need to do anything but serve static HTML files, with a style sheet if you are fancy, and the browser does everything else for you.
I agree with you, however: The WaPo has a veeeeery wide variety of endpoint devices. If they stuck to HTML + CSS it would mean an imperfect output on things like kiosk panels, public news stand displays, ebook readers etc. or needing to maintain multiple output services server side, with potentially different authoring considerations.
With their current approach, they can share one content authoring environment over an API that splits all render concerns to the consuming client.
Sounds a lot like what HTML was supposed to do in the first place doesn’t it… but not all devices support arbitrary html web browsing, nor would you want to serve a full page to most , so the next best option (according to some) is API plus javascript client for the web side of things.
While I don’t think this path is correct, given the tools we have I do see why it is used so frequently.
With their current approach, they can share one content authoring environment over an API that splits all render concerns to the consuming client.
Sounds a lot like what HTML was supposed to do in the first place doesn’t it… but not all devices support arbitrary html web browsing, nor would you want to serve a full page to most , so the next best option (according to some) is API plus javascript client for the web side of things.
While I don’t think this path is correct, given the tools we have I do see why it is used so frequently.
> With their current approach, they can share one content authoring environment over an API that splits all render concerns to the consuming client.
Do you need an SPA for this? You have to write some code to handle different devices, I don't think it makes a lot of difference if it's being done in JS on the client side or rendered as HTML and spat out to the user direct?
Do you need an SPA for this? You have to write some code to handle different devices, I don't think it makes a lot of difference if it's being done in JS on the client side or rendered as HTML and spat out to the user direct?
Yeah :( Unfortunately, frontend developers have all specialized on building SPAs, and that's all they build now. I've tried to change this in my company, but the frontend devs resist strongly.
Please give me a site in NextJS that doesnt break my browser
some that i've built recently with app router that are intentionally minimalistic
- https://rauchg.com
- https://next-ai-news.vercel.app/
- https://emoji-todo.vercel.app/
Next.js scales up and down in complexity / ambition. On perf:
- https://twitter.com/rauchg/status/1652093980958683137
- https://twitter.com/rauchg/status/1744183168541007878
- https://rauchg.com
- https://next-ai-news.vercel.app/
- https://emoji-todo.vercel.app/
Next.js scales up and down in complexity / ambition. On perf:
- https://twitter.com/rauchg/status/1652093980958683137
- https://twitter.com/rauchg/status/1744183168541007878
Two of those three are simple content sites. Why even use JS at all? I feel like we're reinventing the wheel with a ton of added complexity these days.
JS is used for fast page transitions and stuff like that, but funny enough I'm pretty sure I end up shipping less JS overall by running server-side JS.
Last I checked, a Tweet embed alone was several mbs of JS, and it causes a bunch of layout shift and loads third party resources. On my blog they're pre-rerendered and shipped statically[1]
Probably the strongest reason though is to not set a 'power cap' on your project unnecessarily. It'd suck to have to rewrite a project because you got trapped in a local maxima, which is why i always share you can have your 100 lighthouse cake & eat it too.
[1] https://rauchg.com/2021/making-the-web-faster#next-momentum
Last I checked, a Tweet embed alone was several mbs of JS, and it causes a bunch of layout shift and loads third party resources. On my blog they're pre-rerendered and shipped statically[1]
Probably the strongest reason though is to not set a 'power cap' on your project unnecessarily. It'd suck to have to rewrite a project because you got trapped in a local maxima, which is why i always share you can have your 100 lighthouse cake & eat it too.
[1] https://rauchg.com/2021/making-the-web-faster#next-momentum
the new Node.js website is made NextJs
> Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab. They offer no way to link to something that I look at.
In my experience, this is very simple when using the Angular Router. Indeed, it's difficult to not get it working.
https://angular.io/guide/router
In my experience, this is very simple when using the Angular Router. Indeed, it's difficult to not get it working.
https://angular.io/guide/router
> They have a URI, but only for the whole thing, not for all of those valuable things that are inside of it.
This isn't always true, and I wouldn't actually find it to be false more most SPAs I use. Its straightfoward to sync the URL with Javascript state. Most high grade SPAs takes URIs seriously, because they are still the primary way users share views with each other. Traditional URIs point to static resources, but most SPAs contain at least a record identifier, and possibly even a view state. Google Slides is a SPA, but I can easily share a URL with another person, and if they have access they will end up on the same slide as the one I was viewing when I copied the link.
> Business logic does not belong in the client, unless you like having to redundantly maintain the same logic in every kind of client you support (in addition to maintaining it on the server, of course — remember that you can never trust any client).
I don't see how moving view state management from the client to server solves this issue. Of course you can't trust the client, anyone can spoof API calls. But even basic forms have this issue. You can't trust a form just because you generated options on the server.
Also view logic is tightly coupled with the client UX. Moving it to the server does not magically make it reusable. Additionally, having client side logic often is more about displaying a list of possible options, than validating correct choices. Just writing server side validation does not eliminate the need for client side business logic.
This isn't always true, and I wouldn't actually find it to be false more most SPAs I use. Its straightfoward to sync the URL with Javascript state. Most high grade SPAs takes URIs seriously, because they are still the primary way users share views with each other. Traditional URIs point to static resources, but most SPAs contain at least a record identifier, and possibly even a view state. Google Slides is a SPA, but I can easily share a URL with another person, and if they have access they will end up on the same slide as the one I was viewing when I copied the link.
> Business logic does not belong in the client, unless you like having to redundantly maintain the same logic in every kind of client you support (in addition to maintaining it on the server, of course — remember that you can never trust any client).
I don't see how moving view state management from the client to server solves this issue. Of course you can't trust the client, anyone can spoof API calls. But even basic forms have this issue. You can't trust a form just because you generated options on the server.
Also view logic is tightly coupled with the client UX. Moving it to the server does not magically make it reusable. Additionally, having client side logic often is more about displaying a list of possible options, than validating correct choices. Just writing server side validation does not eliminate the need for client side business logic.
Half of the article is just ragging on a specific subset of poorly designed SPAs (those that don't use HTML 5 history mode with proper server side routing set up), which the author acknowledges before finally moving onto other points.
The other half I'm not even convinced these are real problems:
> A fantastic example of the problems created by the SPA approach is parallelization of work. If you have a team of multiple people, or God forbid, multiple teams working on the same SPA, you need to come up with a good way to support this. Instead, you can just have each of those teams build their own web application. Each of those applications can be connected to every other one built at the same time by the same organization (as well as to every other web application residing anywhere, if you want to) — in fact relying on the core strength of the web.
This paragraph I guess presents a problem and it's "ROCA" solution, but the solution proposed works for SPAs too. You can just make multiple SPA applications.
The other half I'm not even convinced these are real problems:
> A fantastic example of the problems created by the SPA approach is parallelization of work. If you have a team of multiple people, or God forbid, multiple teams working on the same SPA, you need to come up with a good way to support this. Instead, you can just have each of those teams build their own web application. Each of those applications can be connected to every other one built at the same time by the same organization (as well as to every other web application residing anywhere, if you want to) — in fact relying on the core strength of the web.
This paragraph I guess presents a problem and it's "ROCA" solution, but the solution proposed works for SPAs too. You can just make multiple SPA applications.
I think that, in 2024, a lot of these problems aren't as bad as they once were, but when this article was written in 2016, SPAs really were a mess. Since then, people have mostly solved the URL problem and the back-button problem, and I think that if your organization has the headcount to support it, there are advantages to having the kind of very clean separation between your backend and your user interface that an SPA can provide. For instance, They can be developed by different teams, on different release schedules. Or, you can replatform your backend without rewriting your frontend.
Even so, I kind of wish that most websites still used old-school server-rendered HTML. I still run into all kinds of glitches that just could not possibly happen on a server-rendered site. As an example, I like to visit the Deutsche Welle website to catch up on European news stories that don't make their way to the US, and sometimes their site just flat-out doesn't load, because of some caching problem that I don't care about, because it isn't my problem as someone who just wants to read the news. Since the best DW's SPA architecture can possibly do is to make it look like server-rendered HTML, it's just nothing but downside to me personally. It might make sense for Deutsche Welle itself, but I don't work for DW, and I don't get paid to care about their problems.
In the end, I think the overall message of the article still resonates in 2024, even if it doesn't resonate as strongly now as it did when it was written. I think SPAs are good technology when they are used in the right way for the right reasons. But there's a kind of dogma surrounding heavyweight JavaScript frameworks, and I think it pays to be a little skeptical as a result.
Even so, I kind of wish that most websites still used old-school server-rendered HTML. I still run into all kinds of glitches that just could not possibly happen on a server-rendered site. As an example, I like to visit the Deutsche Welle website to catch up on European news stories that don't make their way to the US, and sometimes their site just flat-out doesn't load, because of some caching problem that I don't care about, because it isn't my problem as someone who just wants to read the news. Since the best DW's SPA architecture can possibly do is to make it look like server-rendered HTML, it's just nothing but downside to me personally. It might make sense for Deutsche Welle itself, but I don't work for DW, and I don't get paid to care about their problems.
In the end, I think the overall message of the article still resonates in 2024, even if it doesn't resonate as strongly now as it did when it was written. I think SPAs are good technology when they are used in the right way for the right reasons. But there's a kind of dogma surrounding heavyweight JavaScript frameworks, and I think it pays to be a little skeptical as a result.
I smile, because ALL modern tech try to do what classic Smalltalk environment have done in the past, see a Pharo video demo to get an idea, a DocUI, with active elements. Well, no modern tool so far have reached the same level of power. Modern webapps might have some of that power, but fails dramatically in flexibility and user control...
His reasoning is alright, his solution is bad, not sure if for the lack of knowledge of MPAs (like Astro) which fix the problems he is talking about.
This may say 2016, but so many of these points still apply today. My biggest issue with these JavaScript-first sites (SPAs and React/Angular/Whatever) is that they break in weird and unpredictable ways. Some of my common complaints that I still see often:
- Pages never fully load because some JavaScript file timed out - Browser history disappearing - Middle-clicking or right-clicking links doesn't work - Start typing in a form field while the page hasn't fully loaded, and then the form field clears itself when the page does finally load - Modal screens only partly load or leave artefacts on-screen when dismissed (e.g. a random spinner icon on the page, or a part of the screen stays dimmed after modal is gone) - Copy/pasting into form fields doesn't trigger actions (e.g. buttons stay disabled while they wait for a key-press to activate) - Password manager autofill doesn't work because of some weird JavaScript validation script - And. So. Much. More.
- Pages never fully load because some JavaScript file timed out - Browser history disappearing - Middle-clicking or right-clicking links doesn't work - Start typing in a form field while the page hasn't fully loaded, and then the form field clears itself when the page does finally load - Modal screens only partly load or leave artefacts on-screen when dismissed (e.g. a random spinner icon on the page, or a part of the screen stays dimmed after modal is gone) - Copy/pasting into form fields doesn't trigger actions (e.g. buttons stay disabled while they wait for a key-press to activate) - Password manager autofill doesn't work because of some weird JavaScript validation script - And. So. Much. More.
RIP Stefan
The biggest contender for breaking browser history and middle-clicking are the fucking Microsoft Admin Portals, especially the Azure Portal.
Oh. My. God.
I lost all trust in Microsoft when I started using these. It's like the devs don't know the very basics of web browsing, or they all use Macs and want to impose their preference onto everybody else.
Oh. My. God.
I lost all trust in Microsoft when I started using these. It's like the devs don't know the very basics of web browsing, or they all use Macs and want to impose their preference onto everybody else.
The number of times I'm told to use porn mode (anon browser) to use those bloody things is annoying.
I often need to be multiple identities. My email clients, if webby, understand that and just work. My work sites just work too. I have quite a few customers, whom I act on behalf of, and I need that to work efficiently and be secure.
MS admin portals seem to be rather arrogant and sort sighted and insist on one identity per browser invocation and not per session (hence the porn mode workaround). I don't think that is a Mac thing at all - its probably rather lazy programming.
It seems they are incapable (or unwilling) to efficiently define how to authenticate and authorise a "session", without some serious constraints.
I often need to be multiple identities. My email clients, if webby, understand that and just work. My work sites just work too. I have quite a few customers, whom I act on behalf of, and I need that to work efficiently and be secure.
MS admin portals seem to be rather arrogant and sort sighted and insist on one identity per browser invocation and not per session (hence the porn mode workaround). I don't think that is a Mac thing at all - its probably rather lazy programming.
It seems they are incapable (or unwilling) to efficiently define how to authenticate and authorise a "session", without some serious constraints.
I feel like just using containers in the first place to separate your identities would solve multiple issues. Not sure if you have used a browser that has them, but I think on Firefox it works quite well and is easy to use.
Github has onboarded the SPA train I think, and browsing a repo is a nightmare especially with URL state. I don't know if it's becoming better or no, but there was a time when links on Readme.md were broken on the homepage of a repo.
I hate your spa bc 100% of the time it breaks
Tell us more about blocking ads on porn sites....
I now work on an Angular 17 enterprise application.
Out of all of them, the Angular 17 application is by far the most enjoyable to work with. And I was brought into the SPA world kicking and screaming and muttering "get off my lawn".
But these points are not necessarily valid. We don't break the back/forward buttons, or page refresh, the initial payload is sizable, but less than many "non-SPA" websites outo there. And it runs a large enterprise. When we release a new update, nobody notices. In the corporate world, downloading a few MB that is compressed over the wire and cached on the client after it's sent ... people don't notice. There are single images on websites bigger than our platform.
The first compliment we got after releasing the Angular project was how incredibly fast it was. It's not bloated, I feel that is just an old way of thinking about it. Sure it's not pure HTML with bit of vanilla JS sprinkled in, but it's not going to slow your machine to a crawl (if done properly). Yes, "view source" is going to be a sea of JavaScript that renders HTML. Pure? No. Slow? No.
It's not one URI, it's /users/edit/104 and /departments/accounting/invoices/42. It allows bookmarks via deep linking.
Would I use a SPA for my personal blog? No, I'd use a static site. In fact, I've had them since the early 1990s and I still do have static sites up right now. But would I use HTML and vanilla JS for a large enterprise system? No. As I mentioned, been through almost every web framework since ASP in 2002. JavaScript since 1997. I know the pros/cons at this point.
There are too many SPAs out there, there is no question about it. It's because had a lot of developers go to bootcamps (or teach themselves) which ended up with a lot of JavaScript developers who knew some React. So that has been the go-to for "a website".
But I don't feel these points are valid about SPAs. 30 years into it, I'm happy I greenfielded with Angular on this most recent project. Smooth sailing.