not sure why you're being downvoted. SPA's have their place but I agree with you that they are being heavily overused.
I've seen plenty of applications that could have easily been a collection of server driven pages broken into an api and spa. I think it comes down to a few things where SPAs are great.
1. Programmers padding their resume. react looks more marketable that any server side templating technology
2. fomo, what if later we want to add something that needs it
3. seperate api/frontend teams, spas make seperating responsibility easier. two seperate codebases.
of course it has its downsides
1. you're maintaining a communication bridege between two different applications. This entails a context switch if you're a developer hopping back and forth.
2. more failure modes to handle. Only so many things can go wrong loading a page. If an SPA breaks, it can render the entire page unusable. You also need to have error. handling code for inputs on both your frontend and backend.
3. large file sizes to download. This one has been beaten to death but it still holds true.
Ive personally found a nice middleground with phoenix liveview. Its slightly more work than a tradtional page driven app while giving me teh ability to create all the features I was being asked for that before would have warrented an SPA. I hear livewire and stimulus reflex are great too.
YMMV, but when I've dabbled with what I believe are good SPAs, I've noticed what I was essentially was essentially implementing a crude primitive web-browser inside my React app. I mean, I was neck-deep trying to code page transitions, load progress indicators, history states, all this sort of stuff.
Thankfully, I'm not a frontend developer. Was just toying around here and there. Maybe it was just that I sucked at simple things.
Still, for now I believe many (not all, of course) fancy SPAs are a probably a waste of otherwise productive time. There is already a browser, and it does things well. Having something that would allow for smaller documents is a good idea, of course, and some eye candy for transitions between different documents would be neat to have, but every site doing this for themselves feels just plain wrong to me.
Exceptions - e.g. for heavily API-centered systems - apply, of course. If a webpage is one of half a dozen client applications that consume the same API, then SPA could be a sane way to do it.
I'm not necessarily scared of SPAs (I actually work with React myself), but I do believe them to be overkill in lots of cases. One nice thing about them is you can enforce a hard boundary between frontend and backend. Although with some discipline you could do the same with a single backend framework.
> SPAs have allowed engineers to create some great web applications, but they come with a cost:
> Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks.
Yes, better quality software usually packages a bit more complexity.
SPAs are popular, just like native apps, because people don't like jarring reloads. Webviews in native apps are panned for a reason; turning your whole app into a series of webviews would be stupid, right?
> Tooling is an ever-shifting landscape in terms of building and packaging code.
I've used these 4 libraries to build apps since 2015:
* React
* MobX
* D3
* Webpack
The only one I have had pain with is react-router-dom, which has had 2 or 3 "fuck our last approach" refactors in this time. And I added TypeScript in 2018.
PEBCAK
> Managing state on both the client and server
It's a lie that a thin client isn't managing state; it's just doing a static, dumb job of it.
Imagine some cool feature like... collaborative editing.
How would you pull that off in HTMX?
> Frameworks, on top of libraries, on top of other libraries, on top of polyfills. React even recommend using a framework on top of their tech:
Yes, React is famously not a batteries-included library, while Angular is. But, as addressed, you need about 3 other libraries.
Besides, did you know: HTMX is also a framework. Did you know: HTMX also has a learning curve. Did you know: HTMX forces you to be able to manipulate and assemble HTMLstrings in a language that might not have any typing or tooling for that?
Anyways, I've said enough. I should've just said what I really think: someone who can't even get their nested HTML lists to actually indent the nesting shouldn't give advice on building UIs.
I didn't say there are no use cases for a SPA, what I'm arguing is that in the vast majority of cases it's not a good option.
What constitutes a SPA? Essentially it is a JS application that handles all route changes and in consequence also has to handle application logic, state, etc.
To be able to achieve that kind of functionality development becomes much more complex. Not only you now get all the architectural nuances of making an app, which your typical JS dev doesn't understand, but the dev workflow becomes convoluted for a number of reasons:
1. Not all browsers support the same language features and APIs which introduces the need of using transpilers like Babel or Traceur.
2. JavaScript is objectively a poor language for complex projects hence the success of alternatives like TypeScript.
3. The JavaScript standard library does not live up to the necessities of the modern front end developer which introduces the need of using and managing more dependencies. For example, after all these years there is still no native reactivity.
For these reasons we now have to use bundlers like Webpack, NPM dependencies, and a very long etcetera. Plus a continuously changing dev landscape (see React hooks for example).
It is still challenging to make an accessible SPA. Common functionalities likes control+click on a link have to be re-implemented.
Of course sending all this functionality to the client can have a serious cost in size and CPU. It's not as big in leaner frameworks/libs like Svelte but it's always there.
The initial bytes can be mitigated by using something like Webpack chunks, but again this introduces more dev complexity.
Finally, in the vast majority of cases (if not all) SPAs also render the content. This requires developing an API (GraphQL, REST, etc) which introduces another layer of complexity vs doing the rendering in the server. In some cases this is necessary as there can be various clients, but not always.
IMO all these drawbacks make sense when the SPA model is justified and there is a need for sophisticated functionalities. Gmail is the perfect example. Soundcloud is another good candidate since audio needs to keep playing at all times.
So usually the arguments in favor of an SPA are that the UX is better or that after a number of clicks the user receives less bytes compared to receiving markup.
I think that the UX benefits of a SPA are exaggerated for common use cases (e-commerce, CRUD admins, enterprise apps, marketing websites, etc). Amazon, Ebay, Wikipedia, are not SPAs and they are still getting millions of visits every day and probably growing.
As for getting the data in JSON or WebSockets vs getting HTML, yes, after a number of clicks there are some bytes savings but after having paid a high cost in initial bytes and CPU cycles. This argument could make sense in very particular use cases, but I don't think it can be applied as a general argument on all websites. It makes sense for gmail, since there is a lot of clicking around and changing views, but that's not a concern for the vast majority of websites.
I should probably write an article about this since I've left out some points and haven't gone with much depth into others... but I hope this comment conveys my position.
That's what the goal is, and that's what SPAs enable. You can't build a modern web app without it being a SPA. The two are basically synonymous, I don't understand how there is even a discussion around this. No user wants to navigate to another page and lose their context. That's why the industry moved to SPAs. If you ever tried to manage complex UI state in the jQuery/Backbone/Knockout/etc days you would see that a React SPA is a huge improvement. It actually enables devs to build complex apps without getting bogged down in bugs.
I mean, SPAs were overkill for half the shit they were being developed for. Your average web app is a CRUD app and works better as an SSR app. But there's still use cases for them, they're still a great way to build highly interactive cross platform apps.
While the author explains that the front and backend are coupled, I think they overstate the coupling of client/API but don’t account for the numerous and disparate factors that motivated the popularity of SPAs to begin with. It’s perhaps out of scope of a comment to go into those details, but anyone who’s built and had to evolve large business applications on the web in the early 2000s is familiar with the headaches of the traditional server side techniques [sweats in server-side includes, ASP.NET form state, unnecessary db calls loading whole pages when only part has changed, etc.]. Not even getting into other benefits (API reuse and the flexibility to support multiple clients and use cases simultaneously).
In my opinion, the two major problems are tooling (which I think is more of an issue with browsers and the deficiencies of JS) and people using SPAs as an all purpose solution (does your blog or marketing homepage really need to be a SPA, really?). The former has seen steady improvements, but at any rate I’ll eat the cost of because it’s worth it for some of the larger systems I have to build and maintain. The former, well I dunno what to tell you, the cargo cult has been a fixture in this industry for a long time. I don’t think wearing a “you’re a bad person if you develop SPAs” helps (not accusing OP of this, but remarking on a general attitude) but in fact furthers the problem by pressing devs into binary thinking rather than evaluating and making decisions on their own.
So I’m with you: I won’t be shamed for having written SPAs and I’ll continue to do so as needed
The current state of SPAs is just a symptom of an overall illness the web is suffering from. SPAs just happen to introduce some annoyances that lazy and inexperienced programmers don't avoid, often defeating the point of SPAs.
The average SPA is not only written to experience zero latency but are poorly written from an efficiency perspective. They are often doing tons of procedures under the hood in order to support generalized programming when in actuality they could get by with a lot less framework code (Svelte in part demonstrates this in a positive way). Programmers waste so much time figuring put frameworks that they shirk proper exception handling, handing off complex tasks to the server, or giving the user cues as to what to expect.
Most SPAs don't even need to be SPAs. If all the meaningful state belongs on a server then the app is better off being a traditional web site with progressive JavaScript enhancement. Not only does that free frontend code to be more UI centric but it also means JavaScript wouldn't be required. It amazes me how many blog sites don't work at all with JS turned off. That shouldn't be any more acceptable than it would have been to implement a blog entirely in Flash back in 2005.
There are lots of applications which don't really benefit from being an SPA (blogs, books, etc.). As soon as you start thinking about meaningful interactions you quickly start having to pile enough JavaScript into the HTML that you quickly run into a mess - defining ways to marshal data back and forth with an ad-hoc structure.
While SPA tooling like React are incomplete since they don't provide all of the client/server data communications that comes for free with a server side application. That is starting to become more "standard" as GraphQL and Apollo start filling the gap of boilerplate. Though of course wrapping your head around GraphQL takes a bit of work for anybody who's spent their life with REST.
Most applications should be SPAs to create the interactions that users expect.
I could almost agree, but for at least one aspect: 90% or more of today's SPA web apps are just glorified information pages, that do not need any React, Vue, Angular or Svelte. That is where the hype train shows. They could just as well be way simpler in design, and avoid having to reimplement (through a dependency or not) the back button. Many cases for actually multi page apps, that are needlessly implemented as SPA with additional router BS and tons of dependencies and a heavy framework, rather than simply going for server side rendered template and being done with it. This comes mostly pushed by frontend developers, who want their shiny framework of choice to be relevant everywhere. A job guarantee.
The fundamental problem is not that the SPA pattern is bad, is that it takes a lot of skill and effort to make a proper SPA. Obviously, skill and time are scarce resources and the result is that most SPAs are crap.
OTOH all these component based frameworks have definitely brought us a much better way to produce interactive experiences compared to the jQuery days. This is not related to SPAs at all. You can use React/Vue/etc in a multipage application. The problem is that to hydrate (make interactive) the server rendered HTML you now need to duplicate your markup between your server language and front end framework. The solution is to use the same framework in the backend and the front and write the components just once.
Anyone can throw out a better-because-of-experience answer, and in fact I’ll do so now: I also have 15 years of experience in front-end dev and I disagree with your premise. It completely depends on what you’re trying to build, and SPAs are too heavily used at the light-interactivity end of the scale. We’re failing our users with brittle solutions that make us feel cleverer as developers.
I exclusively write SPAs these days and I think they are vastly superior for many reasons. The problem is that you can build a shitty product with good tools.
One of my duties is performance improvement, so I’m very familiar with problematic architectures. You can have an instantly loading informational SPA... I tend to use Gatsby for that. For more interactive sites, I prefer vanilla React with lightweight libs, code splitting and sensible caching rules.
I do agree that poor design, reluctance to refactor and lib/tracking heavy apps are very problematic. Isn’t that something that’s always been a problem in Webdev?
There are no pain points with SPAs that can't be had in any other kind of web app architecture. Most of the problems we run into are ones we create for ourselves. Writing jQuery splatter got tiring, so we moved everything to the frontend. Then we got tired of our 300+ line Webpack configs, so now the old days of server rendered HTML is where the grass looks green. Inevitably, we will get tired of all the hacks we have to do to work around the shortcomings of HTMX/LiveView/Hotwire and move on to something else.
What tires me is the groupthink around web development. SPAs and server rendered content aren't better than one another. It's annoying and unreasonable that the current trend is that SPAs are bad. They are not. Everything bad with SPAs I've seen is caused by developers not getting their priorities straight and by bandwagoning. Stop making webpages complicated and you'll find that many problems disappear.
SPAs become necessary when the user experience requires bells and whistles, like cross-widget consistency of like/friend request counts (the original use case of React IIRC).
It's not "you ain't gonna need it," it's "you are gonna need it, users will judge you by your fluidity, sure it's overkill right now, but the overhead may be less than the pain of a frontend rewrite since you may need it soon."
I've often thought that if there was a way to gradually codegen a fluent React codebase from Django/Rails/Laravel server-focused frameworks, and move template-by-template into a rich frontend + API, a lot more people would start with those server-focused frameworks, because there wouldn't be a need for a full rewrite. It would be a holy grail for our industry and let us develop business apps way faster. Not an easy problem to solve. Email me if anyone reading this wants to chat though!
I have no idea. I do a lot of front end work in React, and the assumption that an SPA is a better experience for people because you don't have to do a page reload to see a new page is really baffling to me. It's widespread too - across industries and disciplines and age ranges, as if the people suggesting these things have never used SPAs.
The SPA movement has always seemed like a cargo cult to me. Yes, AJAX is handy and it was exciting when it came out. We used it to update search results when you changed a filter.
For 90-95% of applications, a single page app architecture with a front-end JavaScript framework running a bunch of application code and rendering output is overkill and you could write the same app in half the time using server side rendering.
I've seen plenty of applications that could have easily been a collection of server driven pages broken into an api and spa. I think it comes down to a few things where SPAs are great.
1. Programmers padding their resume. react looks more marketable that any server side templating technology
2. fomo, what if later we want to add something that needs it
3. seperate api/frontend teams, spas make seperating responsibility easier. two seperate codebases.
of course it has its downsides
1. you're maintaining a communication bridege between two different applications. This entails a context switch if you're a developer hopping back and forth.
2. more failure modes to handle. Only so many things can go wrong loading a page. If an SPA breaks, it can render the entire page unusable. You also need to have error. handling code for inputs on both your frontend and backend.
3. large file sizes to download. This one has been beaten to death but it still holds true.
Ive personally found a nice middleground with phoenix liveview. Its slightly more work than a tradtional page driven app while giving me teh ability to create all the features I was being asked for that before would have warrented an SPA. I hear livewire and stimulus reflex are great too.
reply