It's been so frustrating watch this play out over the past decade.
I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs.
Inevitably none of these projects end up taking advantage of the supposed benefits of SPAs: there are no snazzy animations between states, and the "interactivity" mainly consists of form submissions that don't trigger a full page - which could have been done for a fraction of the cost (in development time and performance) using a 2009-era jQuery plugin!
And most of them don't spend the time to implement HTML5 history properly, so they break the URLs - which means you can't bookmark or deep link into them and they break the back/forward buttons.
I started out thinking "surely there are benefits to this approach that I've not understood yet - there's no way the entire industry would swing in this direction if it didn't have good reasons to do so".
I've run out of patience now. Not only do we not seem to be learning from our mistakes, but we've now trained up an entire new generation of web developers who don't even know HOW to build interactive web products without going the SPA route!
My recommendation remains the same: default to not writing an SPA, unless your project has specific, well understood requirements (e.g. you're building Figma) that make the SPA route a better fit.
> And most of them don't spend the time to implement HTML5 history properly, so they break the URLs - which means you can't bookmark or deep link into them and they break the back/forward buttons.
The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up.
That aside,
SPAs are great for a number of reasons:
1. You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync.
2. You need a beefier backend. A SPA backed by REST APIs is super easy to scale. nginx can serve up static resources (the JS bundle of the site) LOLWTF fast, and stateless REST apis are easy peasy to scale up to whatever load you want. Now you just have to worry about backend DB, which you have to worry about with non SPAs anyway.
3. Less languages to deal with. If you are making a modern site you likely have JS on the front end, so with SPA you have JS + HTML. With another backend framework you now have JS+HTML+(Ruby|Python|PHP|C#|...), and that back end code now needs to generate HTML+JS. That is just all around more work.
I agree some sites shouldn't be a SPA, a site that is mostly text content consumption, please no. A blog doesn't need to be a SPA. Many forums, such as HN, don't need to be a SPA.
But if a site is behaving like an actual application, just delivered through a web browser, then SPAs make a ton of sense.
Your arguments seem to be assuming a particularly bad implementation of a traditional backend.
1. A good server-generated-HTML backend will have no more state than a good server-generated-JSON backend. The client state is all stored in the client either way, whether in JS variables, HTML tags, or the URL.
2. A good server-generated-HTML backend doesn't do significantly more work just because its output is in HTML instead of JSON. A bit of extra text generated isn't going to increase your CPU load in any meaningful way.
3. There are only fewer languages to deal with if you aren't in charge of writing backend code. If you're in charge of the backend code, you still have to pick a backend language for your JSON API.
I think you're assuming that the choice is "SPA" or "messy stateful monstrosity". It's perfectly possible to build a RESTful HTML-based API that is as clean and stateless as any JSON API. PHP's been starting each request with a clean slate for decades.
> 1. You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync.
If this were true, you wouldn't need a REST API. I don't understand what you're trying to say here. When you make a REST call to get data, you instantly have two different sets of state: the client and the server. It's no different from SSR, it's just transmitted in a different data format (json vs html).
> 2. You need a beefier backend. A SPA backed by REST APIs is super easy to scale. nginx can serve up static resources (the JS bundle of the site) LOLWTF fast, and stateless REST apis are easy peasy to scale up to whatever load you want. Now you just have to worry about backend DB, which you have to worry about with non SPAs anyway.
You do the exact same thing with SSR. Stateless shared nothing app tier instances. Been doing it for 15 years now.
> 3. Less languages to deal with. If you are making a modern site you likely have JS on the front end, so with SPA you have JS + HTML. With another backend framework you now have JS+HTML+(Ruby|Python|PHP|C#|...), and that back end code now needs to generate HTML+JS. That is just all around more work.
You can use JS on both the frontend and backend. Or ClojureScript. Or TypeScript. I'm sure there's others. But yes, for many languages this is a potential negative of SSR.
> You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync.
This is a bit weird to me, in that I'd say that cuts in the opposite direction. State can exist in at least three locations for most applications: db, app server, and client. Keeping state consistent across all of them can be difficult in the best of times, but thin clients by their very nature carry less state, lessening the burden. Sometimes client state is necessary, for richer user interactions, but for all but the most cosmetic of purposes you're going to have to replicate that state on the backend anyway, to enforce business and security requirements.
This is missing the real reason that people write SPAs, which is that React solved web components, which are hugely beneficial for almost 100% of web sites, and thus became the standard for building web sites, and with React it's easier to make an "SPA" than to make a "traditional" site and users don't know or care either way.
I agree with all your points, but I think it's worth pointing out that those benefits you mentioned are largely for the developers. As a consumer I love a well-written SPA when the problem set calls for it, but most of the SPAs I have to use are garbage. I don't fault the tech for that, although I suspect that a lot of those SPAs were created by "me too" people that just wanted to build a SPA. When React was in the pre 1.0 days, I did that, and several people on my team as well (so I'm not casting any stones here, just trying to state facts).
Last time I bootstrapped a React SPA I don't think cra includes a router ootb.
2. Hard to believe that is true in the general case.
Typical scenario for SPA is to use some sort of REST API, these API:s are usually designed for general usage, not specific usage, i.e. designed to be reused between components and views thus they basically return everything of a specific model regardless if data is needed or not.
Therefore the controller queries the database with the equivalent of SELECT * on a table (or perhaps multiple tables with joins) and then exposes every field.
And in many cases one request is not enough because the common generic design of REST APIs, thus a few request more are fired that results in multiple SELECT * against the database, and eventually the equivalent of SQL JOIN is performed in JavaScript.
Already SPA solution has an increased cost by asking for data that is currently not needed, not only in the traffic between the database and the backend but also in the traffic between the backend and the frontend.
And because we want to be good REST citizens we sprinkle the JSON payload with timestamps, resource urls and pagination information and what not and in majority of cases never to be used.
Comparing that to SSR where you can fetch what you need from the database with custom SQL query (I hope you do, otherwise the SQL leprechaun will make a visit).
Just imaging how much data there is on the web that is requested and then just discarded, not even looked at.
It is possible to design custom REST endpoints for each component, but then of course what is the point of a SPA then? If you are already writing a custom REST endpoint just return HTML instead of JSON and then swap in the new and swap out the old for your component (one-liner), the end result is the same.
> The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up.
They might not mess up history when using a standard routing library, but I've seen plenty of devs forget to add unique titles to different pages which is frustrating for a user with multiple tabs going.
On SO the accepted answer for react-router looks like "create a custom Page component with title as a prop"[0]. At work I just ask folks to use react-helmet.
> . You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync.
Why would I want to keep any state on the client? What in the history of the web (the whole idea being its someone elses computer) would make it a good idea to take away the one major selling point of the web? That no matter what, someone else has the state I need, and I never have to worry about losing that if something happens to my connection. It either went through or it didn't.
> The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up.
99% of SPAs break history related features in some way.
Client-side routing for page-oriented stuff is certainly not a solved problem: the basics, sure, but not actually doing it properly. There are some parts of the experience that it’s not possible to do perfectly because the web doesn’t expose the necessary primitives, and exceptionally few things go beyond the basics of just clobbering and resetting scroll position on back/forward. To do it properly, you need to restore all transient UI state (form field contents/state, scroll positions, focus, selection, media playback position; zoom level, probably not implementable; and there may be more, though I don’t include things like <details open> as transient state since that’s put into the DOM) on back/forwards, and I don’t know if I’ve seen anything actually do that. Then there’s the matter of helping accessibility tech to realise a page change has occurred, and I’m not sure of the state of the art on that, but last time I looked (some years ago) I think it was bogged down in unreliable heuristic land rather than actually being solved.
1) JS history handling is fragile. A single error can break navigation completely. There's no built-in loading indicator so sites are left with no feedback or have bloated progress bars. And nothing automatically solves for deep links if the app doesn't use routes for different views or relies on other events instead of hyperlinks.
2) Servers are very fast and assembling HTML is trivial. Browsers are optimized for downloading, parsing and rendering HTML as it streams in. Using JS to write HTML after making multiple network calls is objectively slower than a single network request that assembles everything on the server close to the datastore with minimal latency.
3) Every other language is faster and more capable on the server than JS, and all major web frameworks have modern component-based UI templating. Interactions with roundtrips are just fine, and some light JS can handle most other scenarios.
> "an actual application"
That's the only reason to use a SPA, not what you mentioned.
I don’t work on front-end and am trying to learn from this thread, so I may misunderstand, but that doesn’t look like an advantage to me. Doesn’t “beefier backend” imply “higher costs”?
We recently went a rewrite of our frontend for https://www.crunchybridge.com from SPA to more "basic" request response app and couldn't be happier. Previously was SPA with React and we rebuilt from scratch with request/response using Node. In places we still leverage react components for re-usable frontend bits, but no more SPA and state management.
As you've mentioned in some of your other threads on this, the state management and sync between the API team and the front end team just caused velocity to slow down. It took longer to ship even the most basic things. While we want a clean and polished experience, the SPA approach didn't really accomplish any of that for us.
The rewrite was under 8 weeks of an app that had been built up over a couple years and we quickly recouped all that time in our new found velocity.
My knowledge is limited on the front end. May I know which Node framework do you use? Is it NextJS? If not, what do you think about using NextJS because I really consider it a better approach and want to use it at new projects.
We built a product in ~5 months with real-time collaboration, extensive interactivity, Oauth, Stripe and Gmail integrations with a standard Ruby on Rails stack.
It's rock-solid, performant, dead-simple and extremely productive to work with.
Why're we throwing away years of learning to build unstable, complex and inaccessible applications?
Same experience here, in our case with Laravel. The project started as a Next.js SPA and after we needed to add authentication, translations and background jobs things became so crazy and so "custom" that we ditched it and in almost 2 weeks had everything built in a much more robust way with Laravel and Livewire + Alpine.
Because the majority of developers will gravitate towards tools that will give them the best employment opportunity, not necessarily the best tools for the job.
One could argue rails is just doing a decent job of hiding a monstrous amount of unnecessary complexity from you for basic CRUD stuff. It’s good at this… until it isn’t. In the the whole ORM abstraction (not just in rails) is questionable.
The way most of us would handle authorization in something like rails is a leaky abstraction, especially when we’re usually backing onto postgresql which has very mature roles and permissions.
I always thought of the benefits of SPAs more as a separation-of-concerns thing. You can pretty effectively build a functional front-end web application and mock a set of back-end REST apis, while another team builds out a the back-end. There are absolutely tradeoffs, and being a good software engineer is about understanding where and when those tradeoffs apply.
That's definitely true at the organizational level, and it's an argument with some merits.
In practice though, I've seen this backfire. You end up with the frontend team blocked because the API they need isn't available yet, and then the backend team gets blocked because they shipped the API but they can't use it to deliver value because the frontend team don't have the capacity to build the interface for it!
My preference is to work on mixed-skll teams that can ship a feature independently of any other team. I really like the way Basecamp describe this in their handbook: https://github.com/basecamp/handbook/blob/master/how-we-work... - "In self-sufficient, independent teams".
Why not eliminate that organizational bottleneck by using a full-stack framework that lets one person do it all? DHH recently described Rails as a one-person framework [1]. I think Phoenix fits that category as well.
When SPA started picking up steam, I thought it was an amazing development! We had gone from mainframes, to personal computers, and were back to mainframes and using our powerful machines as glorified dumb terminals. This way, we could have UI code running locally, and servers only handling state. Plus, less data to transfer!
Then the frameworks ballooned in size. What previously was seen as wasteful (rendering and sending HTML) started to seem pretty frugal in comparison to the multi megabyte pages. Not to mention that one could always send just page fragments.
Other than specialized apps, I think most single page applications are a mistake. Sure, some may benefit from a nice UI - say, I'm writing a 3D modeler. But most apps there are could just re-render pages. 'Refresh' is not much of a problem in an age where simple REST API calls are returning megabytes of JSON data...
I try to tell myself "don't get caught up in using a fancy frontend framework on this one," as I'm starting a new project, but I keep running into situations where my functionality would just work so much better.
As an example, I was writing a tool the other day to automate some things that have to do with quotes for my 9-to-5. Being able to add inline functionality in Django to select a customer within the quote page, or add / edit a new customer without having to leave that quote felt very 'hackish,' using the same jquery callback method used in Django Admin. My point is, this feels like very basic functionality, but turned into a whole other ordeal using traditional methods.
> Being able to add inline functionality in Django to select a customer within the quote page, or add / edit a new customer without having to leave that quote felt very 'hackish,' using the same jquery callback method used in Django Admin.
Agreed. For form based apps I don't like to fall back to SPAs (bloat, the desire of every dev to reinvent forms in their framework, client and server side validation duplication), and yet working with relational data they are easier.
It's one of those places where a half-way step would be so useful.
I initially thought part of the appeal was offloading the workload to the front end, where your processing power scales infinitely with each user's device. Maybe the benefit turned out to be negligible, I'm not really sure. Can server costs be reduced by offloading the work to the front end?
They absolutely can, if your workload is ideal for this situation, but unfortunately, the most "expensive" (in terms of time, money, computing power, you name it) part of giving a user information is typically the filtering and collation of that information from a much larger pool of information — almost always a pool of information that is far too big and too private to just send to the client to sort through locally.
Even in the most simple scenarios, you quickly find your limits. If you get data back, but it's paginated (and it almost always has to be, for basic reliability reasons as much as anything else), you can't be guaranteed to have the complete set of data in a given circumstance, so you can't perform operations like filtering, pivoting, or sorting that data locally. You have to ask the server to do this for you and wait for the response, just like we've had to in the past.
If you can actually offload substantial CPU cycles to the client, yes, you'll save server costs. But the SPA hype has led to a lot of SPAs that work like this:
> User clicks a tab. A request to server fetches the JSON data for the tab. Client renders it to HTML. User fills in some fields and clicks submit. A request to server sends the JSON form data and gets a JSON response code. Client shows a confirmation screen. ...
In this case, you're not saving much by templating JSON on the server instead of just templating HTML.
This was one of the appeals initially, and would certainly still be true if you were doing something very processor intensive that could securely be done on the client.
Languages/runtimes have gotten faster and more optimized, while hardware has continued to move forward. It's also far easier now to add more backend instances using orchestrators like k8s, so it's less of a big deal to have to add replicas.
> Can server costs be reduced by offloading the work to the front end?
I would say yes. One significant benefit of SPAs is that you can produce fairly complex applications without any server logic, only static hosting. The workload is essentially offloaded to the build process and the front-end. You still need to carefully consider the effect on e.g low powered and js-disabled devices ... but these are straightforward considerations.
>Not only do we not seem to be learning from our mistakes
That is a lot of good faith. What happens if they were not mistakes? But deliberate attempt to push Javascript as the one and only de facto approach to web development and Resume Driven Development?
I recently asked this [1],
I dont want to name names, but do any tech company actually apologise after their high evangelism to the world and industry and walk back 70% of their decision five years later?
And for some strange reason this mostly happens to Web Development in general.
I know people for whom the traditional way of building a web app is completely foreign. I am curious how you would describe the concept and tools to someone who has never encountered them before outside an SPA architecture.
>....taking advantage of the supposed benefits of SPAs: there are no snazzy animations between states....
If that's the main benefit, let's hear it for MPAs. I want a website that's fast, responsive, clicky, sharp and to the point - not some soft-focus pastel cartoon movie. As the author says, that's fine for audio/video sites (and reasonable for other entertainment-focussed sites) - for information sites it just gets in the way (animated elements - especially persistent ones - are a terrible idea when trying to concentrate on textual content).
For some reason, designers likes it no matter it makes sense or not, so it is what you get. The current designer trending is just a shit show, nuke the usability for nearly no benefits IMO.
It’s all about state management IMO. There are legitimate reasons to keep UI specific complex temporary state on the client that would be more complex (and slower) if the server needed to hold it. So an SPA or at least partial SPA in some situations does makes sense.
But it does tend to become a hammer for every screw over time…
> It's been so frustrating watch this play out over the past decade.
> I keep seeing projects that could have been written as a traditional multi-page application pick a SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs.*
Its been frustrating seeing the webplatform not play out, seeing so little growing in to SPAs, so little maturing.
Url-based routing is heavily under-represented, tackes on only by the one or two blokes who happened to have some memory of web architecture. This clairifies the architecture both internally & externally.
As bad a problem, single page apps being stuck, forever, at single-bundle apps is phenomenally sad. Splitting bundles into chunks as a manual development task is so hard, so bad. The goal of having web based modules almost made sense, almost happened, but we rafically underinvested in transport technology, cache-digest going undelivered. I continue to think js modules, with import maps- the key tech to making modules modular- is worth it, would help make our architecture so much better. There is mild extra time to first load, but worth it/small, & cached after.
Again we're damned though.
Years too late to try & see how excellent it would be to have something like react cached & AOT compiled as from a cdn. Because now privacy concern freak-outs mean this huge advantage of only needing to pull & potentially compile a js module once are gone: site-partitioning rules. We could have had better architecture, been using the language not absurd bundlers, and enjoyed high cache bit rates for common libraries. SPAs just didnt care, never tried at all, we all (almost all) did a horrible job & took way way too long (over a decade) to make modules modular g usable. There was so much hope g promise & such abaurd non-delivery, on the module front, on app archtiecture.
HTTP3 and early-hints still have some promising hopes for accelerating our transports, making "just modules" a possibility & fast, without careful hand optimization. We could still do more to optimize bundles, have automated tools that analyze up front versus on-demand dependency bundles, build http bundles of these. But i hope eventually itcs mostly not super necessary to build webpackage (nor far worse, webpack) bundles.
SPAs still have great potential. More so, now that we finally have some support tech for modules forming.
I mean, of course the co-creator of Django would say this.
I wouldn't recommend newer generation of developers to build traditional web apps, let alone use jQuery.
I don't understand why people think we're still in the age of form submissions and blog posts - There has to be a good majority of us here that has worked on something complex that required SPAs here, no?
Not only would it be detrimental to a young developer's career to suggest avoiding SPAs in regards to hiring, but only limiting that developer to create blog post styled content is severely restraining.
Let them develop their blogs in SPAs, at least when they are needed to go into something a bit more complex, they at least have the foundational knowledge required to move towards that.
What you're suggesting is to learn two things, (one that is inevitably being phased out), and spend the mental effort to discern when to use either one, when the more beneficial alternative is to learn SPAs and just go with it.
No 18-25 year old is trying to make a Weblog where walls of text is the main content - Youtube shorts, instagram reels, tiktoks and all these bite sized content has done a great job at destroying that level of attention span.
They're going to be building something else, something quick and visual, something pleasing to the eyes - and more often than not, it's going to require a SPA.
> There has to be a good majority of us here that has worked on something complex that required SPAs here, no?
You can still create a something complex without using any of the common SPA techniques, instead you can use things like Hotwire, Livewire, htmx instead.
If you consider that native desktop and mobile applications are siloed applications that coordinate with an API to achieve tasks - this is basically how SPAs or serverless MPAs work.
Part of the reason this is effective is because of the low cost nature of deploying applications like this.
For example; I can write a calorie counter that stores records in the client via indexeddb.
Given all the work is processed on the client, using an http server would be an unnecessary maintenance burden as it would simply server static files.
Rather than host the web application via a self managed http-server, I can just put my html files on S3 making hosting it free and unmanaged.
Should I decide I need to add user accounts and cloud storage - well I can then create a backend that exposes API endpoints to facilitate the tasks.
Those endpoints are then compatible with native applications, should I decide to write native mobile and desktop variations of my web application.
Furthermore, with Web Assembly expanding to offer the ability to write web applications using languages like C++, Rust, C#, Golang and the browser expanding access to OS subsystems like filesystem access - what we are seeing is that the browser is becoming a sandboxed UI toolkit, much like GTK or QT (except without native styling).
If there was anything that would empower Linux Desktops to be compatible with productivity software - it's progressive web applications.
Consider that Photoshop and Office are accessible on Linux via web today.
That's a lot of interfaces to create and maintain. The principle value of backend/MPA frameworks like Rails & Django is that they give you nearly all these interfaces for free in a neat package, which ends up being "good enough" for many use cases below Google-scale.
A calorie counter using IndexDB is a great example of something where an SPA is appropriate - like I said, "default to not writing an SPA, unless your project has specific, well understood requirements (e.g. you're building Figma) that make the SPA route a better fit".
I mainly work in the world of database-backed websites and applications, where going client-only without a backend isn't an option.
You're describing an actual client side (mobile or desktop) application made with web technology, not a web application. That's a fair use of SPA tech.
As soon as you need authentication, showing data across users, allowing visitors to see shared data, perform validation of inputs, send notifications when other user action happens, etc you're back in SPA hell.
i think what it comes down to is if you have to make a decision of "should i build an SPA?" the answer is no. the web is good at doing pages. if your app has pages, use the web's default page mechanism.
and i don't say this as a hater of single-page apps. i love webapps, and i think that building a webapp should be the default for most cases. there's a lot of apps that don't naturally break into a "page" metaphor, and all the technologies that are part of the single-page app concept are great for those cases.
figma is a perfect example, because there's no obvious division between what would be one page versus another. it's not a paginated website that has been built as an SPA, it's literally just one page that has a whole bunch of interactivity.
Don't don't do what I would do. The mistake is forgetting first principles. You don't do something good by focusing on what not to do (like don't be evil). Focus on what to do: KISS, YAGNI, etc.. even DRY is a far lower priority. Software, especially frontend and web are rampant with problems from operating as an echo chamber. Just consider what Ryan did with Deno and had to say criticizing his first project. Yet folks are still wildly supportive of the older technical decisions and go to great lengths to preserve those same mistakes.
Idk I don't think the problem is the SPA itself, it's bad design patterns that that make it terrible as you say.
I think really clean, performant SPAs can definitely be written and I think the overall experience of using a SPA can be much better than a multi-page site if the task at hand requires it.
There should be two parts of the web now really:
* Traditional multi-page websites
* SPAs that could have been a native app on the device, but are much more accessible in web form and without requiring an install
Speaking for myself, I find it much quicker and easier to build an SPA than a server rendered app. You seem to take the stance that server rendered is the default, normal way to architect and SPA requires justification for its aberrant departure from the norm.
SPA have lots of advantages: fewer languages to learn, easier to deploy, etc.
> SPA have lots of advantages: fewer languages to learn, easier to deploy, etc.
The two examples you give are only true if you don't have a backend at all. As soon as you have a backend, you're back to having to pick a backend language and deploy a backend server.
If your app doesn't need a backend, then I'd agree that an SPA is the way to go.
That just sounds like poor performing developers to me. You don't need snazzy animations between states. Just not reloading the full page is a benefit.
I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side Stimulus controllers, maybe a Turbo frame here and there and it works, but then you get to browser navigation and you're screwed, because none of this works if somebody were to submit the form, then navigate back. Now you have to implement lifecycle handling to account for navigation and once you're done, you've basically implemented a SPA, except it's broken into a mix of tightly-coupled Javascript, Ruby and ERB templates.
The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy.
To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts presentation and logic. The only state is its own. It does not handle an entire web app as a SPA, no Redux, prop drilling, it's just the idea of a reusable component as an HTML tag. Same with VueJS and all. If we restrict ourselves to that we're in the good path.
If there was already an HTML tag for your own specific problem, wouldn't you just use it in your traditional server-rendered app? A `<photo-upload url="/photos">` tag that does exactly what you want. Or a `<wizard pages=5 logic="com.domain">` tag. We should create just those components, either in React/VueJS/Whatever or in vanilla JS Web Components, and live with the rest as we used to.
We're basically saying that some parts of our apps are too difficult to mix and match state management, and we should offload all of the state to one of the two sides. In some rare apps indeed all of the state should be on the front end, but the use cases for that are just not as big as they're made out to be.
Exactly, the best approach seems to be where the app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA.
This approach eliminates the need for a client-side router, keeps any centralized page state small, and improves the SEO and bookmarkability of the app.
I have implemented this architecture in several projects, and it’s effective
Yes this is exactly right. What I’ve done in the past is use Django to return HTML with JSX mixed in, and have a super lightweight SPA frontend that just hydrates the react components on each load. You can also use form state to communicate back and forth with the server, where sending a response doesn’t refresh the entire page, just a react render diff.
With this you get the best of both worlds where your backend can do the heavy lifting where everything it needs to decide on the view is all in one place, and your frontend just comprises of really really generic JS components.
I have a library I’ve been playing around with for 2 years now, I should package it up
Agree, we just add React components here and there to server-side rendered HTML and it works great for us. The issue is most companies want separate teams for front-end and back-end and each team wants clear separation of boundaries and responsibilities between them.
>The problem is the mixing and matching of state management
Routing (history management) is also a big problem (I'm assuming you weren't including that in your definition of "state" here).
Some would say, "but React, etc. have solved the routing issues", and that's perhaps the case. But what's difficult is wiring these routers up outside of a full React app. That is, if you truly want routing "solved", you generally have to go all React (or whatever) or just let the browser handle it in the traditional request/response sense. Sprinkling in just a bit of dynamic interaction wherein you want the history managed is purgatory.
And, on mobile, things get even more interesting. Consider the simple case of popping a modal (especially a slide-out). Many users will hit "back" on a mobile device, which they would reasonably expect to simply close the modal. But, if your app/page doesn't intercede to manage the history, the previous page is loaded instead.
> The problem is the mixing and matching of state management.
This. But IMHO the right solution is to make the back-end stateless and manage all client state on the client. Each request authenticates itself, and (if you're ReSTful about it) the back-end is simply a database connector/augmenter.
In this paradigm, the SPA is basically a desktop app that retrieves data from a server, built to run within a framework, which happens to be a web browser.
In case you're jumping to conclusions, know that I'm a late-comer to the SPA party, having resisted from its inception until about a year ago, for all the obvious reasons, including those bemoaned by the OP.
Why did I relent? SPA frameworks like React now handle pretty much all the heavy lifting for you. OP, you should check out React Router, which can render this post's examples irrelevant. I'm surprised that in 2022, someone writing to the web UI layer would bother to create code to manage the address bar when there are a thousand ways to not have to.
Exactly. I've been in the position various times where I'm embedding a JS app on a page to help the user do something highly interactive, usually creating/editing content. And then as it's expanding to integrate with other things on the site, I start to wish more of the site was in the JS-app side of things.
Sometimes I realize a SPA would have simply served the user better, and it doesn't necessarily take much to be in that predicament.
Too many people hate on SPAs by, presumably, just imagining static read-only content like blogs and news. Though I'm also a bit tired of "SPAs suck amirite, HN?"
Put the user first, consider the trade-offs that work towards that goal, and see what shakes out.
The other thing people who hate SPAs need to think about is that rendering blogs/news/static sites isn't a problem that developers really work on anymore. Businesses will just pick from the huge pile of existing CMSs or hosted solutions because it's easier and cheaper. So if you're wondering why all these developers are building SPAs, it's because we're building custom applications, not blogs.
I think the fundamental issue with SPAs is that it's building on multiple levels of technology that fundamentally weren't designed to support being a single page application.
The browser <-> multiple pages paradigm is pretty much how the web evolved, so SPA's just end up being one giant hack to get everything working.
UWP/WPF/any other desktop app framework demonstrates how easy developing a 'single page application' can be without all the cruft you have to add to make a SPA work because it's actually a sort-of-massive-workaround.
Setting limits for future features to keep the code base clean and manageable is something developers could be more vocal about.
Acquiescing to every demand product designers and management throw into the mix is what turns beautiful, easily-maintained codebases into nightmares.
What people are talking about here is writing web apps as a series of small, tightly-coupled spas who manage state within very specific parameters. And that's a great way to build software. Until someone comes in and asks you to draw in the state from one section into two other sections. You have the choice to say a) no and explain why, to b) create a clever "glue" that will be hard to maintain and difficult to explain, or to c) take the time to refactor the code into something more general and complex to allow for the feature on a more abstract level.
Guess which one almost always gets chosen.
The upshot is this: The solution to front-end complexity may not be a technical one, it may not require a new framework or library. It may be a shift in what we expect out of the web. We could always temper our expectations in order to keep our code clean.
> Put the user first, consider the trade-offs that work towards that goal, and see what shakes out.
In my experience, every single team I've been part of that was building an SPA was because they put the developer experience and desires first, even if in the mid/long term the dev experience ends up being worse as the project grows.
I feel like most people that hate SPAs never have to deal with this type of thing, or even only have to work on the backend. They just don't get it. Of course, if you're using a SPA for a static website, you're also doing it wrong but that doesn't mean SPA itself is a bad thing.
I'm living proof that it is possible to simultaneously hate SPAs and understand why they are popular. I've built and worked on a number of them, I don't have a better alternative to recommend, and yet I still hate them because I think they are a clunky solution to the problem. We need something better, but I'm not smart enough to come up with what that should be.
I agree. These people hating on SPAs are mostly not frontend developers. They're backend devs that think returning an HTML page is all you need to do. Modern websites are very complex.
This is what jQuery solved. It made it ridiculously easy (compared to not using jQuery at that time) to add a little sprinkle of progressively enhanced JavaScript to a page. It still works today (and you don't even need jQuery now, as browser standards have mostly caught up), but everyone seems to have forgotten how to do it!
This is my biggest gripe with the direction of Rails.
I completely understand the historic reasons for wanting to keep JS to a minimum and stay within ERB/Ruby, but the JS component-driven UI pattern feels like the correct front end architecture for most commercial projects these days, especially now with better JS tools like Svelte, which feels like rails for the front end to me.
I started playing around with InertiaJS recently and I absolutely fell in love with it. I was surprised to see how niche it still is because it's pretty much what I've dreamed what writing JS with Rails could be for the last 5 years.
Progressive enhancement was largely solved before SPAs became a thing. Its quite easy to enhance the client side incrementally, but SPAs started out as useful for full on Web apps and now everybody uses them by default for some reason.
It's an implementation of Elm (imagine React if you're a JS dev), but all logic is executed on the server. State is passed back to the server whenever you choose to listen to an event. The view is then re-rendered and virtual dom diffed on the client. Non-interactive pages are just views. If you want them to be interactive, you add a Message an update function.
I used it on a client project and it was pretty delightful.
It probably isn't documented well enough yet to make total sense, but I think it's a step in the right direction.
> Then you add a couple of client-side Stimulus controllers, maybe a Turbo frame here and there and it works fine, but then you get to browser navigation and you're screwed, because none of this works out of the box if somebody were to submit the form, then navigate back. Now you have to implement lifecycle handling to account for navigation and once you're done, you've basically implemented a SPA, except it's broken into a mix of tightly-coupled Javascript, Ruby and ERB templates.
Where in this process did you need to start adding navigation via JS? Did that functionality really require JS, or was it implemented that way just because other parts are JS, and the trend was continued? Could you have used Stimulus controllers to manage functionality on the page itself, but when it came time to navigate to a new page, just done a basic browser redirect?
Saying that SPAs is a mistake doesn't mean that a strong dependence on JS or frameworks in a mistake. It just means that trying to make an entire site fit into a single page load introduces more costs than savings. You can still have pages controlled via React or Vue or Stimulus, but forgoing the router functionality.
In my own apps, I use Vue and VueX to control page behaviors, but each URL is its own Rails page. For example, I have a search page that uses Vue and VueX to asynchronously load, filter, and display search results. Clicking on a result is a basic browser redirect, taking you to the result's page, doing a full Rails page load, and again using Vue and VueX to manage any dynamic state (any static content is rendered via ERB files).
This has created a very clear and simple structure that allows each page to have any dynamic functionality it needs, but no complications from having to maintain navigation or browser history via JS. The browser already does that natively, and I get to spend my time working only on actual features--not recreating the browser's built-in functionality, or debugging my own take on it.
> Where in this process did you need to start adding navigation via JS? Did that functionality really require JS, or was it implemented that way just because other parts are JS, and the trend was continued? Could you have used Stimulus controllers to manage functionality on the page itself, but when it came time to navigate to a new page, just done a basic browser redirect?
In my specific example, the navigation itself didn't happen through JS, but you need to hook into navigation APIs to handle backing into a partially-filled form after submitting to rebuild the UI to reflect the state before the user hit submit. To make things even more fun, Turbo/Stimulus (sometimes?) breaks bfcache in Safari & Firefox so they behave different from Chrome.
Personally, I detest the vast majority of SPAs, especially the ones from Google, Facebook and Linkedin. Not even sure what they do to make them so horribly slow to use.
I think the best solution for this is just doing fullstack dev with SSR + partial hydration.
The issue is that, so far, we haven't figured out how to have a good fullstack DX.
Remix is probably one of the best attempts so far, but it still leans heavily towards being a very sophisticated renderer for the front end. The proof is you probably would not use Remix to create a 100% backend project with no front end. Same with SvelteKit or Next.
Until fullstack frameworks get more serious about the backend, we will be in this weird limbo.
In my current project I use Fastify as my main backend framework, and then use Svelte for SSR + hydration. I loose a lot of the frontend sophistication that SvelteKit brings to the table, but OTOH I have an amazing backend framework and total control and flexibility.
At the risk of a pile on, this is what jQuery was brilliant for. And frankly the native browser APIs have caught up enough that scenarios like what you want to achieve are simple to implement with just a script tag and a sprinkling of JS. I don't know what "Stimulus controllers" or "Turbo frames" are but they don't sound necessary.
Yes. Nobody should have to make a SPA to accomplish what JQuery did with sprinklings of JavaScript. JQuery was maligned because many people used it to make all XHR requests all over the place resulting in non-deterministic async behavior. JQuery was made to make adding small bits of JS easy and work in almost all browsers.
Bringing in React and turning that non-deterministic events firing all over the place greatly improved that situation, but this has become if someone needs JS, bring in SPA framework. This is in spite of the browser world getting much better. So just as JQuery was used to make SPAs to bad effect, SPA frameworks have been used to do minimal JS actions in a bad way.
It does and it has lots of work-alikes on other platforms (though some are not nearly as good). For almost any app that is inherently useless when not connected to the server, its a pretty good fit.
Inertia [1] is an interesting project in this space that might solve some of your problems. I haven't used it, but I believe the general goal is to make it easy to "plug in" client-side frameworks (React, Vue, Svelte) into server-side views.
Yeah can someone fix this please. I'm experiencing the same thing with a rails app I'm currently building.
In all seriousness it feels like there must be an elegant way to do more responsive modern functions while keeping the core server rendering concept. It's 2022 after all. But no I don't know a good solution either.
The Basecamp guys created Hey which is a mail app not implemented as a SPA. It's probably the fastest mail app I've ever seen while delivering around 40kb of javascript.
If Hey is a toy app you then you must be working on some truly alien projects from the future or something.
SPAs dominate? Off the top of my head I can't think of a single SPA that I actually use regularly. I worked in a niche a few years back where they seemed common (configuration interfaces for embedded systems) but looking at my own habits and the sites that dominate in terms of web traffic, that's thankfully not something that has caught on generally.
I can sort of see the point if the "A" part of "SPA" actually applies to your product, but for the dominant players that doesn't seem to be the case.
It was probably never too beautiful of a technique, but JSF does solve this problem splendidly. You basically have a view-flow besides the usual ones and it can act in many of the ways SPAs can.
Progress bars and previews are simply a matter of attaching an events to the http request and file input respectively.
When someone submits a form and navigates back, don't you just re-display the empty form?
If it needs to be a form bounded with the uploaded file (maybe as part of a wizard), then why not ask the server for it instead of storing client side state?
Maybe using Javascript without a SPA looks hard because you're trying to avoid storing state on the server as well as bypass native browser features.
I feel like react-rails (https://github.com/reactjs/react-rails) is basically perfect for this. You just make the photo upload its own react component and render it as normal from your rails view. You basically encapsulate the small bit of complex state into a component and it doesn't infect the rest of your app with SPA.
"I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. " I've started using django-unicorn lately and I'm hopeful that it may solve that problem for many use-cases.
SPAs are a pattern that's been applied too broadly IMO, but it's going a bit far to call them a mistake. The aims of an SPA are pretty noble - the idea of essentially removing the network round trip when a user clicks on something is not a bad one. It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features.
They might not be actual requirements for a blog or a brochure site but it's not totally unreasonable for someone to want their website to work that way. The question is not whether or not an SPA is a good or a bad thing, but whether or not the cost (more code, more complexity, potentially a series of background requests after the initial page load) is worth paying in order to get the benefits.
When either an SPA or a multi-page site is done well most users can't tell which sort of site they're looking at. That should be the goal. Make stuff where the user forgets about the tech. Make a website that just works, that's fast enough for users not to think 'this is a bit slow', and that's coded in a way you can maintain and work on for a long time. If you get those things right then no one can reasonably criticise what you've made no matter how you've made it.
> the idea of essentially removing the network round trip when a user clicks on something is not a bad one.
Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete. With SSR, you can take care of everything with a single GET and a single POST no matter what. Images load in parallel of course, but those are non-critical.
The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly.
Who CARES if the SPA had to make 3xRTT in the background, if it can serve the next page up instantly because that data is already present and cached, it's a huge win.
The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not.
Still doesn't make an SPA the right fit for everything, but on bad networks, we get incredibly improvements in performance by rendering from cache, and occasionally handling cache updates in the background. User's fucking love it compared to waiting 2-5 seconds for every page load, even if they were JUST on the page a second ago.
> Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete.
This is largely solved with innovations like GraphQL (which you don't need a SPA to use). Pages that require multiple API calls can show their UIs progressively with appropriate loading indicators. For SPAs that have ~long sessions, it's arguably a good thing to have multiple API calls, because each can be cached individually: the fastest API call is the one you've already cached the response for. This is stuff we were doing at Mozilla in 2012, it's nothing new.
There's also nothing stopping you from making purpose-built endpoints that return all the information you need, too. Your proposed solution (SSR) is literally just that, but it returns HTML instead of structured data.
SSR isn't a one-size-fits-all solution. Blogs? Sure. Corporate marketing site? Absolutely. Wikipedia? What else.
A webapp where state can exist in various components is a perfect fit for SPA-s. Clicking a button in a widget and submitting the page with every other state, updating them and refreshing the page makes no sense.
SPA-s also help with separating frontend and backend development, they are different beasts. I know many backend devs who wouldn't touch frontend with a 10m pole and not because of JavaScript, but because they don't like design and UX in general.
People generally have a very bad estimate of just how engaged users are with their sites.
These people have lives and other shit to do besides spend all day in my web app. There’s a lot more accidental and exploratory clicks than you think and all of the background requests run even though the user is only on that page for half a second.
If you can do it in a single GET/POST in an SSR, you can do it in a single XHR call in an SPA. There's no reason it has to be split up in separate XHR calls.
> When either an SPA or a multi-page site is done well most users can't tell which sort of site they're looking at.
And therein lies the problem. In the _vast_ majority of SPA sites I've been to, they are not "well done" by this definition. It is commonplace for things to break, like the back button as the quintessential example, because the developer(s) didn't spend the time to make sure things work correctly. With a non-SPA site, you generally have to go out of your way _to_ break those same things.
I like SPAs for some things (gmail being a good example), but they should not be the default implementation; there should be a _very_ strong argument before the SPA architecture is used.
>It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features.
Yet the reality seems to be the opposite. If my connection is flaky (which it often is) then SPA's seem to fail more often and it isn't obvious what is going wrong. They don't seem to be faster either, long pauses between pages is common.
Right. The typical SPA doesn't recover at all from network failures, and you end up poking random buttons hoping that it will reach some sort of consistent state. Then you find that doesn't help and you need to refresh anyway, which is a reboot for the whole 'app'. So much for saving page loads.
I think it's exciting to see frameworks like https://remix.run/ trying to temper the disadvantages of SPAs by relying on web standards and server-side rendering. It's pretty cool that this is a JavaScript framework that can work without any (client-side) JavaScript.
Honest question: why is remix the primary example for this now? Next.js has been doing this for years and is really amazing. It seems like a ton of people had no idea this was even a problem they had until remix came along, and now remix is the savior.
Am I missing something with remix? Is there anything really novel that it does/introduces?
Not saying it can't be done, but I haven't seen many SPAs that handles well flaky connections. Most stall with no indication to the end user, endless spinners or just broken in some random way.
This article seems to be directed at dealing with people that use SPAs to make more content focused websites, which quite obviously are better made with the browser.
However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all.
Even the example is a bit silly - SPAs that should be SPAs don't really have "links" per say, they will mostly have buttons, which will have a some sort of defined action. Perhaps these buttons will navigate to some other screen in the application, however, reloading all of the client side state every time one does this is absurd to say the least.
Finally, from a technical perspective, having a clear separation of concerns by having code talk to an API as opposed to HTML being rendered on the server, you remove a lot of complexity.
It feels like the people who write these articles don't actually remember how utterly shit the jQuery days were.
It does feel like the tiring contrarianism type of heading as opposed to a particularly well thought out article.
In the same way I feel lesser able coders seem to dwell on shit-slinging against tech that is proven, works, and has solved innumerable problems when they bang on about how things were so much nicer with vanilla JS and how frameworks are lazy and slow or something, in order to cultivate a sense of superiority.
Any well made tech has it's place, skill and experience are about knowing which tech should be used where.
>> He was just unable to follow and understand the trend, and thinks that therefore the whole industry made a MISTAKE :D
That's not true, though. If you read [his next blog post](https://gomakethings.com/how-to-make-mpas-that-are-as-fast-a...) you'll see he has lots of experience with architecting an advanced multi-page application which works and behaves much like an SPA.
It makes his anti-SPA post kind of redundant and a bit hypocritical, but he clearly knows roughly what he's doing.
Yeah - I think a lot of it might be developers who don't understand that SPA and caching go pretty much hand in hand.
I'll admit that can make your life as a developer harder sometimes (to be blunt - caching is hard - full stop) but an SPA rendering from cache is basically a rocket compared to a server rendered page on a bad connection.
Absolutely no one enjoys waiting 2-5 seconds after clicking the back button to see a page they were just on, but that's the reality of a server rendered app on a bad connection. An SPA with good caching does, in fact, feel like a native app - in lots of good ways.
>no one enjoys waiting 2-5 seconds after clicking the back button to see a page they were just on, but that's the reality of a server rendered app on a bad connection
Wait, what. Don't basically all browsers nowadays keep previous pages in memory exactly not to do this?
> However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all.
in the same way how re-rendering the screen in a 3D game for every frame does it. Or how you buy a new pair of jeans instead of meticulously learning how to patch the old ones. It solves a lot of problems even if it sounds suboptimal. It was the standard practice when computers and networks were much much much slower, therefore it cannot be that bad.
I think SPA and their entire ecosystem give some sense of optimality to purists which is probably shortsighted and wrong.
Nah, they weren't a mistake, at least not in isolation. Much of modern software development is a mistake, generally speaking. When you look at it that way, SPAs only failed in the sense that Object-oriented Programming failed, as well as the failure of various design patterns, microservices, write-once-run-anywhere, test-driven development, decentralization... I can go on and on with the number of engineering and computer-sciencey crap that never really lived up to its promises.
SPAs only suck as much as we suck. Just admit that SPAs are like any other tool, and if we're going to swing back to apologizing for goto-statements (something I don't necessarily disagree with) then we can't at the same time act like SPAs are a mistake in and of themselves. We collectively continue making mistakes and instead of owning up to our collective lack of craftsmanship, we are blaming the tool.
Only when we shed the mindset that informs us that computer "science" is actual science might we then be in enough touch with reality that we seriously impose some standards upon ourselves to address our clumsiness.
We suck pretty bad. SPAs are often the default because that is what the framework dictates and nobody trusts a JavaScript developer to delivery any kind of quality product without some epic massive framework, including ourselves. This is the standard for hiring, performance, and delivery and nobody dares deviate. If its not an NPM package written by an anonymous stranger or an API on the framework its not an option. We don't trust each other and management doesn't trust us, so let the framework dictate our every decision.
Doesn't every other science field work pretty much the same way though? We make mistakes, we iterate, we make new and better mistakes. It may be too obvious in software cause it's easy to create stuff and iterate very fast cause there aren't so many natural constraints. Someone may even argue that this is what makes software also an art.
TDD, or rather the effort behind TDD, failed because its proponents couldn't help but preach it as a cornucopia of solutions with the insistence that it's appropriate for every circumstance. When you are familiar with the domain of a problem, TDD makes a lot of sense. For the project I'm working on now where I'm effectively learning at just about every step of the way, and said project is intended for very few users, it's highly questionable if I could have benefited from TDD. Even when I'm not doing something unusual, TDD doesn't always make sense.
Any research that currently exists around TDD is of poor quality and proves little, but TDD fanatics (not sure how many of them exist anymore though) speak like there's objective evidence in their favor. And some call this sort of thing "science"?
By the way, when I mentioned science, I was specifically referring to the concept of "computer science", of which there has been very little actual use of the scientific method in our lifetimes. Computer science is of course a legitimate area of study; if our heads are still so in the clouds that we are still calling it a "science" then it's no surprise that we're continually losing touch with the very technologies we create.
TDD also shot itself in the foot with this (IMO toxic) insistence that the tests are the documentation, which is a nice principle to keep in mind, but I've never seen it come close to replacing actual documentation. A simple comment block describing the why of a function is always better than scrolling through tests and reconciling inconsistencies with the mocks that were used. And yeah, I know that TDDing isn't really about "mocking", but let's face it [...].
Perhaps the worst thing of all is that TDD is founded on a somewhat dishonest implicit premise, which is that if you aren't TDD'ing then one must be either not writing enough tests or are writing inferior code because one is writing tests after development. TDD fanatics, in particular those freshly inducted into the cult, often think it's either TDD or nothing, and if you're not TDD'ing one particular part of an app then you're not following "standards". Maybe TDD is fine as a form of guard rails when you're a junior developer, but by the time you're a high mid-level and in touch with reality then you're going to intuit whether a unit of work will actually benefit from TDD.
TDD isn't bad at all in terms of its mechanics. It's a great idea, and I've used it many times. In fact I even TDD'd an entire web app that handled payment processing from start to finish. The part about TDD that "failed" was this belief that it is actually a generalized solution that needs to be applied everywhere, which lead to it both being misapplied as well as dismissed when it becomes apparent that those promises of better and easier code/process/readability often don't magically manifest.
This is really the story behind just about every failed idea related to our field, not just TDD. SPAs were supposed to make pages snappier because it meant server responses to different user actions would require fewer bytes and no page refreshes. Instead of viewing SPAs as a tool with a purpose, people had to treat SPAs as the end-all-be-all of frontend development and a way to do everything, and now the world is stuck with many SPAs that are likely worse than if they were done as regular webpages.
REST API's (literally, "Representational State Transfer", ReST) are a very nice match with SPA's, because now the browser is the sole source of truth for application state (and the server only has to produce some JSON data instead of entire HTML pages).
Literally the entire point of REST is that you don't have to maintain server-side sessions, and you shouldn't. This also has benefits for scalable applications, in that you can transfer your running application to a cluster of servers on the other side of the world, and it'll still keep working.
The trust boundary between the front and back ends can be a huge boon to security as well, and some things are literally impossible to do with a multi-page app, and you can still maintain URL parity with new actions in your page.
That's why SPAs were, and are, great!
That doesn't mean everything should be an SPA! A photo, news, blog, or recipe website might be better laid out as a separate page for each individual item. However, there are tons of other types of real applications that can only be built as an SPA.
Are they unwieldy, sometimes hard-to-code and maintain, and sometimes result in a poorer experience? Yes, but that can also be true of a multi-page app, especially if you're trying to shoehorn an SPA experience into a multi-page app and want to maintain the same user experience as a user moves around within the app.
A multi-page "app" isn't really an app anymore; it's a server-side app that is producing multiple pages. A single page app literally is running in the browser and only sending a bit of data back and forth with each user interaction. It's just a completely different model.
I don't disagree with most points here, but I did chuckle at this one:
> YouTube is a great example. Being able to keep a video playing while you explore other videos is fantastic.
I hate that (mis)feature. When I click something else, my attention is on the new thing. Having to go find the little still-playing video window to close it is a hassle.
As a counter: I love it. It allows me to add videos to a queue without having to build a playlist beforehand. And halfway through the queue, I can add more without having to navigate away.
And if you don't, you're probably going to open in a new tab. Too many webapps are designed with complete disregards to the fact that browsers have tabs.
YouTube is awfully slow - back when I used it I dreaded accidentally mis-clicking on something because it would initiate 3 seconds of stuttering and shit moving around everywhere while their terrible SPA (poorly) reloaded the page.
Nowadays I use Invidious which is a proxy that renders good old server-side-rendered pages and it manages to be faster despite being a proxy.
I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6). So why would I ever do an SPA again if it were up to me? I would use https://github.com/jfyne/live which is inspired by Phoenix LiveViews. This is my professional opinion, having many years of experience in both kinds of web apps.
Template based UI programming is like going back to the year 2007. Your views should be reactive. Elm, Flutter, React, Et Cetera understand this. Having a function that takes data and returns a view is much better.
Isn't a template essentially a "function" that takes data and returns a view? I don't have much experience with UI programming but I don't really see the conceptual difference.
We can debate syntax but a Go or Python based template language is not conceptually any different to JSX based syntax. Both are essentially functions that take some input data and return the data formatted in HTML.
Sure, if you implement a trivial single-task app (one tiny feature of a Calendar app) with an unfriendly UI, you don't need an SPA. That doesn't prove anything.
It doesn't "prove" anything, but it's a data point, and quite a lot more thorough than your dismissive comment. If you want to make a well supported counter-argument, please be my guest. It's easy to criticize, it's harder to make a thoughtful argument.
I kind of have to agree here. There are very few times I've ever worked on a SPA and felt like throwing it all away and using the alternative.
The last time I thought about this, which admittedly was many years ago, the alternatives that I knew about were: server-side frameworks like ASP.NET MVC Razor, PHP, RoR templates, Node.js EJS, Jade (now Pug), and static HTML.
Nowadays, you can create extremely elegant and performant SPAs with tools like Next.js and Remix, so I really couldn't agree less to the OP.
You're being very rude and dismissive. I may well have more SPA experience than you do. Don't make assumptions about people and then use that to dismiss something they say - we're better than that here on HN.
wow you must be incredibly smart and discerning, being able to confidently make assumptions and judgments about people's lives and background based on one or two HN comments, and then dismiss them as an ignorant and incapable fool.
I have worked as an engineer on products in a lot of different domains in my career including:
- edtech
- real estate
- HR/payroll software
and every single project I've worked on had enough complex state to benefit from using a SPA.
I've also worked on one complex web project run by someone dogmatically against client-logic, and it was absolute hell. The codebase was full of janky hacks to approximate the same complex session state and full interactivity that a SPA provides trivially.
This whole thread seems like a huge echo chamber of people who seem annoyed that FE development is getting too complex.
But do you all really think that the entire industry is so disconnected from its needs, and the entire community of FE engineers just have their heads in the sand about the requirements of working in their domain of expertise?
And to everyone saying SPAs are sometimes useful in very rare occasions, what web apps do you use regularly? Gmail? Jira? Slack? LinkedIn? Figma? Notion? Docs? Dropbox? Airbnb? Netflix? Airtable? ...
How many of these use javascript to do the heavy lifting on the client?
In your experience how often did the complex state have to be modelled on the backend as well as the frontend, to provide validation of submitted data?
And for personal interest, how did you handle streaming in updates and edits from multiple people, and stopping people from editing eg the same real estate listing at the same time? I know it can be done but I find it easier with server round trips for every request.
As for your question about persisted data, yeah it definitely needs to be modeled on the backend, right? How much modeling should be done on the FE is a good question. This question is sort of why GraphQL exists. GraphQL provides a contract between the backend and the frontend about what the data sent between the two needs to look like. Apollo provides a pretty good and easy-to-use GraphQL implementation in my experience.
As for real-time updates, this hasn't been a real concern in most of my professional work. If I needed to support this, I think what I would do is:
1.) Define a clear set of actions for everything that needs to be streamed to users real-time (IE, I wouldn't try to stream the full state tree itself, this is where conflicts would arise)
2.) Determine how each action mutates the graphql tree
3.) Add a process that watches for these actions at the top of the React tree and manipulate the GraphQL cache as necessary in response to the incoming actions, (coming from a WebSocket connection, for example).
If you stream the actions, you may be able to resolve simultaneous edits naturally. Or, if you really want to block simultaneous edits, I think you should 1.) definitely ensure the edit is really blocked on the backend, and 2.) stream on "disable" action to the user via webso
State is a pretty loaded word, but what I meant more specifically is complex application state, and by that I mean the ephemeral state that manages a user's usage of the application.
For example, in the real estate use case, there may be, all on the same page:
- a table of listings and grid of listings that can be toggled between
- a map that can be displayed alongside the table with all the listings plotted
- dynamic updates on the map that highlight listing when it is hovered on the table
- a detail modal that displays whenever any listing on the table or map is clicked
- pagination that can controlled from either the modal or the table
- selection state for each row on the table and a bulk action bar that conditionally appears when the row is selected.
- filters and search that need to work quickly and not disrupt the user experience
None of these things are particularly unusual or groundbreaking, but trying to control all these stuff via server-rendering or jquery would be a huge mess and potentially a jarring UX.
These are good concerns. IME it's important to be able to share code and schemas & domain data manipulation code between BE and FE like you can do eg with Clojure + ClojureScript.
Every week someone posts some half-baked blog ramble about how SPAs are bad (except for media sites!).
How about this - I am just as or more efficient working with SPA frameworks such as React as working with server-side-rendering. I have invested in a skill and toolset that can deliver any sort of website or web application from blogs to Youtube to Figma. I don't see any reason I would invest in learning an MPA framework that is only good for a subset of that.
If you are delivering content-only website with simple forms you might as well just use a CMS and call it a day.
Why are wood shops loaded to the rafters with tools? Because there is no Golden Hammer, only people who think they’ve found one.
You’re saying you’re doubling down on a single solution, which is probably not actually true, but you are surrounded by younger developers who will copy what you seem to be doing rather than what you’re actually doing.
All of these unresolved arguments are about team dynamics, not technology, which is why they never get resolved. Because we talk about our experiences or “objective” things like logic.
> All of these unresolved arguments are about team dynamics, not technology
No, it's definitely about technology. Let me simplify this for you. Technology A can do thing 1 very well, and thing 2 decently. Technology B can do thing 2 well, but can't do thing 1 at all.
In reality, people who only do technology B claim technology B is necessary to do thing 2 and go to great extents to write blog posts claiming such, while people who only do technology A get on with doing things 1 and 2 without feeling the need to rant.
I regularly stumble upon stale data in SPAs, even in big names' like Linkedin, Jira, Github, etc. I wonder how the hell corporations with thousands of engineers, lot of them being brightest engineers in the world, can't make proper SPA.
Can we just go back to server side rendered pages, with a bit of JS sprinkled in, please.
Github is not an SPA. They use the middle road of dynamically loading HTML snippets, using webcomponents, and lightweight JavaScript. Any problems you see with most of Github's interface should be chalked up to server-rendered pages with sprinkled JS.
I dread using GitHub's fake client-side navigation. For me it's always faster to just load a link "for real" rather than wait for their terrible JS to pretend to load the link for me.
Interesting that you use Github as an example, when Github is not an SPA. So basically just admitting these problems aren't necessarily inherent to SPA's, but to the developers/teams building them. They may just be a bit harder to get right in SPA's.
GitHub is a great example of a site that would benefit from actually being an SPA, imo. It is server rendered pages with JS sprinkled in, and you can easily end up in the situation where parts that live update fall out of sync with parts that don't. For example, being able to see that an issue is closed while the badge on the Issues tab still says you have one open.
I share your general sentiment over the state of them though. It's not actually that hard to avoid breaking navigation buttons, having links open in new tabs correctly etc, so I don't know how it gets screwed up so much.
This ship has sailed. SPAs shortcomings are widely known and addressed by frameworks.
Whatever MPA alternative you bring will need to address other shortcomings. There will always be something quirky due to building applications in a technology designed for hypertext documents.
Many of those shortcomings were solved 15-20 years ago. Far too many SPAs are little more than old school request and response, GET and POSTs. I've literally had to drop into the dev tools console just to push through a page with 7 sets of radio buttons because Angular broke in some spectacular way, on a page that is and should be boring (prescription refill page).
I have in my life used a couple of SPAs where I thought "Man, this works really smoothly and quickly!" Like there have seriously been a couple really good ones.
They absolutely can be done right, I've built one I think is done right. I've built a couple. I don't think the average team has it in them to build a good SPA.
The majority of SPAs are user hostile hot garbage.
The 95% of other SPAs were full of minor frustrations that could have been easily avoided by not being an SPA including
1. Completely unhandled errors with no indication anything is wrong.
- This is a majority of SPAs. Any request error on flakey internet? Don't bother tell the user, just break.
- The sheer number of times I've needed to open inspector to see that something has gone wrong… At least an actual non-SPA request that fails will show you an error page.
2. Broken… native… everything
- 2.1 Especially "broken open link in new tab"/middle click - see next.
3. Inability to run the site in multiple tabs.
- State is entirely local so state gets broken *easily*.
- Some just outright refuse and warn you.
4. Adding everything I do to the browser history api
- Makes it even worse than the back-button-not-working of old. Have to hit back a thousand times.
- Scrolling SHOULD NEVER add things to my back button. NEVER.
5. High CPU usage on a site doing seemingly nothing
- Looking at you, Medium.
6. Generally being way slower to use than the previous non-SPA website
- Looking at you, Wells Fargo.
7. LOSING MY POSITION ON HITTING BACK
- The sheer number of times I've been scrolling down an infinite list for like 30-45 seconds, click on something, nope not what I wanted, hit back, returned to the top of the list is entirely unacceptable as a society.
- This is very often combined with 2.1 and 3 to make for a truly infuriating experience
Like don't get me wrong, you can do a lot of this junk in a non-SPA but the failure state is almost always better.
> Inability to run the site in multiple tabs. State is entirely local so state gets broken easily.
I have seen this more for sites where a TON of state is stored in the backend, the site expects the user to have 1 tab that is kept in sync with what the server thinks that user session is doing.
Heck I have seen sites that throw up errors asking me not to open multiple tabs.
I have also seen sites where if I have Tab 1 on Page A, and I open Tab 2 to Page B, then go back to Tab 1 and navigate to Page C, if I go to tab 2 and try to navigate anywhere, it just goes to Page C.
I'm not clear why the author thinks that "media sites, really" are the only SPA use case. Have they never used webmail (like GMail), map apps (like Google Maps), or social networks (like Twitter)?
I give you Google Maps is a perfect example maybe for SPA.
But Gmail? Why do we need SPA for that? Receiving emails notifications could be websockets and clicking on email should go to a new page displaying the email. I dont know if the initial gmail was SPA or not, but the current version is very very slow and consumes a lot of memory to display some emails that worked even in terminal clients, remember Pine?
The same for twitter? I anyhow have to press "Load 39 new tweets" to load the new ones so why is it a SPA? Just for that notification? If you would give me a twitter client where I need to refresh the page to load new tweets but works faster and consumes less memory I will happy use that.
Do you want a full page reload just because you deleted an email? Or flagged it? Or marked it as spam? Or even do you want your webmail in frames just to have a reader pane? Webmail is a great SPA candidate.
Anyone can choose the tech stack, patterns, or whatever that he likes. But developers enjoy being absolutists, and deem something they don't like as a MISTAKE, or would tell you that the way they think is the ONLY way to think.
You do your app the way you want depending on the Ux you want to provide, on the tech you enjoy implementing, on the patterns you like to follow.
> Anyone can choose the tech stack, patterns, or whatever that he likes
Maybe for personal projects, but 99% of us have to use the tech stack, pattern or whatever of our employer that was decided on (presumedly by some consensus at some point in the past). Publicly pointing out the flaws in what might have made sense then but might not make sense now is a Good Thing so that those flaws might be taken into consideration in the next round of consensus building.
I don’t understand what sort of cave trolls think I get to decide for me. Even as a lead I am making decisions based on the situation on the ground and those are informed by what people are comfortable with and what I can help them get comfortable with. It’s a team activity.
But every conversation has someone spouting off like these are experiments in a Petri dish. Petri dish projects don’t matter. Haven’t for a long time.
That's what interview processes are for.
And if the consensus goes for a stack you don't like, let's say for example for doing and SPA, then maybe it's not a mistake as stated in the article. Unless you guys think that any engineer that makes choices different than yours is incompetent.
Don't limit this to SPAs, include the Jamstack, which has all the same problems, and the false promise that if you can statically render a few pages or parts of pages and put them on a CDN, everything will be fast. It won't, because to load dynamic content, you still have to do a lot of work and talk to a (gasp) centralized API over the internet.
SPAs and Jamstack favor developer convenience over end user experience. Let's have fewer loading spinners, and more SSR-by-default for pages with dynamic content.
But there's a cost savings, right? JSON requests for just the data necessary vs. sending the whole HTML page each time.
Personally I'd prefer to develop a website the old-fashioned way, but I see that the bandwidth savings is a major point for SPAs and if you're running a business...
SSR by default, and then if you want, client side hydration and navigation so subsequent page loads happen in the client. However, the size difference between an HTML response and a JSON response is negligible, and HTML responses don't have to wait for Javascript to download, parse, execute, kick off off a request over the internet, get the data back, execute the result, and update the DOM. Browsers have literally decades of optimization to show HTML to users as fast as possible, and doing this in Javascript is fundamentally slower.
Am I the only one preferring good old-school, "boring" stacks that I can run entirely on my own machine if needed and understand the sequence of operations as opposed to relying on dozens of third-parties, services, APIs, etc just to do what a stupid PHP script on shared hosting could do 20 years ago? I don't consider the modern complexity as convenience.
One thing that I found working in a bigger organisation is just how well React encapsulates Design Systems. You can have a dedicated team of talented frontend engineers that builds a really solid design system, and then other folks building the actual user facing bits can use them, and everything will be nice and consistent across all the various apps.
For example look at how well this has been going for Uber.
Now this is certainly possible, and even relatively easy to do in server side frameworks, but as others have stated, its harder to make sure it works nice in all the various edge cases and visual flair that is required for end users, and keeping it all consistent and upgradable across the board.
React (and I'd wager other component based approaches) shine there - its low level enough that you can implement anything with it, but still allow you to build complex things fast. And then are free to implement the actual business logic of the backend with the technologies of your choice. Even better various teams can do that in their preferred language, without the end user being affected by the difference.
Throw in react native to make the styles transferrable to mobile apps and you have the perfect sweet spot for largish tech companies. And since those tend to be the more vocal ones, we get this, in my opinion largely deserved desire to build SPAs.
Smaller teams / startups of coarse don't have those incentives, so they will understandably not have the same cost / benefit analysis.
The problem with SPAs is that they have been misused and overused, at least in Italy. Tons of projects built with SPA in which we have to re-implement basic browser features like the back button, just because project manager has no idea of how this technology works. I've worked on at least 4 projects which could be written in Nextjs in half of the time
This is way oversimplified. You can build a completely static website with NextJS. What I love about it is that you can do everything : SSR by default, SSG as an option, and awesome features like ISR etc.
However, the way NextJS implements SSR is really weird right now : if you use their <Link/> component, the pages props are actually fetched with an XHR request, then the page is rendered. I don't know why. It does feel like an SPA in the end.
Next.js recommends delivering static assets by default and is geared towards that.
> We recommend using Static Generation (with and without data) whenever possible because your page can be built once and served by CDN, which makes it much faster than having a server render the page on every request.
If you need dynamic content, they recommend server-side rendering, and lastly client-side rendering only if the page is unaffected by SEO and requires a lot of in-page updates.
I was going to say.... ironically NextJS is just an additional layer for creating static-rendered sites over an SPA framework. We have come full circle.
I think SPAs were the best solution we had at the time and I enjoyed trying to build good UX with them. Yes, React started fresh and ended up driving me back to Rails because I'm just not smart enough. That said, I am really excited about Django w/HTMX, Rails w/ Hotwire, and Next and Remix with React. Particularly Remix.
I can get good at a lot of things, but most of them (including half the ones I’m good at) really just aren’t worth my time and energy.
Ain’t nobody got time for that is more often closer to the mark. But anything that requires hypervigilance is eventually going to make you look dumb. Just don’t let them put “human error” on the RCA. Yes, You screwed up, but We put you there in the first place.
It should be obvious why SPA/PWA frameworks were developed by the likes of facebook and Google: Offloading their content rendering to the client.
Instead of Google/Facebook CPU cycles being spent on rendering their content, it's now the client devices, while the Google/Facebook infrastructure is "just" serving the data.
First lead dev offered me advice for the rest of my career.
Most of what you are going to see people argue about are cyclical fads. A pendulum. We try A and it doesn’t work. So we try !A. And when people forget why we stopped doing A someone tries it again over and over.
How are things different this time should be your second question. Your first question is what is the middle ground? Boolean logic falls on its face in the real world. If 1 is bad that doesn’t mean 200 is better. If 200 was bad the solution is not 1. The best answer is probably three.
I'm sure the data that FB and Google are delivering is far more expensive than rendering HTML would be. I am skeptical that server side rendering was a big enough bottleneck for them for that to be their primary motivation. I'm also skeptical that SPA frameworks would have been widely adopted by developers all over the world if they were just some conspiratorial plot by tech companies to save on CPU cycles.
This is completely inaccurate. Every millisecond of load time affects conversion so much that they would trade huge amounts of CPU to speed up a page load.
In my humble opinion, SPAs are not the fundamental mistakes. SPAs are applications. There's nothing wrong with having applications. The mistake was not maintaining a distinction between applications and content. The difference between a static document, a collection of hypertext documents, and a web application is very blurry. If it were less blurry, there would have been things we would have been able to do that we are not currently able to do.
SPAs were a good solution when page load/rendering times were longer. However with todays internet speeds, edge caching, HTTP3/Quic as well as todays chips and browser implementations page reloads are barely noticeable so you get all the goodness the browser gives you out of the box creating MPAs.
There are still some examples were SPAs are useful such as replacing complex desktop applications but 95% of web apps don't need it.
It was a big day for me when I realized the CSS perf tool had been removed from my browser because the clock resolution was no longer sufficient to make it work. Everything was <1ms.
Bloom filters for CSS were a huge deal, and the CSS load and apply times are one of several things SPAs were trying to amortize.
It's posts like these where I can feel the age of HN.
For many developers, especially in startups, SPAs are all they've ever known.
Now, I'm relatively young, but I'm old enough to know monolithic django before moving onto angular then onto react, and it is quite staggering what I'm capable of doing in SPAs as opposed to traditional web pages.
You mentioned Soundcloud and Youtube, but you'd be lying to yourself if you think the list comes even close to even stopping there.
How about fantasy drafts in DraftKings, Sleeper, or FanDuel?
How about chess like chess.com or lichess?
How about collab tools like Trello, Monday, or Asana?
I wouldn't even dream of building these types of applications in a traditional web app
The level of interactivity that is capable within SPAs makes applications like these seamless and snappy, and overall feel-good for the user.
What a total nonsense. I’m quite old in our industry standards and remember all this ”great and easy” way of working with backend templates and struggle to find it much easier than working with SPAs.
I also thank computer gods for SPAs each time I click in Github and wait for it junky slow interface to reload whole page.
Please save us from likes of ROR etc. that is slow and has awful user experience. Just try to use Basecamp. It’s so ugly, slow and free of any features at all that your eyes will bleed.
I personally am totally for ditching html and css from the browsers and just leave JS with some nice APIs (without DOM nonsense) and let us work with web apps like we would with desktop apps.
Web is not for documents any more. Just get over it.
"I personally am totally for ditching html and css from the browsers and just leave JS with some nice APIs (without DOM nonsense) and let us work with web apps like we would with desktop apps."
Have you tried using React Native For Web? The name is so ironic it almost seems like a joke, but I think the rationale is to simplify things as you are suggesting
Yeah it’s a nice idea, but it still has to mess with DOM and css in the end.
I just think that web apps are not web pages. And all this struggle with css quirks and all this power wasted on parsing DOM is not really needed. I know that if what you need is a blog, then html with css is enough. But building interactive apps with backend templates rendering ends up like Github (slow and with bad user experience), or it requires a lot of crazy jQuery hackery we have been doing in the old days. And I’ll pick building a React app any time I have a choice like that.
>SPA's suck! Here's my ad-hoc replacement architecture that you should totally just use!
Really though, this is a dead horse. SPAs are just a tradeoff like everything else in engineering. We trade the simplicity of a monolith for the ability to parcel out work efficiently between large disparate teams of frontend/backend engineers.
Most of that navigation stuff is long-solved - e.g. Angular's router will do a lot of that.
If you want to do a SPA without a modern library, then yes you will need to reimplement a bunch of stuff. But who would start from scratch? Unless you are doing something incredibly niche or tiny-tiny-tiny, just use Angular or React or whatever and don't worry about the minutiae.
Of course there will now be people screaming at their screen about how this attitude is everything that is wrong with the modern web etc. I am sure they'll get over it one day, or just go use gopher/Gemini if not.
I'm building business application at my job. Users navigate (filter, configure, visualize 3D models) huge lists of data (bill of material, product structures). SPAs are heaven sent. Delegating every filter or configuration action to the server would be insane. Same with server side paging. Another example is 3D viewing: When selecting a part in the viewer detailed data should be displayed. A round trip to the server for this? No, thank you.
I have to heavily disagree with this post. Which by the way lacks any in depth arguments.
A SPA is an Application and not a Web Site. With a SPA you can replace classical desktop or mobile applications, for example Gmail, Spotify or maybe Dropbox.
SPAs are good for that, because you just have to develop it once, instead of 5 or 10 times for all platforms.
SPAs are bad for traditional websites that deliver content.
I can't agree with this. That list of 9 complexities are well abstracted by the most common library or framework for SPAs. Having done a lot of SPA development I can say routing is not anywhere up on the list of trouble spots you do encounter. State management is another story.
When I was a FE developer building single page apps, I would hear these arguments and say "you just don't get it, man, SPAs are the future". Now that I don't get paid to work on SPAs, these and other downsides come into very stark relief, and it's the advantages which seem more dubious to me. I doubt I'll ever touch an SPA again, and I'm not mad about that.
Indeed: "It is difficult to get a man to understand something when his salary depends upon his not understanding it"
Everytime I see one of these binary "XYZ is good/bad" posts I come away thinking that either I don't know what I'm doing, or the author doesn't.
Having built relatively simple Django web applications, and having built and managed building complex SPAs with Angular/React and GraphQL backends, I have a hard time thinking of when I would ever willingly grab for serving up dynamic HTML ever again.
The mixing of concerns with something like Django vs just having a native JS application loaded and running in the browser pulling in data as needed once loaded is a world of difference.
Using straw man examples of people using a technology badly to claim the technology itself is a mistake is silly.
There's literal annals of examples of poor memory management in compiled software causing massive issues. Is allowing memory management to be handled directly by software engineers a mistake? In some cases, yes, people would be better off with garbage collection. But you'd have a revolt in embedded systems development if that was taken away.
SPAs create more surface area for inexperienced or poor developers to screw up the UX. But a talented team developing SPAs (which really is a misnomer as you're rarely not chunking and lazy loading things behind the scenes) will ALWAYS result in a better UX for users than dealing with the browsers loading individual pages, and very likely more manageable development too.
That said, as I've spent more time in development I've noticed there's a noticeable shortage of talented teams out there.
SPA's #1 draw back is that you have to rebuild browser functionality inside of the browser.
The browser natively handles internet connectivity, back / forward buttons, refresh buttons, URL management. Additionally, users have been trained to understand the responses, hit the refresh button, and use the back button. Browsers have gotten better at distinguishing between your internet being down and the website being down.
Good SPAs have to rebuild all of that functionality.
Use them where they make sense, and don't get religious about it.
I recently wrote a site to track Apple-silicon-native audio software. It works great as an MPA. It's fast, organized, and easy to use.
And the first thing someone offered as a suggestion was: "Why don't you use https://www.sanity.io/ for the content and nextjs or gatsbyjs for the front end?"
SPAs were not a mistake, SPAs were an attempt to make the front end work like front ends have ALWAYS worked.
Back before the web people made C++ and VB user interfaces that interact directly with the data source. SPAs are an attempt to make the web closer to that well known paradigm. POST REDIRECT REFRESH cycle was an insane programming paradigm that wasn't found in any previous edition of programming.
Not so. IBM mainframe systems (3270 terminal based) that ran most of commerce for a long time are basically the same paradigm as a web browser. Send a form to the smart terminal (GET), wait for the response with the field values (POST), send another form.
In fact there are adapters that literally turn these applications into websites by translating the forms into HTML. Commonly seen when you need to do something like change the beneficiaries on your health insurance.
“Client-server” paradigm came out in the 90s when PCs became powerful enough to run a “thick client” application, and was considered revolutionary.
>Back before the web people made C++ and VB user interfaces that interact directly with the data source. SPAs are an attempt to make the web closer to that well known paradigm.
I wish more web developers were aware of just how damn good UI tooling was for native systems. Stuff like WinForms/WPF/Visual Studio and Cocoa/UIkit/Xcode on OSX. Perhaps we could get away from the insanity of rebuilding a select component for every new project.
> POST REDIRECT REFRESH cycle was an insane programming paradigm that wasn't found in any previous edition of programming
Actually I'm old enough to remember old mainframe CICS programming that was a lot closer to the form-based HTML server-side programming of old. When "the web" came out in the mid-90's, it was actually a "blast from the past".
Most SPAs don't interact directly with the datasource, but interact with a middle service. Also many older architecture do draw entire "pages" on the screen at once, rather than manipulating only individual components. (at least not on every interaction)
Clearly, we can't have an SPA front end performing an SQL query directly. The HTTP/GQL/REST services are the SPA equivalent of that data source (they are still a data source). The C++ and VB apps written back in the day were single user programs so yes that's a difference but not by much architecturally.
"Pages" are similarly in SPAs too. We usually have a router that helps the app decide what main "page" is on the screen.
I showed an interviewer a piece of something I built in a traditional page-per-view design, with some xmlhttprequest where appropriate, and a sprinkling of Vue where it added usability to some of the modal dialogs. Their only response was "why didn't you build it in React?".
I stopped interviewing for front-end work since then. The landscape changes frustratingly too often.
I think SPA tooling solves a composability issue that people didn't realize they had, and so SPAs are used in a lot of instances where MPAs make way more sense and would be more performant, because the developers want to utilize the composability of components. The fact that SSR is a feature for React and Vue makes me think a lot of projects were really just aching for composability, not interactivity and dynamic data features of SPAs.
A think a lot of backend frameworks offer some attempts at frontend composability on the serverside but it's usually not the same approach that SPA tooling uses. I would love to get people's thoughts on backend tooling that is attempting to solve composability in a serious way, not just tacked onto an existing MVC framework.
This. I'm keeping an eye on the newer server side renderings like Remix because most of the time what I want is to be able to write components and have them render to HTML, with a few remaining interactive.
If Web components had got this right we the developers could have been happy and using composable components a decade ago.
I agree, I'm am pretty disappointed by how web components turned out. I still use them actually, on personal projects. But that developer experience is absolutely not where it needed to be, then the cool kids showed up and stole their lunch.
Having worked with ASP.NET and other templating engines way back when and now working with React, I can say that there is a world of difference between the ease of composability of ASP.NET templates and React components.
People really want composability and sometimes they need a tiny bit more interactivity than their server rendered stack offers without hacks (even if it's just more interactive forms)
The fundamental conclusion I reached is that all of the pain originates by having your state divided between client & server, and then being forced to synchronize the two.
Doesn't really matter what technique or framework is involved. The worst trip I've had is with angular 2, trying to put humpty dumpty back together again via tons of janky API calls.
The best solution I have used so far is probably Blazor. In server mode this gets you pretty damn close to 100% state lives on the server. I've had to write some javascript, but even then the abstractions for interop make it very clean throughout. I use eval to dynamically run methods against the client. This allows me to avoid having to serve any custom javascript source (aside from the blazor client js).
If it's an "application" there are no "pages" as that's an old (very old) and deprecated construct. Now if it's a "web site" with a collection of "web pages" - that's another matter. I've been building commercial SPAs now for over 20 years and I can say with much authority that users prefer "applications" over "web sites" for complex business management tasks.
I've also built some pretty huge static web sites (longwoodgardens.org for example) and it an absolute joy to do those as well. I would never recommend to such a client that they build an SPA.
So I'll state this opposing view - that "web sites" were a mistake when used for complex business applications.
To me one of the biggest distinctions here is the overuse of the term "App". I agree that a lot of websites written as an SPA were the wrong tool for the job. There are tons of examples besides the mentioned media websites where SPA is the way to go. Most, but not all, of the applications I work on feel like desktop class applications and the traditional server side rendered approach simply would not work. This includes when I was on the iCloud Web team working on the iCloud Drive App, the Mail App and some others behind icloud.com.
I think a lot of companies that default to SPA would benefit from a very quick traditional website. However, some of the applications that I've been fortunate enough to work on would never be possible.
It's seeming pretty fashionable these days to bash SPAs. I disagree that SPAs were mistake (or that it's often a mistake to reach for a SPA, even today) SPAs are now and have been a great tool to leverage when you want to build an application without needing to think about servers. Yes, there are tradeoffs. Yes, you should think about the thing you're building for. Yes, you should think about the skills of the developers working on it. That doesn't change the fact that SPAs can be great choice and not something to be perceived as a mistake.
If the choice was between building a traditional app from scratch, or building an SPA from scratch, then I think the article would have a solid leg to stand on: building an SPA from scratch does involve finding ways around things that browsers provide out-of-the-box.
However, pretty much no one writes SPAs from scratch, and there exist many very popular frameworks that handle the vast majority of the common SPA tradeoffs out-of-the-box, so that in reality, you don't really have to think about e.g. whether links are internal or external.
That's not to say that SPAs are always a good idea, or that they do everything well — the author's point about scrolling to the right place, especially when navigating backwards and forwards, is one thing that many SPAs don't get right, for example. And the rise of next.js and the like have shown that there are other benefits to hybrid approaches, as well, and there isn't a one-size-fits-all solution.
As for why SPAs have become so popular, I think this can be summed up pretty neatly: everything is code. There's something appealing to a software engineer about being able to control everything about how your app behaves, control when and how it loads or preloads data, how navigation works, etc. This comes with tradeoffs, you have to be careful about breaking user expectations and making things accessible, and if you go too far you can end up with a big mess ("just because you can make everything custom doesn't mean you should"), but that underlying freedom to make those choices is appealing.
No shit, Sherlock. Of course, all of this was obvious to any of us with more than 5 minutes of industry experience, alas this field seems super prone to reinventing the same things over and over again, making the same mistakes and never learning from the past.
Also, this article does not even mention the fact that SPAs are terrible for SEO. Of course, that's not an issue for YouTube, but it might be a huge issue for your clients, unless it's ok to not have any search traffic.
It is definitely not solved for the vast majority of SPAs out there. Where it is solved, it is not solved for free or cheaply, as it would've been if these apps used server-rendering tech.
The issue is you need some of both for an "optimal" solution.
Unfortunately, Javascript and the basic "controller" capabilities of a web browser just aren't up to the task.
Here are your "controller" options:
1) the server is the controller
2) the web page is the controller of itself (which sucks)
When what is probably needed is:
3) a controller that lives as an extension of the browser.
Frames, for all their issues, basically enabled #3. A controller frame could manipulate the view frames, and those frames were scoped/contained web page "processes". There were issues of course, if you hard-refreshed the overall page (and the "controller" frame) it would lose state, so I don't want to say that frames were a complete solution.
Client storage is half of the equation, and that was added. Good caching infrastructure, multiple asset delivery, connection multiplexing, that seems to be working so you don't need a "big bertha" first page. Standardized DOM capabilities and the like seem to be fairly well solved, and maybe the "Javascript problem" will be solved once ... crap the thing where you have an IR bytecode so you can code in anything in a browser... well that will be solved.
Frankly this needs to be solved. Apps and app stores are a pox upon the land, and the web browser can still save us from that.
Meanwhile essentially every major tech property develops SPAs and users enjoy them far more than traditional hypertext web round-trip-every-change pages
Big tech companies love wasting money and developing a SPA is a good way to do that.
Whether users prefers SPAs or not is debatable. Amazon, Github, and Aliexpress aren't SPAs because poor usability will cause users to move to competitors. If Hacker news turned into a SPA, I guarantee that it would suck big time.
SPA developers seem to be living in a tiny bubble oblivious of simple solutions to simple problems.
In what world is this not an SPA? I don't see page transitions hardly anywhere, except when you're switching from marketing material to repos maybe.
Additionally, the fact that GitLab (which is devops/issue tracking/wiki/etc.) ISN'T an SPA drives me crazy every day. I have to wait for so many rerenders that could just be seamless loads, it's actually insane to me how unoptimized of a user experience it is, especially when my happy path is super clear with respect to what content I load.
> SPA developers seem to be living in a tiny bubble oblivious of simple solutions to simple problems
I think it's hilarious who you consider to be living in a bubble, and what simplicity really means. Client side interactions need to be smooth. Web applications are consistently and increasingly presenting meaningful user workflows that can be made more resilient and responsive with SPAs. I develop tools for dataflow/workflow editing, scheduling, visualization, etc., and the idea that these things can be made to feel good without a dedicated client layer is truly an archaic attitude.
I've been thinking about this a lot, and the one thing I love about SPAs is that everything the user can do from the front end. They can do from the API. The trend has essentially tricked tons of corporate apps into opening up APIs to their users. My screen scraping skills are starting to get rusty, but it's worth it.
I sometimes daydream about a framework that allows me to build a spa and a server side app at the same time using the same url scheme.
Here's the thing: so-called "JAM stack" apps are the cheapest to run, right? I realized this while I was thinking about how to create the cheapest site possible. Mainly, you want to minimize bandwidth. Well, SPAs are designed to do this. The site gets cached on the first hit, and runs usually JSON requests in the background after. So I think a big motivation for building SPAs is because they're cheap to host/run.
This article doesn't seem to be thought out properly. I mean the name already suggests what Single Page _Applications_ are good for. They are useful when you want to build an application in a browser and not just a regular website.
State is probably the main factor why you would like to do this. I can agree on that SPAs are used in some places where they don't fit (mostly content heavy sites). But they are not a mistake.
True, but irrelevant. I have written an OS GUI, including full file system support, in the browser that performs faster than native OS GUIs. My biggest learning from this is talking about performance in a job interview is the fastest way to kill the interview. Performance, like security, requires trade offs that deviate from comfort. If the common developer is insecure comfort is the only thing that matters.
JS hiring expects the following: React components, 2-6 weeks of JS practice, the ability to use map/filter on arrays, and CSS. If you overshoot that you begin to enter unknown territory that intimidates other developers. The better you are the less employable you become as the further from the bell curve you drift.
If you are wondering why this is or how we got here the answer is trust, or the lack thereof. In software there is a long standing bias: if you can see it visually its worth less. I have been doing this work for more than 20 years and that bias predates my work, so its been around for a while. Bias is continuously reinforced by the lack of standards in software hiring and the inability of employers to train their employees.
This lack of trust means that employers do not trust their employees to perform original work and likewise the developers don't trust each other. This is why absolutely everything, I mean this literally, is a downloaded NPM package, because the developers will trust an anonymous stranger to write original code before they trust anyone they know. There is all kinds of excuses to qualify this, of which some are bizarre and nearly all lack any kind of merit.
This is why its irrelevant what the browsers provide. Its baked into the framework, an NPM package, or ignored.
For me, things like react and vue are DEDICATED to the front end. They are great for building UIs and have great ergonomics.
Backend frameworks that I LOVE (asp.net, laravel) have templating languages that feel like an afterthought, and passing data to them sucks (I usually have to redeclare what data they receive somewhere, or it’s entirely a dynamic paradigm) editor support is ok AT BEST… all of the sudden part of my app is dynamic c#, which c# isn’t good at.
My choice of backend should be absolutely divorced from my choice of front end. I can write an api in node, c#, go, etc and I don’t have to totally change how my front end works.
And splitting state between front end and backend (as mentioned throughout the comments here) is awful and error prone. There is a reason large scale apps aren’t using vanilla js or jquery and hand rolling state management etc.
It’s all about the size of the app, complexity, division of labor (I can hire a front end specialist who spends 70-80% of their time on front end)… the only goal isn’t JUST performance but if you do it right you get that too.
These types of posts always miss a common reason why an SPA might be desirable in the real world: cross-company collaboration.
The assumption made in these posts is that you have total control over your entire application stack. Infra, Backend, Frontend, Ops, etc. In the real world, often times different companies are collaborating to build a final product for a client.
I worked at an agency that built an SPA because the frontend and backend were built by two separate companies at the same time. We’d meet to agree on what the APIs would look like and what shape to expect in the data payloads. Once we had some sample data, we could build a UI against that data.
When the real API was ready, we just switched the URL in the app config and everything started working.
If we didn’t build that as an SPA, we wouldn’t have been able to make the deadline the client was aiming for.
In a perfect world, would this have made sense to build as a MPA? Probably. But in the real world, you sometimes have to build things given some non-ideal constraints.
I also notice how much longer it takes to build the same crap we built 15 years ago with just html/css/js, and no, projects these days are not more sophisticated. Same old form submissions, but with a monstrosity of a project and crazy rates of devs who wants to constantly upgrade/update/migrate so some newer JS framework :shrugged :evilsmile
Many projects are absolutely more complex than they were 15 years ago. The web is now a space for fully-interactive applications, not just interlinked documents and forms
SPAs are ideal for web applications where users are manipulating application state in real time. There are many situations where this is applicable, you can't build something like e.g. Office on the web without an SPA, calling SPAs a mistake is trendy, but betrays an ignorance of the practical tradeoffs of an SPA.
I usually bite my tongue when these articles pop up weekly, but let’s ask ourselves a question: did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake? Or did this guy with a blog miss something?
I’ve recently worked on converting a large code base to an SPA and the improvements in DX, UX and performance are enormous. Even the old timers that resisted the project have all come around.
This doesn’t mean your blog should be an SPA. It shouldn’t. but reducing the valid use cases for them to Youtube is equally ignorant.
I generally agree they are being overly applied, but that’s not an indictment on the technology whatsoever. Fads in technology happen (“rewrite it in rust” is a recent one). The fact that many people are falling into this fad says nothing about Rust as a technology other than people love it enough to overuse it.
> did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake? Or did this guy with a blog miss something?
Today I opened the Music app on my Mac to cancel a subscription. It asked me to use Touch ID to authenticate (fair enough) but then immediately fell back to asking me for my Apple ID & password.
This is on a Mac that's been logged into iCloud for ages, has a working iCloud connection (exchanged some files through it today) and I installed an app from the App Store today (without being asked to reauth, suggesting my session is indeed still valid).
The fact that MacOS frequently asks for Apple ID credentials seems to be a common and widespread problem that I myself experienced for years (sadly this occurrence wasn't a surprise for me - if anything the initial Touch ID prompt was more surprising as I couldn't believe it would actually not ask me for my password this time), so I wouldn't use big names as a sign of quality - if anything it's the opposite, big names means lots of employees who might have their own reasons for doing certain things or preserving a status-quo that might benefit them & their careers at the expense of the user experience.
> did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake?
Is that so impossible? There are many other considerations that go into technology choices at these companies. There are trade-offs involved, and for companies with huge teams of developers the considerations need to be very different than for small–medium sized groups of developers.
I would argue that a smaller group of developers can focus much more on user experience and engineering efficiency, whereas a large company has a organisational scaling issues and a significant bureaucracy to support. At a large company, engineering considerations come second to very many things. It would actually be surprising if the trade-offs and choices those companies made were correct for other very different companies.
ANY modern site uses something like nextjs or any other static site generator. The q is then if you make the site isomorphic or not and how the need for dynamic content looks.
There are no other viable options today for large professional sites.
If you have the problems described in the article you probably are not using a web framework.
SPAs exist for a reason. Same with SSR. Developer ergonomics play a bigger role than you think. And if you think that the choice is either SPA or SSR then you haven't been paying attention to recent developments in the frontend world.
Websockets+SSR (PhoenixJS) attempts to store state on the server rather than the client; in that way you can still have stateful interactions with minimal JS. NextJS does an amazing job patching the bridge between SPA+SSR by having the same codebase run on the backend and the frontend. What I would like to see more of from this industry is less "grass is greener on the other side" and the unification of a single tool that allows for the cross-collaboration of SPA + SSR without having two distinct codebases that one has to context-switch between.
I think one of the main reason SPAs are overused is because it's hard in 2022 for your users to wait after clicking on a link. Users are now used to instantaneous, especially since they all have a smartphone with apps on it. We, as web developers, try to give the best UX to users.
I agree with you and I think there are some good SPAs. In my case what makes me angry is opening a presentation website and seeing a loader because someone decided to make that a SPA.
It is annoying to see titles such as this, since SPAs are most certainly not a mistake (the article itself points out that the Youtube SPA is not a mistake).
The truth is most devs struggle to implement SPAs well. To implement an SPA well, you need to understand browser APIs extremely well (such as the History API), and in my experience, most devs don't, hence the broken back buttons etc.
To me, there is nothing nicer than a well made SPA, and often, the best SPAs are faster and lighter than the desktop apps they replace. I believe they are the best way to deliver software in the current age, and the sandbox that the browser offers actually provides users with a more secure execution environment than traditional software delivery mechanisms.
I am mostly on the SPA-hating camp. There are two issues that annoy me the most. They are not a framework's fault but some kind of "mental model" fault:
First. When doing SPAs, APIs tend to leak a lot more info than needed, opening the door to attacks not commonly seen on server-rendered pages.
Second. Applications' bundle tend to have way more than users needs, even UI's they should not have access due to security/permissions. Most developers are not even aware of this problem and don't know that sensible info/features/endpoints are leaking.
As I said before, those are not faults at the framework level, but the development style that I seed used when making SPAs always led to them.
They were necessary from a perspective of "we need a way to develop a company's web presence in a way we can send kids to code camp to get the gist of." Of course they weren't a wonderful thing in terms of actually building sustainable infrastructure, but what's that to stand in the way of business's need to go to market yesterday?
Code camps don't have time or resources to educate their students so we got the reinvent-the-world half-solution that is the SPA. SPA frameworks won't ever go away but you'll get the chance eventually to go work on something better-architected than your run-of-the-mill NodeJS shitshow.
I don't think that's accurate. SPA's arise from the desire to put something like Slack in a web page. If bootcamps are responsible for that, I don't see how. Isn't it more likely that they meet the demand rather than create it? And bootcamps taught Rails long before they taught React.
And let's be honest, making a server rendered site with some traditional Python framework is in many ways just as easy or easier than making a SPA.
I don't know why routing is the sole focus of the article. In all my SPAs it has been a set up once and forget about it deal. No one is constantly reinventing the wheel there, the churn is in other areas like reactivity and state management.
its easy to make bad SPAs nowadays. imo more time needs to be spent in the tool/environment/framework/language selection and evaluation process.
also, many SPAs cant even handle basic forms correctly anymore, because developers learn more javascript than html5. like the author pointed out, rebuilding features in js that already exist, just because one is unaware of the fact that it exists or what the underlying design choices have been, often is a bad idea.
are there actually still people that care about noscript? i mean, i get that most people dont care and js is enabled by default in most browsers, but the no-js-web-world is also quite interesting.
Traditional dynamic web servers can solve a lot of the same problems that SPAs and event front-end frameworks like React solve, by just applying software engineering principles to the whole stack. That's what Novo Cantico[1] does, and a lot of what I've been trying to say in my blog posts[2] that explain Novo Cantico.
If not SPA, which technologies would you suggest for a web app similar to an IoT dashboard, with gauges and other UI elements that update every second? The server is written in ASP.NET Core.
I was considering Blazor server side but it does not seem to be very popular (compared to react, Vue, angular, etc) and I am not sure it's a good choice for the long term (MS likes to kill UI technologies). Approaches like htmx and unpoly do not seem to be appropriate if a large portion of UI needs to update frequently (feels similar to implementing the Blazor approach but inefficiently).
It makes sense when what you expect is an actual application. Tools that just happen to be running within a browser for convenience. The browser just happens to be delivery mechanism.
On the other hand if the user expects navigable, hyperlinked content, SPAs just get in the way of navigation and make users' lives miserable for no good reason.
I want to move forward, move backwards, make a bookmark, open multiple tabs. It is frustrating when the application makes it impossible when those would be completely reasonable operations on, say, news site.
Users do stupid things regardless of the implementation. The extra work to implement a SPA is worth it because you can swap material in and out on demand without constructing a complete new web page.
I think SPAs are awesome, there are just so many cases that SPAs can handle easily and more gracefully. From non-redundant input checks over interactive elements to optimizations for spotty networks or even offline usage.
Anyway, it's painful when a page won't load or it takes 10 seconds to load for no apparent reason. That's why profilers need to be used, loading indicators within the elements and also there's the trend towards frameworks with small footprints or even to go framework-less.
Using them for everything and everywhere as a default option might have been a mistake. SPAs in general are not a mistake (but generalised headlines do bring in the clicks so there's that).
As a user, when I'm using an "application", on the web or the desktop, the last thing I want is for the entire UI to be reloaded for me after every action. For applications it makes sense to be run on a single page, fetching only the data when it's required and that's it.
Unless you already have a SSR in place(or you're familiar with it, e.g. Django, Laravel, Rails,etc), I feel SPA(or MPA) is actually a decent choice albeit the learning curve. Separation of concerns is always good. With SPA frontend developers can develop the UI using restful or some web APIs provided by the backend, while backend engineers can advance the server side and keep the API consistent.
I had the pleasure (aka hell mode) of building a content site as a SPA because some non-technical manager kept pushing it (it was one of those companies).
It was an insane task to meet all the SEO requirements, we ended up doing server rendered pages, and keep in mind this was years ago so there was not a whole lot of support or tutorials on how to do it.
Oh well, I got paid to learn a bunch of new stuff so I can't complain :D
Yeah, I was gonna say SPAs are not really good for marketing type of sites. Doesn't work easily with SEO. I learned this the hard way, but there are other use cases for SPAs. Just don't use it for sites that require good SEO.
I am pushing for a rebuild of that site using Laravel and minimal amount of javascript, actually :D
That was the worst manager I've ever worked for. He also never pronounced my name right even after I told him, so he can go f** off. Still triggers me to this day :D
He pulled the SEO requirement at the last minute, since he would not invite the technical people to decision meetings.
If it makes you feel better, SPAs were a mistake when they were all the craze in Flash. Also way before that in Director.
In those two cases, they signified (or accelerated) the end of the useful lifespan of those languages.
SPAs, like frameworks, always make some things easier and some things harder. As long as you stay within the lines of what is easy, you are good. As soon as you stray outside those lines, you get punished.
SPAs are great, not a mistake. If you use the wrong tool for the job you can make look anything like a mistake. Sure, your two-page hobbyist blog won't benefit from being an SPA, having a well-partitioned Cassandra cluster holding your three-paragraph posts nor having a serverless autoscaling architecture, but that's how people like to build it.
The argument appears to be that browsers give you a lot of things for free that SPAs need to recreate.
But that's not true in practice. In practice most SPAs are created on top of a handful of extremely well tested libraries/frameworks that do all the work for you that the browser would do in an MPA.
That's not really a good reason that SPAs are a mistake.
I think people have forgotten how easy it is to set up a traditional server-rendered site with Spring Boot or Django or whatever framework. These days I see people adding a SPA as the default starting approach, which adds an entirely separate additional tech stack & deployable to the mix when it's not usually clear why.
My dev was asserting that a modest change to how a certain form control works would be "easier in React" (and this is on a piece of our application that's not even in any SPA right now). I marvel over the eagerness with which developers reach for React and friends nowadays.
lol another developer who hasn’t built an enterprise web app that requires The be benefits of a spa… and hasn’t taken advantage of the best practices around redux state management.
Have fun with managing state in the server while building apps that work internationally and offline.
This is probably true if you're writing an SPA from scratch, but in reality much of that complexity is handled by libraries like Next.js. I also think it's much easier to learn a React-like library than to learn various server-side template frameworks..
But it is so strange, most SPA's are basically just power point presentations. Why did it go like that? It isn't like people look for programmers to replace their power point presentations or PDF's, but for some reason that is exactly what they do on the web.
At this point most articles like this or tools addressing the problem discussed here replace one local optima with another, I'm holding out for something radically different, maybe something like makepad or bevy like ECS with good support for UI.
This is irrelevant in practice because the SPA's code is also loaded from the server - if the server is malicious it'll just serve you backdoored JS, unless you load from a separate domain and have the main server allow cross-origin requests.
If you want to defend against a malicious server you need to make sure your client doesn't load & execute code from said server - it needs to be distributed as a stand-alone application instead of in a browser.
Luckily we don't have to use them. Go ahead and do a full page reload when the user navigates to another page. Go ahead and implement interactive elements using jQuery. It all still works just as well as it did in 2012.
For me, I mostly work on applications, the UI just happens to be in a browser. This is different from server rendered sites that may make more sense in some scenarios.
I happen to really like, React, Redux, Material UI, etc... ymmv.
Also, more SPA framework logic needs to become part of the web platform; APIs beyond pushState, service workers, etc. You have to integrate it into the browser to really remove the confusion and the boilerplate.
The worst is when you have to use a piece of tracking or support software in your product and it pulls in a whole SPA with its own react/angular/whatever even when nothing is shown...
If our whole industry is wrong about SPAs, and a whole generation is wrong about SPAs, what is the best practice then? Does anyone have a comprehensive resource on the right way to do things?
I just wanted to note that the example - YouTube - is not an SPA. A click on a video from the homepage loads a distinct page, along with user profiles and other areas of the site.
I don’t see Navigation as a main problem and it can be solved quite neatly, not that much more complex than a normal site. Was expecting something about bundle size etc.
the frustrating thing is that i rarely find a page that doesnt take at least 20 seconds to load, even if i only want to see an 100x100 image. This happens no matter how fast computer i use and it 's despairing
The term "server-side rendering" gives me giggles every time
It's been so frustrating watch this play out over the past decade.
I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs.
Inevitably none of these projects end up taking advantage of the supposed benefits of SPAs: there are no snazzy animations between states, and the "interactivity" mainly consists of form submissions that don't trigger a full page - which could have been done for a fraction of the cost (in development time and performance) using a 2009-era jQuery plugin!
And most of them don't spend the time to implement HTML5 history properly, so they break the URLs - which means you can't bookmark or deep link into them and they break the back/forward buttons.
I started out thinking "surely there are benefits to this approach that I've not understood yet - there's no way the entire industry would swing in this direction if it didn't have good reasons to do so".
I've run out of patience now. Not only do we not seem to be learning from our mistakes, but we've now trained up an entire new generation of web developers who don't even know HOW to build interactive web products without going the SPA route!
My recommendation remains the same: default to not writing an SPA, unless your project has specific, well understood requirements (e.g. you're building Figma) that make the SPA route a better fit.
Don't default to building an SPA.
> And most of them don't spend the time to implement HTML5 history properly, so they break the URLs - which means you can't bookmark or deep link into them and they break the back/forward buttons.
The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up.
That aside,
SPAs are great for a number of reasons:
1. You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync.
2. You need a beefier backend. A SPA backed by REST APIs is super easy to scale. nginx can serve up static resources (the JS bundle of the site) LOLWTF fast, and stateless REST apis are easy peasy to scale up to whatever load you want. Now you just have to worry about backend DB, which you have to worry about with non SPAs anyway.
3. Less languages to deal with. If you are making a modern site you likely have JS on the front end, so with SPA you have JS + HTML. With another backend framework you now have JS+HTML+(Ruby|Python|PHP|C#|...), and that back end code now needs to generate HTML+JS. That is just all around more work.
I agree some sites shouldn't be a SPA, a site that is mostly text content consumption, please no. A blog doesn't need to be a SPA. Many forums, such as HN, don't need to be a SPA.
But if a site is behaving like an actual application, just delivered through a web browser, then SPAs make a ton of sense.
Your arguments seem to be assuming a particularly bad implementation of a traditional backend.
1. A good server-generated-HTML backend will have no more state than a good server-generated-JSON backend. The client state is all stored in the client either way, whether in JS variables, HTML tags, or the URL.
2. A good server-generated-HTML backend doesn't do significantly more work just because its output is in HTML instead of JSON. A bit of extra text generated isn't going to increase your CPU load in any meaningful way.
3. There are only fewer languages to deal with if you aren't in charge of writing backend code. If you're in charge of the backend code, you still have to pick a backend language for your JSON API.
I think you're assuming that the choice is "SPA" or "messy stateful monstrosity". It's perfectly possible to build a RESTful HTML-based API that is as clean and stateless as any JSON API. PHP's been starting each request with a clean slate for decades.
28 replies →
> 1. You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync.
If this were true, you wouldn't need a REST API. I don't understand what you're trying to say here. When you make a REST call to get data, you instantly have two different sets of state: the client and the server. It's no different from SSR, it's just transmitted in a different data format (json vs html).
> 2. You need a beefier backend. A SPA backed by REST APIs is super easy to scale. nginx can serve up static resources (the JS bundle of the site) LOLWTF fast, and stateless REST apis are easy peasy to scale up to whatever load you want. Now you just have to worry about backend DB, which you have to worry about with non SPAs anyway.
You do the exact same thing with SSR. Stateless shared nothing app tier instances. Been doing it for 15 years now.
> 3. Less languages to deal with. If you are making a modern site you likely have JS on the front end, so with SPA you have JS + HTML. With another backend framework you now have JS+HTML+(Ruby|Python|PHP|C#|...), and that back end code now needs to generate HTML+JS. That is just all around more work.
You can use JS on both the frontend and backend. Or ClojureScript. Or TypeScript. I'm sure there's others. But yes, for many languages this is a potential negative of SSR.
6 replies →
> You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync.
This is a bit weird to me, in that I'd say that cuts in the opposite direction. State can exist in at least three locations for most applications: db, app server, and client. Keeping state consistent across all of them can be difficult in the best of times, but thin clients by their very nature carry less state, lessening the burden. Sometimes client state is necessary, for richer user interactions, but for all but the most cosmetic of purposes you're going to have to replicate that state on the backend anyway, to enforce business and security requirements.
7 replies →
This is missing the real reason that people write SPAs, which is that React solved web components, which are hugely beneficial for almost 100% of web sites, and thus became the standard for building web sites, and with React it's easier to make an "SPA" than to make a "traditional" site and users don't know or care either way.
8 replies →
I agree with all your points, but I think it's worth pointing out that those benefits you mentioned are largely for the developers. As a consumer I love a well-written SPA when the problem set calls for it, but most of the SPAs I have to use are garbage. I don't fault the tech for that, although I suspect that a lot of those SPAs were created by "me too" people that just wanted to build a SPA. When React was in the pre 1.0 days, I did that, and several people on my team as well (so I'm not casting any stones here, just trying to state facts).
Last time I bootstrapped a React SPA I don't think cra includes a router ootb.
1 reply →
2. Hard to believe that is true in the general case.
Typical scenario for SPA is to use some sort of REST API, these API:s are usually designed for general usage, not specific usage, i.e. designed to be reused between components and views thus they basically return everything of a specific model regardless if data is needed or not.
Therefore the controller queries the database with the equivalent of SELECT * on a table (or perhaps multiple tables with joins) and then exposes every field.
And in many cases one request is not enough because the common generic design of REST APIs, thus a few request more are fired that results in multiple SELECT * against the database, and eventually the equivalent of SQL JOIN is performed in JavaScript.
Already SPA solution has an increased cost by asking for data that is currently not needed, not only in the traffic between the database and the backend but also in the traffic between the backend and the frontend.
And because we want to be good REST citizens we sprinkle the JSON payload with timestamps, resource urls and pagination information and what not and in majority of cases never to be used.
Comparing that to SSR where you can fetch what you need from the database with custom SQL query (I hope you do, otherwise the SQL leprechaun will make a visit).
Just imaging how much data there is on the web that is requested and then just discarded, not even looked at.
It is possible to design custom REST endpoints for each component, but then of course what is the point of a SPA then? If you are already writing a custom REST endpoint just return HTML instead of JSON and then swap in the new and swap out the old for your component (one-liner), the end result is the same.
SQL -> (Array of) object(s) -> JSON -> Javascript (Array of) object(s) -> HTML
can therefore be shortened to
SQL -> (Array of) object(s) -> HTML
3. That doesn't make any sense, number of languages are still the same regardless.
25 replies →
> The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up.
They might not mess up history when using a standard routing library, but I've seen plenty of devs forget to add unique titles to different pages which is frustrating for a user with multiple tabs going.
On SO the accepted answer for react-router looks like "create a custom Page component with title as a prop"[0]. At work I just ask folks to use react-helmet.
[0] https://stackoverflow.com/questions/52447828/is-there-a-way-...
> . You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync.
Why would I want to keep any state on the client? What in the history of the web (the whole idea being its someone elses computer) would make it a good idea to take away the one major selling point of the web? That no matter what, someone else has the state I need, and I never have to worry about losing that if something happens to my connection. It either went through or it didn't.
> The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up.
99% of SPAs break history related features in some way.
8 replies →
"A website has to go out of its way to mess this up."
I know it's supposed to be easier, but I keep seeing teams mess this up.
7 replies →
Client-side routing for page-oriented stuff is certainly not a solved problem: the basics, sure, but not actually doing it properly. There are some parts of the experience that it’s not possible to do perfectly because the web doesn’t expose the necessary primitives, and exceptionally few things go beyond the basics of just clobbering and resetting scroll position on back/forward. To do it properly, you need to restore all transient UI state (form field contents/state, scroll positions, focus, selection, media playback position; zoom level, probably not implementable; and there may be more, though I don’t include things like <details open> as transient state since that’s put into the DOM) on back/forwards, and I don’t know if I’ve seen anything actually do that. Then there’s the matter of helping accessibility tech to realise a page change has occurred, and I’m not sure of the state of the art on that, but last time I looked (some years ago) I think it was bogged down in unreliable heuristic land rather than actually being solved.
1) JS history handling is fragile. A single error can break navigation completely. There's no built-in loading indicator so sites are left with no feedback or have bloated progress bars. And nothing automatically solves for deep links if the app doesn't use routes for different views or relies on other events instead of hyperlinks.
2) Servers are very fast and assembling HTML is trivial. Browsers are optimized for downloading, parsing and rendering HTML as it streams in. Using JS to write HTML after making multiple network calls is objectively slower than a single network request that assembles everything on the server close to the datastore with minimal latency.
3) Every other language is faster and more capable on the server than JS, and all major web frameworks have modern component-based UI templating. Interactions with roundtrips are just fine, and some light JS can handle most other scenarios.
> "an actual application"
That's the only reason to use a SPA, not what you mentioned.
All of your benefits seem to come from using only rest APIs to drive to site. That alone can be done with any site, but SPA usually implies more.
> SPAs are great for a number of reasons:
> [...]
> 2. You need a beefier backend.
I don’t work on front-end and am trying to learn from this thread, so I may misunderstand, but that doesn’t look like an advantage to me. Doesn’t “beefier backend” imply “higher costs”?
Hi Simon, why'd you pull me in ;)
We recently went a rewrite of our frontend for https://www.crunchybridge.com from SPA to more "basic" request response app and couldn't be happier. Previously was SPA with React and we rebuilt from scratch with request/response using Node. In places we still leverage react components for re-usable frontend bits, but no more SPA and state management.
As you've mentioned in some of your other threads on this, the state management and sync between the API team and the front end team just caused velocity to slow down. It took longer to ship even the most basic things. While we want a clean and polished experience, the SPA approach didn't really accomplish any of that for us.
The rewrite was under 8 weeks of an app that had been built up over a couple years and we quickly recouped all that time in our new found velocity.
What server-side framework did you use for the request/response rewrite?
1 reply →
My knowledge is limited on the front end. May I know which Node framework do you use? Is it NextJS? If not, what do you think about using NextJS because I really consider it a better approach and want to use it at new projects.
1 reply →
Totally agree.
We built a product in ~5 months with real-time collaboration, extensive interactivity, Oauth, Stripe and Gmail integrations with a standard Ruby on Rails stack.
It's rock-solid, performant, dead-simple and extremely productive to work with.
Why're we throwing away years of learning to build unstable, complex and inaccessible applications?
>Why're we throwing away years of learning to build unstable, complex and inaccessible applications?
1. Smart people seek out difficult problems.
2. Difficult problems drive the creation of complex, niche tools, that bear cultural associations with the smart people who made and use them.
3. People who want to be smart seek out complex, niche tools.
10 replies →
Same experience here, in our case with Laravel. The project started as a Next.js SPA and after we needed to add authentication, translations and background jobs things became so crazy and so "custom" that we ditched it and in almost 2 weeks had everything built in a much more robust way with Laravel and Livewire + Alpine.
Because the majority of developers will gravitate towards tools that will give them the best employment opportunity, not necessarily the best tools for the job.
TL;DR Resume Driven Development
What approach did you take with real-time collaboration and interactivity? Is that part still rendered client-side?
One could argue rails is just doing a decent job of hiding a monstrous amount of unnecessary complexity from you for basic CRUD stuff. It’s good at this… until it isn’t. In the the whole ORM abstraction (not just in rails) is questionable.
The way most of us would handle authorization in something like rails is a leaky abstraction, especially when we’re usually backing onto postgresql which has very mature roles and permissions.
I always thought of the benefits of SPAs more as a separation-of-concerns thing. You can pretty effectively build a functional front-end web application and mock a set of back-end REST apis, while another team builds out a the back-end. There are absolutely tradeoffs, and being a good software engineer is about understanding where and when those tradeoffs apply.
That's definitely true at the organizational level, and it's an argument with some merits.
In practice though, I've seen this backfire. You end up with the frontend team blocked because the API they need isn't available yet, and then the backend team gets blocked because they shipped the API but they can't use it to deliver value because the frontend team don't have the capacity to build the interface for it!
My preference is to work on mixed-skll teams that can ship a feature independently of any other team. I really like the way Basecamp describe this in their handbook: https://github.com/basecamp/handbook/blob/master/how-we-work... - "In self-sufficient, independent teams".
2 replies →
Also allowing your mobile app to use the same API as the website.
That's not really unique to SPAs, right?
I don't know much about front-end development but I imagine you can create a front-end that is both not an SPA, and not server-rendered.
1 reply →
You can still do that with SSR solution, the mocking just moves one step down, instead of mocking a JSON request you mock a class or an interface.
Why not eliminate that organizational bottleneck by using a full-stack framework that lets one person do it all? DHH recently described Rails as a one-person framework [1]. I think Phoenix fits that category as well.
[1]: https://world.hey.com/dhh/the-one-person-framework-711e6318
When SPA started picking up steam, I thought it was an amazing development! We had gone from mainframes, to personal computers, and were back to mainframes and using our powerful machines as glorified dumb terminals. This way, we could have UI code running locally, and servers only handling state. Plus, less data to transfer!
Then the frameworks ballooned in size. What previously was seen as wasteful (rendering and sending HTML) started to seem pretty frugal in comparison to the multi megabyte pages. Not to mention that one could always send just page fragments.
Other than specialized apps, I think most single page applications are a mistake. Sure, some may benefit from a nice UI - say, I'm writing a 3D modeler. But most apps there are could just re-render pages. 'Refresh' is not much of a problem in an age where simple REST API calls are returning megabytes of JSON data...
I try to tell myself "don't get caught up in using a fancy frontend framework on this one," as I'm starting a new project, but I keep running into situations where my functionality would just work so much better.
As an example, I was writing a tool the other day to automate some things that have to do with quotes for my 9-to-5. Being able to add inline functionality in Django to select a customer within the quote page, or add / edit a new customer without having to leave that quote felt very 'hackish,' using the same jquery callback method used in Django Admin. My point is, this feels like very basic functionality, but turned into a whole other ordeal using traditional methods.
> Being able to add inline functionality in Django to select a customer within the quote page, or add / edit a new customer without having to leave that quote felt very 'hackish,' using the same jquery callback method used in Django Admin.
Agreed. For form based apps I don't like to fall back to SPAs (bloat, the desire of every dev to reinvent forms in their framework, client and server side validation duplication), and yet working with relational data they are easier.
It's one of those places where a half-way step would be so useful.
1 reply →
I initially thought part of the appeal was offloading the workload to the front end, where your processing power scales infinitely with each user's device. Maybe the benefit turned out to be negligible, I'm not really sure. Can server costs be reduced by offloading the work to the front end?
They absolutely can, if your workload is ideal for this situation, but unfortunately, the most "expensive" (in terms of time, money, computing power, you name it) part of giving a user information is typically the filtering and collation of that information from a much larger pool of information — almost always a pool of information that is far too big and too private to just send to the client to sort through locally.
Even in the most simple scenarios, you quickly find your limits. If you get data back, but it's paginated (and it almost always has to be, for basic reliability reasons as much as anything else), you can't be guaranteed to have the complete set of data in a given circumstance, so you can't perform operations like filtering, pivoting, or sorting that data locally. You have to ask the server to do this for you and wait for the response, just like we've had to in the past.
1 reply →
If you can actually offload substantial CPU cycles to the client, yes, you'll save server costs. But the SPA hype has led to a lot of SPAs that work like this:
> User clicks a tab. A request to server fetches the JSON data for the tab. Client renders it to HTML. User fills in some fields and clicks submit. A request to server sends the JSON form data and gets a JSON response code. Client shows a confirmation screen. ...
In this case, you're not saving much by templating JSON on the server instead of just templating HTML.
This was one of the appeals initially, and would certainly still be true if you were doing something very processor intensive that could securely be done on the client.
Languages/runtimes have gotten faster and more optimized, while hardware has continued to move forward. It's also far easier now to add more backend instances using orchestrators like k8s, so it's less of a big deal to have to add replicas.
> Can server costs be reduced by offloading the work to the front end?
I would say yes. One significant benefit of SPAs is that you can produce fairly complex applications without any server logic, only static hosting. The workload is essentially offloaded to the build process and the front-end. You still need to carefully consider the effect on e.g low powered and js-disabled devices ... but these are straightforward considerations.
>Not only do we not seem to be learning from our mistakes
That is a lot of good faith. What happens if they were not mistakes? But deliberate attempt to push Javascript as the one and only de facto approach to web development and Resume Driven Development?
I recently asked this [1],
I dont want to name names, but do any tech company actually apologise after their high evangelism to the world and industry and walk back 70% of their decision five years later?
And for some strange reason this mostly happens to Web Development in general.
[1] https://news.ycombinator.com/item?id=30451916
I know people for whom the traditional way of building a web app is completely foreign. I am curious how you would describe the concept and tools to someone who has never encountered them before outside an SPA architecture.
>....taking advantage of the supposed benefits of SPAs: there are no snazzy animations between states....
If that's the main benefit, let's hear it for MPAs. I want a website that's fast, responsive, clicky, sharp and to the point - not some soft-focus pastel cartoon movie. As the author says, that's fine for audio/video sites (and reasonable for other entertainment-focussed sites) - for information sites it just gets in the way (animated elements - especially persistent ones - are a terrible idea when trying to concentrate on textual content).
> not some soft-focus pastel cartoon movie.
For some reason, designers likes it no matter it makes sense or not, so it is what you get. The current designer trending is just a shit show, nuke the usability for nearly no benefits IMO.
It’s all about state management IMO. There are legitimate reasons to keep UI specific complex temporary state on the client that would be more complex (and slower) if the server needed to hold it. So an SPA or at least partial SPA in some situations does makes sense.
But it does tend to become a hammer for every screw over time…
> It's been so frustrating watch this play out over the past decade.
> I keep seeing projects that could have been written as a traditional multi-page application pick a SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs.*
Its been frustrating seeing the webplatform not play out, seeing so little growing in to SPAs, so little maturing.
Url-based routing is heavily under-represented, tackes on only by the one or two blokes who happened to have some memory of web architecture. This clairifies the architecture both internally & externally.
As bad a problem, single page apps being stuck, forever, at single-bundle apps is phenomenally sad. Splitting bundles into chunks as a manual development task is so hard, so bad. The goal of having web based modules almost made sense, almost happened, but we rafically underinvested in transport technology, cache-digest going undelivered. I continue to think js modules, with import maps- the key tech to making modules modular- is worth it, would help make our architecture so much better. There is mild extra time to first load, but worth it/small, & cached after.
Again we're damned though. Years too late to try & see how excellent it would be to have something like react cached & AOT compiled as from a cdn. Because now privacy concern freak-outs mean this huge advantage of only needing to pull & potentially compile a js module once are gone: site-partitioning rules. We could have had better architecture, been using the language not absurd bundlers, and enjoyed high cache bit rates for common libraries. SPAs just didnt care, never tried at all, we all (almost all) did a horrible job & took way way too long (over a decade) to make modules modular g usable. There was so much hope g promise & such abaurd non-delivery, on the module front, on app archtiecture.
HTTP3 and early-hints still have some promising hopes for accelerating our transports, making "just modules" a possibility & fast, without careful hand optimization. We could still do more to optimize bundles, have automated tools that analyze up front versus on-demand dependency bundles, build http bundles of these. But i hope eventually itcs mostly not super necessary to build webpackage (nor far worse, webpack) bundles.
SPAs still have great potential. More so, now that we finally have some support tech for modules forming.
I mean, of course the co-creator of Django would say this.
I wouldn't recommend newer generation of developers to build traditional web apps, let alone use jQuery.
I don't understand why people think we're still in the age of form submissions and blog posts - There has to be a good majority of us here that has worked on something complex that required SPAs here, no?
Not only would it be detrimental to a young developer's career to suggest avoiding SPAs in regards to hiring, but only limiting that developer to create blog post styled content is severely restraining.
Let them develop their blogs in SPAs, at least when they are needed to go into something a bit more complex, they at least have the foundational knowledge required to move towards that.
What you're suggesting is to learn two things, (one that is inevitably being phased out), and spend the mental effort to discern when to use either one, when the more beneficial alternative is to learn SPAs and just go with it.
No 18-25 year old is trying to make a Weblog where walls of text is the main content - Youtube shorts, instagram reels, tiktoks and all these bite sized content has done a great job at destroying that level of attention span.
They're going to be building something else, something quick and visual, something pleasing to the eyes - and more often than not, it's going to require a SPA.
> I don't understand why people think we're still in the age of form submissions and blog posts
Because we are.
> There has to be a good majority of us here that has worked on something complex that required SPAs here, no?
No. Because complex stuff doesn't require SPAs.
> There has to be a good majority of us here that has worked on something complex that required SPAs here, no?
You can still create a something complex without using any of the common SPA techniques, instead you can use things like Hotwire, Livewire, htmx instead.
2 replies →
I really view it as the opposite.
Prefer the writing of an SPA or serverless MPA.
If you consider that native desktop and mobile applications are siloed applications that coordinate with an API to achieve tasks - this is basically how SPAs or serverless MPAs work.
Part of the reason this is effective is because of the low cost nature of deploying applications like this.
For example; I can write a calorie counter that stores records in the client via indexeddb.
Given all the work is processed on the client, using an http server would be an unnecessary maintenance burden as it would simply server static files.
Rather than host the web application via a self managed http-server, I can just put my html files on S3 making hosting it free and unmanaged.
Should I decide I need to add user accounts and cloud storage - well I can then create a backend that exposes API endpoints to facilitate the tasks.
Those endpoints are then compatible with native applications, should I decide to write native mobile and desktop variations of my web application.
Furthermore, with Web Assembly expanding to offer the ability to write web applications using languages like C++, Rust, C#, Golang and the browser expanding access to OS subsystems like filesystem access - what we are seeing is that the browser is becoming a sandboxed UI toolkit, much like GTK or QT (except without native styling).
If there was anything that would empower Linux Desktops to be compatible with productivity software - it's progressive web applications.
Consider that Photoshop and Office are accessible on Linux via web today.
That's a lot of interfaces to create and maintain. The principle value of backend/MPA frameworks like Rails & Django is that they give you nearly all these interfaces for free in a neat package, which ends up being "good enough" for many use cases below Google-scale.
A calorie counter using IndexDB is a great example of something where an SPA is appropriate - like I said, "default to not writing an SPA, unless your project has specific, well understood requirements (e.g. you're building Figma) that make the SPA route a better fit".
I mainly work in the world of database-backed websites and applications, where going client-only without a backend isn't an option.
> Consider that Photoshop and Office are accessible on Linux via web today.
Never used Photoshop, but Office on the web still sucks compared even to native MS Office.
You're describing an actual client side (mobile or desktop) application made with web technology, not a web application. That's a fair use of SPA tech.
As soon as you need authentication, showing data across users, allowing visitors to see shared data, perform validation of inputs, send notifications when other user action happens, etc you're back in SPA hell.
1 reply →
>e.g. you're building Figma
i think what it comes down to is if you have to make a decision of "should i build an SPA?" the answer is no. the web is good at doing pages. if your app has pages, use the web's default page mechanism.
and i don't say this as a hater of single-page apps. i love webapps, and i think that building a webapp should be the default for most cases. there's a lot of apps that don't naturally break into a "page" metaphor, and all the technologies that are part of the single-page app concept are great for those cases.
figma is a perfect example, because there's no obvious division between what would be one page versus another. it's not a paginated website that has been built as an SPA, it's literally just one page that has a whole bunch of interactivity.
Don't don't do what I would do. The mistake is forgetting first principles. You don't do something good by focusing on what not to do (like don't be evil). Focus on what to do: KISS, YAGNI, etc.. even DRY is a far lower priority. Software, especially frontend and web are rampant with problems from operating as an echo chamber. Just consider what Ryan did with Deno and had to say criticizing his first project. Yet folks are still wildly supportive of the older technical decisions and go to great lengths to preserve those same mistakes.
Idk I don't think the problem is the SPA itself, it's bad design patterns that that make it terrible as you say.
I think really clean, performant SPAs can definitely be written and I think the overall experience of using a SPA can be much better than a multi-page site if the task at hand requires it.
There should be two parts of the web now really: * Traditional multi-page websites * SPAs that could have been a native app on the device, but are much more accessible in web form and without requiring an install
The alternative to SPAs is not 90s pages reloads. Nowadays you have livewire, hotwire, unpoly, htmx and several other modern solutions.
Speaking for myself, I find it much quicker and easier to build an SPA than a server rendered app. You seem to take the stance that server rendered is the default, normal way to architect and SPA requires justification for its aberrant departure from the norm.
SPA have lots of advantages: fewer languages to learn, easier to deploy, etc.
> SPA have lots of advantages: fewer languages to learn, easier to deploy, etc.
The two examples you give are only true if you don't have a backend at all. As soon as you have a backend, you're back to having to pick a backend language and deploy a backend server.
If your app doesn't need a backend, then I'd agree that an SPA is the way to go.
1 reply →
Example wealthfront.
All pages are SPAs. I mean, page A is SPA, page B is another SPA and page C is another SPA.
I suggest we go back to iframes
Totally agree.
That just sounds like poor performing developers to me. You don't need snazzy animations between states. Just not reloading the full page is a benefit.
We have a PHP app that doesn't reload the full page. We use jQuery's .load(), which has been around since 1.0:
https://api.jquery.com/load/
3 replies →
I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side Stimulus controllers, maybe a Turbo frame here and there and it works, but then you get to browser navigation and you're screwed, because none of this works if somebody were to submit the form, then navigate back. Now you have to implement lifecycle handling to account for navigation and once you're done, you've basically implemented a SPA, except it's broken into a mix of tightly-coupled Javascript, Ruby and ERB templates.
The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy.
To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts presentation and logic. The only state is its own. It does not handle an entire web app as a SPA, no Redux, prop drilling, it's just the idea of a reusable component as an HTML tag. Same with VueJS and all. If we restrict ourselves to that we're in the good path.
If there was already an HTML tag for your own specific problem, wouldn't you just use it in your traditional server-rendered app? A `<photo-upload url="/photos">` tag that does exactly what you want. Or a `<wizard pages=5 logic="com.domain">` tag. We should create just those components, either in React/VueJS/Whatever or in vanilla JS Web Components, and live with the rest as we used to.
We're basically saying that some parts of our apps are too difficult to mix and match state management, and we should offload all of the state to one of the two sides. In some rare apps indeed all of the state should be on the front end, but the use cases for that are just not as big as they're made out to be.
Exactly, the best approach seems to be where the app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA.
This approach eliminates the need for a client-side router, keeps any centralized page state small, and improves the SEO and bookmarkability of the app.
I have implemented this architecture in several projects, and it’s effective
30 replies →
Yes this is exactly right. What I’ve done in the past is use Django to return HTML with JSX mixed in, and have a super lightweight SPA frontend that just hydrates the react components on each load. You can also use form state to communicate back and forth with the server, where sending a response doesn’t refresh the entire page, just a react render diff. With this you get the best of both worlds where your backend can do the heavy lifting where everything it needs to decide on the view is all in one place, and your frontend just comprises of really really generic JS components.
I have a library I’ve been playing around with for 2 years now, I should package it up
1 reply →
Agree, we just add React components here and there to server-side rendered HTML and it works great for us. The issue is most companies want separate teams for front-end and back-end and each team wants clear separation of boundaries and responsibilities between them.
2 replies →
this seems to be approximately what https://htmx.org/ is trying to accomplish.
9 replies →
>The problem is the mixing and matching of state management
Routing (history management) is also a big problem (I'm assuming you weren't including that in your definition of "state" here).
Some would say, "but React, etc. have solved the routing issues", and that's perhaps the case. But what's difficult is wiring these routers up outside of a full React app. That is, if you truly want routing "solved", you generally have to go all React (or whatever) or just let the browser handle it in the traditional request/response sense. Sprinkling in just a bit of dynamic interaction wherein you want the history managed is purgatory.
And, on mobile, things get even more interesting. Consider the simple case of popping a modal (especially a slide-out). Many users will hit "back" on a mobile device, which they would reasonably expect to simply close the modal. But, if your app/page doesn't intercede to manage the history, the previous page is loaded instead.
2 replies →
> The problem is the mixing and matching of state management.
This. But IMHO the right solution is to make the back-end stateless and manage all client state on the client. Each request authenticates itself, and (if you're ReSTful about it) the back-end is simply a database connector/augmenter.
In this paradigm, the SPA is basically a desktop app that retrieves data from a server, built to run within a framework, which happens to be a web browser.
In case you're jumping to conclusions, know that I'm a late-comer to the SPA party, having resisted from its inception until about a year ago, for all the obvious reasons, including those bemoaned by the OP.
Why did I relent? SPA frameworks like React now handle pretty much all the heavy lifting for you. OP, you should check out React Router, which can render this post's examples irrelevant. I'm surprised that in 2022, someone writing to the web UI layer would bother to create code to manage the address bar when there are a thousand ways to not have to.
2 replies →
Any non-trivial app will require some frontend state eventually.
Exactly. I've been in the position various times where I'm embedding a JS app on a page to help the user do something highly interactive, usually creating/editing content. And then as it's expanding to integrate with other things on the site, I start to wish more of the site was in the JS-app side of things.
Sometimes I realize a SPA would have simply served the user better, and it doesn't necessarily take much to be in that predicament.
Too many people hate on SPAs by, presumably, just imagining static read-only content like blogs and news. Though I'm also a bit tired of "SPAs suck amirite, HN?"
Put the user first, consider the trade-offs that work towards that goal, and see what shakes out.
The other thing people who hate SPAs need to think about is that rendering blogs/news/static sites isn't a problem that developers really work on anymore. Businesses will just pick from the huge pile of existing CMSs or hosted solutions because it's easier and cheaper. So if you're wondering why all these developers are building SPAs, it's because we're building custom applications, not blogs.
I think the fundamental issue with SPAs is that it's building on multiple levels of technology that fundamentally weren't designed to support being a single page application.
The browser <-> multiple pages paradigm is pretty much how the web evolved, so SPA's just end up being one giant hack to get everything working.
UWP/WPF/any other desktop app framework demonstrates how easy developing a 'single page application' can be without all the cruft you have to add to make a SPA work because it's actually a sort-of-massive-workaround.
18 replies →
Setting limits for future features to keep the code base clean and manageable is something developers could be more vocal about.
Acquiescing to every demand product designers and management throw into the mix is what turns beautiful, easily-maintained codebases into nightmares.
What people are talking about here is writing web apps as a series of small, tightly-coupled spas who manage state within very specific parameters. And that's a great way to build software. Until someone comes in and asks you to draw in the state from one section into two other sections. You have the choice to say a) no and explain why, to b) create a clever "glue" that will be hard to maintain and difficult to explain, or to c) take the time to refactor the code into something more general and complex to allow for the feature on a more abstract level.
Guess which one almost always gets chosen.
The upshot is this: The solution to front-end complexity may not be a technical one, it may not require a new framework or library. It may be a shift in what we expect out of the web. We could always temper our expectations in order to keep our code clean.
2 replies →
> Put the user first, consider the trade-offs that work towards that goal, and see what shakes out.
In my experience, every single team I've been part of that was building an SPA was because they put the developer experience and desires first, even if in the mid/long term the dev experience ends up being worse as the project grows.
> Exactly. I've been in the position various times
This is why React is such a popular JavaScript framework of libraries.
I feel like most people that hate SPAs never have to deal with this type of thing, or even only have to work on the backend. They just don't get it. Of course, if you're using a SPA for a static website, you're also doing it wrong but that doesn't mean SPA itself is a bad thing.
I'm living proof that it is possible to simultaneously hate SPAs and understand why they are popular. I've built and worked on a number of them, I don't have a better alternative to recommend, and yet I still hate them because I think they are a clunky solution to the problem. We need something better, but I'm not smart enough to come up with what that should be.
2 replies →
"They just don't get it"
Believe me, I get it.
I dealt with building these kinds of features for a full decade before SPAs became fashionable.
Now I'm stuck here watching in frustration as people go all-in on SPAs because they didn't know how to solve these problems without them.
1 reply →
I agree. These people hating on SPAs are mostly not frontend developers. They're backend devs that think returning an HTML page is all you need to do. Modern websites are very complex.
2 replies →
This is what jQuery solved. It made it ridiculously easy (compared to not using jQuery at that time) to add a little sprinkle of progressively enhanced JavaScript to a page. It still works today (and you don't even need jQuery now, as browser standards have mostly caught up), but everyone seems to have forgotten how to do it!
teach me :)
This is my biggest gripe with the direction of Rails.
I completely understand the historic reasons for wanting to keep JS to a minimum and stay within ERB/Ruby, but the JS component-driven UI pattern feels like the correct front end architecture for most commercial projects these days, especially now with better JS tools like Svelte, which feels like rails for the front end to me.
I started playing around with InertiaJS recently and I absolutely fell in love with it. I was surprised to see how niche it still is because it's pretty much what I've dreamed what writing JS with Rails could be for the last 5 years.
Progressive enhancement was largely solved before SPAs became a thing. Its quite easy to enhance the client side incrementally, but SPAs started out as useful for full on Web apps and now everybody uses them by default for some reason.
I agree. I've been thinking about this lately, and have implemented something I think is interesting in Haskell.
https://github.com/seanhess/juniper
It's an implementation of Elm (imagine React if you're a JS dev), but all logic is executed on the server. State is passed back to the server whenever you choose to listen to an event. The view is then re-rendered and virtual dom diffed on the client. Non-interactive pages are just views. If you want them to be interactive, you add a Message an update function.
I used it on a client project and it was pretty delightful.
It probably isn't documented well enough yet to make total sense, but I think it's a step in the right direction.
> Then you add a couple of client-side Stimulus controllers, maybe a Turbo frame here and there and it works fine, but then you get to browser navigation and you're screwed, because none of this works out of the box if somebody were to submit the form, then navigate back. Now you have to implement lifecycle handling to account for navigation and once you're done, you've basically implemented a SPA, except it's broken into a mix of tightly-coupled Javascript, Ruby and ERB templates.
Where in this process did you need to start adding navigation via JS? Did that functionality really require JS, or was it implemented that way just because other parts are JS, and the trend was continued? Could you have used Stimulus controllers to manage functionality on the page itself, but when it came time to navigate to a new page, just done a basic browser redirect?
Saying that SPAs is a mistake doesn't mean that a strong dependence on JS or frameworks in a mistake. It just means that trying to make an entire site fit into a single page load introduces more costs than savings. You can still have pages controlled via React or Vue or Stimulus, but forgoing the router functionality.
In my own apps, I use Vue and VueX to control page behaviors, but each URL is its own Rails page. For example, I have a search page that uses Vue and VueX to asynchronously load, filter, and display search results. Clicking on a result is a basic browser redirect, taking you to the result's page, doing a full Rails page load, and again using Vue and VueX to manage any dynamic state (any static content is rendered via ERB files).
This has created a very clear and simple structure that allows each page to have any dynamic functionality it needs, but no complications from having to maintain navigation or browser history via JS. The browser already does that natively, and I get to spend my time working only on actual features--not recreating the browser's built-in functionality, or debugging my own take on it.
> Where in this process did you need to start adding navigation via JS? Did that functionality really require JS, or was it implemented that way just because other parts are JS, and the trend was continued? Could you have used Stimulus controllers to manage functionality on the page itself, but when it came time to navigate to a new page, just done a basic browser redirect?
In my specific example, the navigation itself didn't happen through JS, but you need to hook into navigation APIs to handle backing into a partially-filled form after submitting to rebuild the UI to reflect the state before the user hit submit. To make things even more fun, Turbo/Stimulus (sometimes?) breaks bfcache in Safari & Firefox so they behave different from Chrome.
Personally, I detest the vast majority of SPAs, especially the ones from Google, Facebook and Linkedin. Not even sure what they do to make them so horribly slow to use.
10 replies →
I think the best solution for this is just doing fullstack dev with SSR + partial hydration.
The issue is that, so far, we haven't figured out how to have a good fullstack DX.
Remix is probably one of the best attempts so far, but it still leans heavily towards being a very sophisticated renderer for the front end. The proof is you probably would not use Remix to create a 100% backend project with no front end. Same with SvelteKit or Next.
Until fullstack frameworks get more serious about the backend, we will be in this weird limbo.
In my current project I use Fastify as my main backend framework, and then use Svelte for SSR + hydration. I loose a lot of the frontend sophistication that SvelteKit brings to the table, but OTOH I have an amazing backend framework and total control and flexibility.
At the risk of a pile on, this is what jQuery was brilliant for. And frankly the native browser APIs have caught up enough that scenarios like what you want to achieve are simple to implement with just a script tag and a sprinkling of JS. I don't know what "Stimulus controllers" or "Turbo frames" are but they don't sound necessary.
Yes. Nobody should have to make a SPA to accomplish what JQuery did with sprinklings of JavaScript. JQuery was maligned because many people used it to make all XHR requests all over the place resulting in non-deterministic async behavior. JQuery was made to make adding small bits of JS easy and work in almost all browsers.
Bringing in React and turning that non-deterministic events firing all over the place greatly improved that situation, but this has become if someone needs JS, bring in SPA framework. This is in spite of the browser world getting much better. So just as JQuery was used to make SPAs to bad effect, SPA frameworks have been used to do minimal JS actions in a bad way.
Phoenix LiveView really does solve a lot of these problems.
It does and it has lots of work-alikes on other platforms (though some are not nearly as good). For almost any app that is inherently useless when not connected to the server, its a pretty good fit.
I was just going to say this sounds like a great example of something that Elixir, LiveView, plus maybe a little Alpine.js could handle...
Inertia [1] is an interesting project in this space that might solve some of your problems. I haven't used it, but I believe the general goal is to make it easy to "plug in" client-side frameworks (React, Vue, Svelte) into server-side views.
[1] https://inertiajs.com/
Yeah can someone fix this please. I'm experiencing the same thing with a rails app I'm currently building.
In all seriousness it feels like there must be an elegant way to do more responsive modern functions while keeping the core server rendering concept. It's 2022 after all. But no I don't know a good solution either.
HTMX lets you update the url with hx-push-url=“true”
This problem you described is exactly why SPAs will continue to dominate over the traditional server rendered websites.
Often when I see people arguing against SPAs, they are peddling trivial toy websites that don’t do much and don’t change much.
When you need to build a serious application on the web with quickly growing feature sets and complex state management, just use a SPA. It’s 2022.
The Basecamp guys created Hey which is a mail app not implemented as a SPA. It's probably the fastest mail app I've ever seen while delivering around 40kb of javascript.
If Hey is a toy app you then you must be working on some truly alien projects from the future or something.
1 reply →
SPAs dominate? Off the top of my head I can't think of a single SPA that I actually use regularly. I worked in a niche a few years back where they seemed common (configuration interfaces for embedded systems) but looking at my own habits and the sites that dominate in terms of web traffic, that's thankfully not something that has caught on generally.
I can sort of see the point if the "A" part of "SPA" actually applies to your product, but for the dominant players that doesn't seem to be the case.
for simple cases, you can use alpine.js, petite-vue etc. However, if you are considering "routing", then it is no longer a "little bit".
Did you have a look at https://htmx.org/ ? I think it solves the "just a tiny bit of interactivity on an MPA" kind of thing.
It was probably never too beautiful of a technique, but JSF does solve this problem splendidly. You basically have a view-flow besides the usual ones and it can act in many of the ways SPAs can.
Progress bars and previews are simply a matter of attaching an events to the http request and file input respectively.
When someone submits a form and navigates back, don't you just re-display the empty form?
If it needs to be a form bounded with the uploaded file (maybe as part of a wizard), then why not ask the server for it instead of storing client side state?
Maybe using Javascript without a SPA looks hard because you're trying to avoid storing state on the server as well as bypass native browser features.
I feel like react-rails (https://github.com/reactjs/react-rails) is basically perfect for this. You just make the photo upload its own react component and render it as normal from your rails view. You basically encapsulate the small bit of complex state into a component and it doesn't infect the rest of your app with SPA.
"I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. " I've started using django-unicorn lately and I'm hopeful that it may solve that problem for many use-cases.
Yes. The fitness of an architecture can be partially measured by looking at the cost of feature updates.
SPAs are a pattern that's been applied too broadly IMO, but it's going a bit far to call them a mistake. The aims of an SPA are pretty noble - the idea of essentially removing the network round trip when a user clicks on something is not a bad one. It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features.
They might not be actual requirements for a blog or a brochure site but it's not totally unreasonable for someone to want their website to work that way. The question is not whether or not an SPA is a good or a bad thing, but whether or not the cost (more code, more complexity, potentially a series of background requests after the initial page load) is worth paying in order to get the benefits.
When either an SPA or a multi-page site is done well most users can't tell which sort of site they're looking at. That should be the goal. Make stuff where the user forgets about the tech. Make a website that just works, that's fast enough for users not to think 'this is a bit slow', and that's coded in a way you can maintain and work on for a long time. If you get those things right then no one can reasonably criticise what you've made no matter how you've made it.
> the idea of essentially removing the network round trip when a user clicks on something is not a bad one.
Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete. With SSR, you can take care of everything with a single GET and a single POST no matter what. Images load in parallel of course, but those are non-critical.
I pretty strongly disagree with this.
The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly.
Who CARES if the SPA had to make 3xRTT in the background, if it can serve the next page up instantly because that data is already present and cached, it's a huge win.
The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not.
Still doesn't make an SPA the right fit for everything, but on bad networks, we get incredibly improvements in performance by rendering from cache, and occasionally handling cache updates in the background. User's fucking love it compared to waiting 2-5 seconds for every page load, even if they were JUST on the page a second ago.
45 replies →
> Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete.
This is largely solved with innovations like GraphQL (which you don't need a SPA to use). Pages that require multiple API calls can show their UIs progressively with appropriate loading indicators. For SPAs that have ~long sessions, it's arguably a good thing to have multiple API calls, because each can be cached individually: the fastest API call is the one you've already cached the response for. This is stuff we were doing at Mozilla in 2012, it's nothing new.
There's also nothing stopping you from making purpose-built endpoints that return all the information you need, too. Your proposed solution (SSR) is literally just that, but it returns HTML instead of structured data.
7 replies →
SSR isn't a one-size-fits-all solution. Blogs? Sure. Corporate marketing site? Absolutely. Wikipedia? What else.
A webapp where state can exist in various components is a perfect fit for SPA-s. Clicking a button in a widget and submitting the page with every other state, updating them and refreshing the page makes no sense.
SPA-s also help with separating frontend and backend development, they are different beasts. I know many backend devs who wouldn't touch frontend with a 10m pole and not because of JavaScript, but because they don't like design and UX in general.
People generally have a very bad estimate of just how engaged users are with their sites.
These people have lives and other shit to do besides spend all day in my web app. There’s a lot more accidental and exploratory clicks than you think and all of the background requests run even though the user is only on that page for half a second.
> Every AJAX request is an extra roundtrip
But not every AJAX request is blocking or necessary for the site to be usable.
If you can do it in a single GET/POST in an SSR, you can do it in a single XHR call in an SPA. There's no reason it has to be split up in separate XHR calls.
You just have to want to do it.
> When either an SPA or a multi-page site is done well most users can't tell which sort of site they're looking at.
And therein lies the problem. In the _vast_ majority of SPA sites I've been to, they are not "well done" by this definition. It is commonplace for things to break, like the back button as the quintessential example, because the developer(s) didn't spend the time to make sure things work correctly. With a non-SPA site, you generally have to go out of your way _to_ break those same things.
I like SPAs for some things (gmail being a good example), but they should not be the default implementation; there should be a _very_ strong argument before the SPA architecture is used.
You're just saying that bad software is bad. That's tautological.
Without SPA you have horrific 10page forms and the challenge of maintaining state as you go back and forth to make edits.
The hard part is managing state, and there is no way to avoid it if your product is not purely readonly. SPA is one strategy, and a pretty good one.
2 replies →
>It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features.
Yet the reality seems to be the opposite. If my connection is flaky (which it often is) then SPA's seem to fail more often and it isn't obvious what is going wrong. They don't seem to be faster either, long pauses between pages is common.
Right. The typical SPA doesn't recover at all from network failures, and you end up poking random buttons hoping that it will reach some sort of consistent state. Then you find that doesn't help and you need to refresh anyway, which is a reboot for the whole 'app'. So much for saving page loads.
I think it's exciting to see frameworks like https://remix.run/ trying to temper the disadvantages of SPAs by relying on web standards and server-side rendering. It's pretty cool that this is a JavaScript framework that can work without any (client-side) JavaScript.
Honest question: why is remix the primary example for this now? Next.js has been doing this for years and is really amazing. It seems like a ton of people had no idea this was even a problem they had until remix came along, and now remix is the savior.
Am I missing something with remix? Is there anything really novel that it does/introduces?
2 replies →
> they work if your connection is flaky,
Not saying it can't be done, but I haven't seen many SPAs that handles well flaky connections. Most stall with no indication to the end user, endless spinners or just broken in some random way.
Those are very good points - I wonder how the author would see, for example, Google Sheets implemented as not a SPA
This article seems to be directed at dealing with people that use SPAs to make more content focused websites, which quite obviously are better made with the browser.
However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all.
Even the example is a bit silly - SPAs that should be SPAs don't really have "links" per say, they will mostly have buttons, which will have a some sort of defined action. Perhaps these buttons will navigate to some other screen in the application, however, reloading all of the client side state every time one does this is absurd to say the least.
Finally, from a technical perspective, having a clear separation of concerns by having code talk to an API as opposed to HTML being rendered on the server, you remove a lot of complexity.
It feels like the people who write these articles don't actually remember how utterly shit the jQuery days were.
He was just unable to follow and understand the trend, and thinks that therefore the whole industry made a MISTAKE :D
It does feel like the tiring contrarianism type of heading as opposed to a particularly well thought out article.
In the same way I feel lesser able coders seem to dwell on shit-slinging against tech that is proven, works, and has solved innumerable problems when they bang on about how things were so much nicer with vanilla JS and how frameworks are lazy and slow or something, in order to cultivate a sense of superiority.
Any well made tech has it's place, skill and experience are about knowing which tech should be used where.
>> He was just unable to follow and understand the trend, and thinks that therefore the whole industry made a MISTAKE :D
That's not true, though. If you read [his next blog post](https://gomakethings.com/how-to-make-mpas-that-are-as-fast-a...) you'll see he has lots of experience with architecting an advanced multi-page application which works and behaves much like an SPA.
It makes his anti-SPA post kind of redundant and a bit hypocritical, but he clearly knows roughly what he's doing.
1 reply →
`
2 replies →
Yeah - I think a lot of it might be developers who don't understand that SPA and caching go pretty much hand in hand.
I'll admit that can make your life as a developer harder sometimes (to be blunt - caching is hard - full stop) but an SPA rendering from cache is basically a rocket compared to a server rendered page on a bad connection.
Absolutely no one enjoys waiting 2-5 seconds after clicking the back button to see a page they were just on, but that's the reality of a server rendered app on a bad connection. An SPA with good caching does, in fact, feel like a native app - in lots of good ways.
>no one enjoys waiting 2-5 seconds after clicking the back button to see a page they were just on, but that's the reality of a server rendered app on a bad connection
Wait, what. Don't basically all browsers nowadays keep previous pages in memory exactly not to do this?
If you read [his next blog post](https://gomakethings.com/how-to-make-mpas-that-are-as-fast-a...) you'll see he has lots of experience with architecting an advanced, cache-heavy multi-page application which works and behaves much like you describe.
1 reply →
>Absolutely no one enjoys waiting 2-5 seconds after clicking the back button to see a page they were just on
This doesn't happen because the browser caches the last page.
> However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all.
in the same way how re-rendering the screen in a 3D game for every frame does it. Or how you buy a new pair of jeans instead of meticulously learning how to patch the old ones. It solves a lot of problems even if it sounds suboptimal. It was the standard practice when computers and networks were much much much slower, therefore it cannot be that bad.
I think SPA and their entire ecosystem give some sense of optimality to purists which is probably shortsighted and wrong.
jQuery days were bad?
there were certainly people that committed war crimes with jQuery. Just like every other framework in existence. I yearn to return, honestly.
Nah, they weren't a mistake, at least not in isolation. Much of modern software development is a mistake, generally speaking. When you look at it that way, SPAs only failed in the sense that Object-oriented Programming failed, as well as the failure of various design patterns, microservices, write-once-run-anywhere, test-driven development, decentralization... I can go on and on with the number of engineering and computer-sciencey crap that never really lived up to its promises.
SPAs only suck as much as we suck. Just admit that SPAs are like any other tool, and if we're going to swing back to apologizing for goto-statements (something I don't necessarily disagree with) then we can't at the same time act like SPAs are a mistake in and of themselves. We collectively continue making mistakes and instead of owning up to our collective lack of craftsmanship, we are blaming the tool.
Only when we shed the mindset that informs us that computer "science" is actual science might we then be in enough touch with reality that we seriously impose some standards upon ourselves to address our clumsiness.
> SPAs only suck as much as we suck.
We suck pretty bad. SPAs are often the default because that is what the framework dictates and nobody trusts a JavaScript developer to delivery any kind of quality product without some epic massive framework, including ourselves. This is the standard for hiring, performance, and delivery and nobody dares deviate. If its not an NPM package written by an anonymous stranger or an API on the framework its not an option. We don't trust each other and management doesn't trust us, so let the framework dictate our every decision.
why do you think TDD failed :(
Doesn't every other science field work pretty much the same way though? We make mistakes, we iterate, we make new and better mistakes. It may be too obvious in software cause it's easy to create stuff and iterate very fast cause there aren't so many natural constraints. Someone may even argue that this is what makes software also an art.
TDD, or rather the effort behind TDD, failed because its proponents couldn't help but preach it as a cornucopia of solutions with the insistence that it's appropriate for every circumstance. When you are familiar with the domain of a problem, TDD makes a lot of sense. For the project I'm working on now where I'm effectively learning at just about every step of the way, and said project is intended for very few users, it's highly questionable if I could have benefited from TDD. Even when I'm not doing something unusual, TDD doesn't always make sense.
Any research that currently exists around TDD is of poor quality and proves little, but TDD fanatics (not sure how many of them exist anymore though) speak like there's objective evidence in their favor. And some call this sort of thing "science"?
By the way, when I mentioned science, I was specifically referring to the concept of "computer science", of which there has been very little actual use of the scientific method in our lifetimes. Computer science is of course a legitimate area of study; if our heads are still so in the clouds that we are still calling it a "science" then it's no surprise that we're continually losing touch with the very technologies we create.
TDD also shot itself in the foot with this (IMO toxic) insistence that the tests are the documentation, which is a nice principle to keep in mind, but I've never seen it come close to replacing actual documentation. A simple comment block describing the why of a function is always better than scrolling through tests and reconciling inconsistencies with the mocks that were used. And yeah, I know that TDDing isn't really about "mocking", but let's face it [...].
Perhaps the worst thing of all is that TDD is founded on a somewhat dishonest implicit premise, which is that if you aren't TDD'ing then one must be either not writing enough tests or are writing inferior code because one is writing tests after development. TDD fanatics, in particular those freshly inducted into the cult, often think it's either TDD or nothing, and if you're not TDD'ing one particular part of an app then you're not following "standards". Maybe TDD is fine as a form of guard rails when you're a junior developer, but by the time you're a high mid-level and in touch with reality then you're going to intuit whether a unit of work will actually benefit from TDD.
TDD isn't bad at all in terms of its mechanics. It's a great idea, and I've used it many times. In fact I even TDD'd an entire web app that handled payment processing from start to finish. The part about TDD that "failed" was this belief that it is actually a generalized solution that needs to be applied everywhere, which lead to it both being misapplied as well as dismissed when it becomes apparent that those promises of better and easier code/process/readability often don't magically manifest.
This is really the story behind just about every failed idea related to our field, not just TDD. SPAs were supposed to make pages snappier because it meant server responses to different user actions would require fewer bytes and no page refreshes. Instead of viewing SPAs as a tool with a purpose, people had to treat SPAs as the end-all-be-all of frontend development and a way to do everything, and now the world is stuck with many SPAs that are likely worse than if they were done as regular webpages.
REST API's (literally, "Representational State Transfer", ReST) are a very nice match with SPA's, because now the browser is the sole source of truth for application state (and the server only has to produce some JSON data instead of entire HTML pages).
Literally the entire point of REST is that you don't have to maintain server-side sessions, and you shouldn't. This also has benefits for scalable applications, in that you can transfer your running application to a cluster of servers on the other side of the world, and it'll still keep working.
The trust boundary between the front and back ends can be a huge boon to security as well, and some things are literally impossible to do with a multi-page app, and you can still maintain URL parity with new actions in your page.
That's why SPAs were, and are, great!
That doesn't mean everything should be an SPA! A photo, news, blog, or recipe website might be better laid out as a separate page for each individual item. However, there are tons of other types of real applications that can only be built as an SPA.
Are they unwieldy, sometimes hard-to-code and maintain, and sometimes result in a poorer experience? Yes, but that can also be true of a multi-page app, especially if you're trying to shoehorn an SPA experience into a multi-page app and want to maintain the same user experience as a user moves around within the app.
A multi-page "app" isn't really an app anymore; it's a server-side app that is producing multiple pages. A single page app literally is running in the browser and only sending a bit of data back and forth with each user interaction. It's just a completely different model.
I don't disagree with most points here, but I did chuckle at this one:
> YouTube is a great example. Being able to keep a video playing while you explore other videos is fantastic.
I hate that (mis)feature. When I click something else, my attention is on the new thing. Having to go find the little still-playing video window to close it is a hassle.
As a counter: I love it. It allows me to add videos to a queue without having to build a playlist beforehand. And halfway through the queue, I can add more without having to navigate away.
Yeah I like it as well, but there should probably be an option to disable for those who don't like it.
And if you don't, you're probably going to open in a new tab. Too many webapps are designed with complete disregards to the fact that browsers have tabs.
Some like it some hate it. I hate it too but generally I like simpler things. I wish we could opt out of some features so everybody would be happy.
YouTube is awfully slow - back when I used it I dreaded accidentally mis-clicking on something because it would initiate 3 seconds of stuttering and shit moving around everywhere while their terrible SPA (poorly) reloaded the page.
Nowadays I use Invidious which is a proxy that renders good old server-side-rendered pages and it manages to be faster despite being a proxy.
agreed. i dont think youtube needs to be an SPA and simple pages work better. For comparison: porn sites.
I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6). So why would I ever do an SPA again if it were up to me? I would use https://github.com/jfyne/live which is inspired by Phoenix LiveViews. This is my professional opinion, having many years of experience in both kinds of web apps.
When I was reimplementing “reset state” for a logo click I knew it should have been serverside rendering.
Template based UI programming is like going back to the year 2007. Your views should be reactive. Elm, Flutter, React, Et Cetera understand this. Having a function that takes data and returns a view is much better.
Isn't a template essentially a "function" that takes data and returns a view? I don't have much experience with UI programming but I don't really see the conceptual difference.
7 replies →
We can debate syntax but a Go or Python based template language is not conceptually any different to JSX based syntax. Both are essentially functions that take some input data and return the data formatted in HTML.
Sure, if you implement a trivial single-task app (one tiny feature of a Calendar app) with an unfriendly UI, you don't need an SPA. That doesn't prove anything.
It doesn't "prove" anything, but it's a data point, and quite a lot more thorough than your dismissive comment. If you want to make a well supported counter-argument, please be my guest. It's easy to criticize, it's harder to make a thoughtful argument.
I kind of have to agree here. There are very few times I've ever worked on a SPA and felt like throwing it all away and using the alternative.
The last time I thought about this, which admittedly was many years ago, the alternatives that I knew about were: server-side frameworks like ASP.NET MVC Razor, PHP, RoR templates, Node.js EJS, Jade (now Pug), and static HTML.
Nowadays, you can create extremely elegant and performant SPAs with tools like Next.js and Remix, so I really couldn't agree less to the OP.
This reads like a Reddit comment. Let's try to be better than that here.
Harsh. Dude ported liveview, this isn’t amateur level work.
It’s a useful brush but you can’t use it to paint everything.
1 reply →
You're being very rude and dismissive. I may well have more SPA experience than you do. Don't make assumptions about people and then use that to dismiss something they say - we're better than that here on HN.
1 reply →
This is rude
Instead why don't you let us know why you think that position is incorrect rather than resorting to reddit-tier insults?
1 reply →
wow you must be incredibly smart and discerning, being able to confidently make assumptions and judgments about people's lives and background based on one or two HN comments, and then dismiss them as an ignorant and incapable fool.
I have worked as an engineer on products in a lot of different domains in my career including:
- edtech
- real estate
- HR/payroll software
and every single project I've worked on had enough complex state to benefit from using a SPA.
I've also worked on one complex web project run by someone dogmatically against client-logic, and it was absolute hell. The codebase was full of janky hacks to approximate the same complex session state and full interactivity that a SPA provides trivially.
This whole thread seems like a huge echo chamber of people who seem annoyed that FE development is getting too complex.
But do you all really think that the entire industry is so disconnected from its needs, and the entire community of FE engineers just have their heads in the sand about the requirements of working in their domain of expertise?
And to everyone saying SPAs are sometimes useful in very rare occasions, what web apps do you use regularly? Gmail? Jira? Slack? LinkedIn? Figma? Notion? Docs? Dropbox? Airbnb? Netflix? Airtable? ...
How many of these use javascript to do the heavy lifting on the client?
In your experience how often did the complex state have to be modelled on the backend as well as the frontend, to provide validation of submitted data?
And for personal interest, how did you handle streaming in updates and edits from multiple people, and stopping people from editing eg the same real estate listing at the same time? I know it can be done but I find it easier with server round trips for every request.
As for your question about persisted data, yeah it definitely needs to be modeled on the backend, right? How much modeling should be done on the FE is a good question. This question is sort of why GraphQL exists. GraphQL provides a contract between the backend and the frontend about what the data sent between the two needs to look like. Apollo provides a pretty good and easy-to-use GraphQL implementation in my experience.
As for real-time updates, this hasn't been a real concern in most of my professional work. If I needed to support this, I think what I would do is:
1.) Define a clear set of actions for everything that needs to be streamed to users real-time (IE, I wouldn't try to stream the full state tree itself, this is where conflicts would arise)
2.) Determine how each action mutates the graphql tree
3.) Add a process that watches for these actions at the top of the React tree and manipulate the GraphQL cache as necessary in response to the incoming actions, (coming from a WebSocket connection, for example).
If you stream the actions, you may be able to resolve simultaneous edits naturally. Or, if you really want to block simultaneous edits, I think you should 1.) definitely ensure the edit is really blocked on the backend, and 2.) stream on "disable" action to the user via webso
State is a pretty loaded word, but what I meant more specifically is complex application state, and by that I mean the ephemeral state that manages a user's usage of the application.
For example, in the real estate use case, there may be, all on the same page:
- a table of listings and grid of listings that can be toggled between
- a map that can be displayed alongside the table with all the listings plotted
- dynamic updates on the map that highlight listing when it is hovered on the table
- a detail modal that displays whenever any listing on the table or map is clicked
- pagination that can controlled from either the modal or the table
- selection state for each row on the table and a bulk action bar that conditionally appears when the row is selected.
- filters and search that need to work quickly and not disrupt the user experience
None of these things are particularly unusual or groundbreaking, but trying to control all these stuff via server-rendering or jquery would be a huge mess and potentially a jarring UX.
These are good concerns. IME it's important to be able to share code and schemas & domain data manipulation code between BE and FE like you can do eg with Clojure + ClojureScript.
Every week someone posts some half-baked blog ramble about how SPAs are bad (except for media sites!).
How about this - I am just as or more efficient working with SPA frameworks such as React as working with server-side-rendering. I have invested in a skill and toolset that can deliver any sort of website or web application from blogs to Youtube to Figma. I don't see any reason I would invest in learning an MPA framework that is only good for a subset of that.
If you are delivering content-only website with simple forms you might as well just use a CMS and call it a day.
Why are wood shops loaded to the rafters with tools? Because there is no Golden Hammer, only people who think they’ve found one.
You’re saying you’re doubling down on a single solution, which is probably not actually true, but you are surrounded by younger developers who will copy what you seem to be doing rather than what you’re actually doing.
All of these unresolved arguments are about team dynamics, not technology, which is why they never get resolved. Because we talk about our experiences or “objective” things like logic.
> All of these unresolved arguments are about team dynamics, not technology
No, it's definitely about technology. Let me simplify this for you. Technology A can do thing 1 very well, and thing 2 decently. Technology B can do thing 2 well, but can't do thing 1 at all.
In reality, people who only do technology B claim technology B is necessary to do thing 2 and go to great extents to write blog posts claiming such, while people who only do technology A get on with doing things 1 and 2 without feeling the need to rant.
1 reply →
I, as a user, hate them with passion.
I regularly stumble upon stale data in SPAs, even in big names' like Linkedin, Jira, Github, etc. I wonder how the hell corporations with thousands of engineers, lot of them being brightest engineers in the world, can't make proper SPA.
Can we just go back to server side rendered pages, with a bit of JS sprinkled in, please.
Github is not an SPA. They use the middle road of dynamically loading HTML snippets, using webcomponents, and lightweight JavaScript. Any problems you see with most of Github's interface should be chalked up to server-rendered pages with sprinkled JS.
I dread using GitHub's fake client-side navigation. For me it's always faster to just load a link "for real" rather than wait for their terrible JS to pretend to load the link for me.
Interesting that you use Github as an example, when Github is not an SPA. So basically just admitting these problems aren't necessarily inherent to SPA's, but to the developers/teams building them. They may just be a bit harder to get right in SPA's.
> Github
GitHub is a great example of a site that would benefit from actually being an SPA, imo. It is server rendered pages with JS sprinkled in, and you can easily end up in the situation where parts that live update fall out of sync with parts that don't. For example, being able to see that an issue is closed while the badge on the Issues tab still says you have one open.
I share your general sentiment over the state of them though. It's not actually that hard to avoid breaking navigation buttons, having links open in new tabs correctly etc, so I don't know how it gets screwed up so much.
This ship has sailed. SPAs shortcomings are widely known and addressed by frameworks.
Whatever MPA alternative you bring will need to address other shortcomings. There will always be something quirky due to building applications in a technology designed for hypertext documents.
Many of those shortcomings were solved 15-20 years ago. Far too many SPAs are little more than old school request and response, GET and POSTs. I've literally had to drop into the dev tools console just to push through a page with 7 sets of radio buttons because Angular broke in some spectacular way, on a page that is and should be boring (prescription refill page).
I have in my life used a couple of SPAs where I thought "Man, this works really smoothly and quickly!" Like there have seriously been a couple really good ones.
They absolutely can be done right, I've built one I think is done right. I've built a couple. I don't think the average team has it in them to build a good SPA.
The majority of SPAs are user hostile hot garbage.
The 95% of other SPAs were full of minor frustrations that could have been easily avoided by not being an SPA including
Like don't get me wrong, you can do a lot of this junk in a non-SPA but the failure state is almost always better.
> Inability to run the site in multiple tabs. State is entirely local so state gets broken easily.
I have seen this more for sites where a TON of state is stored in the backend, the site expects the user to have 1 tab that is kept in sync with what the server thinks that user session is doing.
Heck I have seen sites that throw up errors asking me not to open multiple tabs.
I have also seen sites where if I have Tab 1 on Page A, and I open Tab 2 to Page B, then go back to Tab 1 and navigate to Page C, if I go to tab 2 and try to navigate anywhere, it just goes to Page C.
Fun times when the server has too much state.
I'm not clear why the author thinks that "media sites, really" are the only SPA use case. Have they never used webmail (like GMail), map apps (like Google Maps), or social networks (like Twitter)?
I give you Google Maps is a perfect example maybe for SPA.
But Gmail? Why do we need SPA for that? Receiving emails notifications could be websockets and clicking on email should go to a new page displaying the email. I dont know if the initial gmail was SPA or not, but the current version is very very slow and consumes a lot of memory to display some emails that worked even in terminal clients, remember Pine?
The same for twitter? I anyhow have to press "Load 39 new tweets" to load the new ones so why is it a SPA? Just for that notification? If you would give me a twitter client where I need to refresh the page to load new tweets but works faster and consumes less memory I will happy use that.
Do you want a full page reload just because you deleted an email? Or flagged it? Or marked it as spam? Or even do you want your webmail in frames just to have a reader pane? Webmail is a great SPA candidate.
1 reply →
You keep making this ad hominem attack without presenting any evidence.
You’re really enjoying that brush today.
Don't be an asshole.
Anyone can choose the tech stack, patterns, or whatever that he likes. But developers enjoy being absolutists, and deem something they don't like as a MISTAKE, or would tell you that the way they think is the ONLY way to think.
You do your app the way you want depending on the Ux you want to provide, on the tech you enjoy implementing, on the patterns you like to follow.
> Anyone can choose the tech stack, patterns, or whatever that he likes
Maybe for personal projects, but 99% of us have to use the tech stack, pattern or whatever of our employer that was decided on (presumedly by some consensus at some point in the past). Publicly pointing out the flaws in what might have made sense then but might not make sense now is a Good Thing so that those flaws might be taken into consideration in the next round of consensus building.
I don’t understand what sort of cave trolls think I get to decide for me. Even as a lead I am making decisions based on the situation on the ground and those are informed by what people are comfortable with and what I can help them get comfortable with. It’s a team activity.
But every conversation has someone spouting off like these are experiments in a Petri dish. Petri dish projects don’t matter. Haven’t for a long time.
That's what interview processes are for. And if the consensus goes for a stack you don't like, let's say for example for doing and SPA, then maybe it's not a mistake as stated in the article. Unless you guys think that any engineer that makes choices different than yours is incompetent.
Don't work for a company running a tech stack you don't like.
Don't limit this to SPAs, include the Jamstack, which has all the same problems, and the false promise that if you can statically render a few pages or parts of pages and put them on a CDN, everything will be fast. It won't, because to load dynamic content, you still have to do a lot of work and talk to a (gasp) centralized API over the internet.
SPAs and Jamstack favor developer convenience over end user experience. Let's have fewer loading spinners, and more SSR-by-default for pages with dynamic content.
But there's a cost savings, right? JSON requests for just the data necessary vs. sending the whole HTML page each time.
Personally I'd prefer to develop a website the old-fashioned way, but I see that the bandwidth savings is a major point for SPAs and if you're running a business...
SSR by default, and then if you want, client side hydration and navigation so subsequent page loads happen in the client. However, the size difference between an HTML response and a JSON response is negligible, and HTML responses don't have to wait for Javascript to download, parse, execute, kick off off a request over the internet, get the data back, execute the result, and update the DOM. Browsers have literally decades of optimization to show HTML to users as fast as possible, and doing this in Javascript is fundamentally slower.
> developer convenience
This is really, really important though.
Am I the only one preferring good old-school, "boring" stacks that I can run entirely on my own machine if needed and understand the sequence of operations as opposed to relying on dozens of third-parties, services, APIs, etc just to do what a stupid PHP script on shared hosting could do 20 years ago? I don't consider the modern complexity as convenience.
1 reply →
One thing that I found working in a bigger organisation is just how well React encapsulates Design Systems. You can have a dedicated team of talented frontend engineers that builds a really solid design system, and then other folks building the actual user facing bits can use them, and everything will be nice and consistent across all the various apps.
For example look at how well this has been going for Uber.
Now this is certainly possible, and even relatively easy to do in server side frameworks, but as others have stated, its harder to make sure it works nice in all the various edge cases and visual flair that is required for end users, and keeping it all consistent and upgradable across the board.
React (and I'd wager other component based approaches) shine there - its low level enough that you can implement anything with it, but still allow you to build complex things fast. And then are free to implement the actual business logic of the backend with the technologies of your choice. Even better various teams can do that in their preferred language, without the end user being affected by the difference.
Throw in react native to make the styles transferrable to mobile apps and you have the perfect sweet spot for largish tech companies. And since those tend to be the more vocal ones, we get this, in my opinion largely deserved desire to build SPAs.
Smaller teams / startups of coarse don't have those incentives, so they will understandably not have the same cost / benefit analysis.
The problem with SPAs is that they have been misused and overused, at least in Italy. Tons of projects built with SPA in which we have to re-implement basic browser features like the back button, just because project manager has no idea of how this technology works. I've worked on at least 4 projects which could be written in Nextjs in half of the time
Hate to break it to you but Nextjs is for building SPAs.
This is way oversimplified. You can build a completely static website with NextJS. What I love about it is that you can do everything : SSR by default, SSG as an option, and awesome features like ISR etc.
However, the way NextJS implements SSR is really weird right now : if you use their <Link/> component, the pages props are actually fetched with an XHR request, then the page is rendered. I don't know why. It does feel like an SPA in the end.
Next.js recommends delivering static assets by default and is geared towards that.
> We recommend using Static Generation (with and without data) whenever possible because your page can be built once and served by CDN, which makes it much faster than having a server render the page on every request.
If you need dynamic content, they recommend server-side rendering, and lastly client-side rendering only if the page is unaffected by SEO and requires a lot of in-page updates.
https://nextjs.org/learn/basics/data-fetching/two-forms
I was going to say.... ironically NextJS is just an additional layer for creating static-rendered sites over an SPA framework. We have come full circle.
1 reply →
They don't know about frameworks in Italy?
I think SPAs were the best solution we had at the time and I enjoyed trying to build good UX with them. Yes, React started fresh and ended up driving me back to Rails because I'm just not smart enough. That said, I am really excited about Django w/HTMX, Rails w/ Hotwire, and Next and Remix with React. Particularly Remix.
I can get good at a lot of things, but most of them (including half the ones I’m good at) really just aren’t worth my time and energy.
Ain’t nobody got time for that is more often closer to the mark. But anything that requires hypervigilance is eventually going to make you look dumb. Just don’t let them put “human error” on the RCA. Yes, You screwed up, but We put you there in the first place.
It should be obvious why SPA/PWA frameworks were developed by the likes of facebook and Google: Offloading their content rendering to the client.
Instead of Google/Facebook CPU cycles being spent on rendering their content, it's now the client devices, while the Google/Facebook infrastructure is "just" serving the data.
First lead dev offered me advice for the rest of my career.
Most of what you are going to see people argue about are cyclical fads. A pendulum. We try A and it doesn’t work. So we try !A. And when people forget why we stopped doing A someone tries it again over and over.
How are things different this time should be your second question. Your first question is what is the middle ground? Boolean logic falls on its face in the real world. If 1 is bad that doesn’t mean 200 is better. If 200 was bad the solution is not 1. The best answer is probably three.
So I ran across a shit ton of your comments in this thread, like how you think, you should hit me up if you're ever hiring.
I'm sure the data that FB and Google are delivering is far more expensive than rendering HTML would be. I am skeptical that server side rendering was a big enough bottleneck for them for that to be their primary motivation. I'm also skeptical that SPA frameworks would have been widely adopted by developers all over the world if they were just some conspiratorial plot by tech companies to save on CPU cycles.
This is completely inaccurate. Every millisecond of load time affects conversion so much that they would trade huge amounts of CPU to speed up a page load.
Until you have a monopoly, at which point conversion rates don't matter or rather don't change despite terrible UX.
In my humble opinion, SPAs are not the fundamental mistakes. SPAs are applications. There's nothing wrong with having applications. The mistake was not maintaining a distinction between applications and content. The difference between a static document, a collection of hypertext documents, and a web application is very blurry. If it were less blurry, there would have been things we would have been able to do that we are not currently able to do.
SPAs were a good solution when page load/rendering times were longer. However with todays internet speeds, edge caching, HTTP3/Quic as well as todays chips and browser implementations page reloads are barely noticeable so you get all the goodness the browser gives you out of the box creating MPAs.
There are still some examples were SPAs are useful such as replacing complex desktop applications but 95% of web apps don't need it.
It was a big day for me when I realized the CSS perf tool had been removed from my browser because the clock resolution was no longer sufficient to make it work. Everything was <1ms.
Bloom filters for CSS were a huge deal, and the CSS load and apply times are one of several things SPAs were trying to amortize.
It's posts like these where I can feel the age of HN.
For many developers, especially in startups, SPAs are all they've ever known.
Now, I'm relatively young, but I'm old enough to know monolithic django before moving onto angular then onto react, and it is quite staggering what I'm capable of doing in SPAs as opposed to traditional web pages.
You mentioned Soundcloud and Youtube, but you'd be lying to yourself if you think the list comes even close to even stopping there.
How about fantasy drafts in DraftKings, Sleeper, or FanDuel?
How about chess like chess.com or lichess?
How about collab tools like Trello, Monday, or Asana?
I wouldn't even dream of building these types of applications in a traditional web app
The level of interactivity that is capable within SPAs makes applications like these seamless and snappy, and overall feel-good for the user.
What a total nonsense. I’m quite old in our industry standards and remember all this ”great and easy” way of working with backend templates and struggle to find it much easier than working with SPAs.
I also thank computer gods for SPAs each time I click in Github and wait for it junky slow interface to reload whole page.
Please save us from likes of ROR etc. that is slow and has awful user experience. Just try to use Basecamp. It’s so ugly, slow and free of any features at all that your eyes will bleed.
I personally am totally for ditching html and css from the browsers and just leave JS with some nice APIs (without DOM nonsense) and let us work with web apps like we would with desktop apps.
Web is not for documents any more. Just get over it.
"I personally am totally for ditching html and css from the browsers and just leave JS with some nice APIs (without DOM nonsense) and let us work with web apps like we would with desktop apps."
Have you tried using React Native For Web? The name is so ironic it almost seems like a joke, but I think the rationale is to simplify things as you are suggesting
Yeah it’s a nice idea, but it still has to mess with DOM and css in the end.
I just think that web apps are not web pages. And all this struggle with css quirks and all this power wasted on parsing DOM is not really needed. I know that if what you need is a blog, then html with css is enough. But building interactive apps with backend templates rendering ends up like Github (slow and with bad user experience), or it requires a lot of crazy jQuery hackery we have been doing in the old days. And I’ll pick building a React app any time I have a choice like that.
SPAs are great when you're actually making an app.
It's a little less great when you're just putting a browser in the browser so they can browse while they browse.
Even then sometimes it works when the content is more app like and you don't want to set up a bunch of js and websocket connections with every load.
Maybe we need some new easy to use APIs for JS that persists it's state between pages.
>SPA's suck! Here's my ad-hoc replacement architecture that you should totally just use!
Really though, this is a dead horse. SPAs are just a tradeoff like everything else in engineering. We trade the simplicity of a monolith for the ability to parcel out work efficiently between large disparate teams of frontend/backend engineers.
Most of that navigation stuff is long-solved - e.g. Angular's router will do a lot of that.
If you want to do a SPA without a modern library, then yes you will need to reimplement a bunch of stuff. But who would start from scratch? Unless you are doing something incredibly niche or tiny-tiny-tiny, just use Angular or React or whatever and don't worry about the minutiae.
Of course there will now be people screaming at their screen about how this attitude is everything that is wrong with the modern web etc. I am sure they'll get over it one day, or just go use gopher/Gemini if not.
I'm building business application at my job. Users navigate (filter, configure, visualize 3D models) huge lists of data (bill of material, product structures). SPAs are heaven sent. Delegating every filter or configuration action to the server would be insane. Same with server side paging. Another example is 3D viewing: When selecting a part in the viewer detailed data should be displayed. A round trip to the server for this? No, thank you.
I have to heavily disagree with this post. Which by the way lacks any in depth arguments.
A SPA is an Application and not a Web Site. With a SPA you can replace classical desktop or mobile applications, for example Gmail, Spotify or maybe Dropbox.
SPAs are good for that, because you just have to develop it once, instead of 5 or 10 times for all platforms.
SPAs are bad for traditional websites that deliver content.
I can't agree with this. That list of 9 complexities are well abstracted by the most common library or framework for SPAs. Having done a lot of SPA development I can say routing is not anywhere up on the list of trouble spots you do encounter. State management is another story.
When I was a FE developer building single page apps, I would hear these arguments and say "you just don't get it, man, SPAs are the future". Now that I don't get paid to work on SPAs, these and other downsides come into very stark relief, and it's the advantages which seem more dubious to me. I doubt I'll ever touch an SPA again, and I'm not mad about that.
Indeed: "It is difficult to get a man to understand something when his salary depends upon his not understanding it"
Everytime I see one of these binary "XYZ is good/bad" posts I come away thinking that either I don't know what I'm doing, or the author doesn't.
Having built relatively simple Django web applications, and having built and managed building complex SPAs with Angular/React and GraphQL backends, I have a hard time thinking of when I would ever willingly grab for serving up dynamic HTML ever again.
The mixing of concerns with something like Django vs just having a native JS application loaded and running in the browser pulling in data as needed once loaded is a world of difference.
Using straw man examples of people using a technology badly to claim the technology itself is a mistake is silly.
There's literal annals of examples of poor memory management in compiled software causing massive issues. Is allowing memory management to be handled directly by software engineers a mistake? In some cases, yes, people would be better off with garbage collection. But you'd have a revolt in embedded systems development if that was taken away.
SPAs create more surface area for inexperienced or poor developers to screw up the UX. But a talented team developing SPAs (which really is a misnomer as you're rarely not chunking and lazy loading things behind the scenes) will ALWAYS result in a better UX for users than dealing with the browsers loading individual pages, and very likely more manageable development too.
That said, as I've spent more time in development I've noticed there's a noticeable shortage of talented teams out there.
SPA's #1 draw back is that you have to rebuild browser functionality inside of the browser.
The browser natively handles internet connectivity, back / forward buttons, refresh buttons, URL management. Additionally, users have been trained to understand the responses, hit the refresh button, and use the back button. Browsers have gotten better at distinguishing between your internet being down and the website being down.
Good SPAs have to rebuild all of that functionality.
Use them where they make sense, and don't get religious about it.
I recently wrote a site to track Apple-silicon-native audio software. It works great as an MPA. It's fast, organized, and easy to use.
And the first thing someone offered as a suggestion was: "Why don't you use https://www.sanity.io/ for the content and nextjs or gatsbyjs for the front end?"
I can't even.
SPAs were not a mistake, SPAs were an attempt to make the front end work like front ends have ALWAYS worked.
Back before the web people made C++ and VB user interfaces that interact directly with the data source. SPAs are an attempt to make the web closer to that well known paradigm. POST REDIRECT REFRESH cycle was an insane programming paradigm that wasn't found in any previous edition of programming.
Not so. IBM mainframe systems (3270 terminal based) that ran most of commerce for a long time are basically the same paradigm as a web browser. Send a form to the smart terminal (GET), wait for the response with the field values (POST), send another form.
In fact there are adapters that literally turn these applications into websites by translating the forms into HTML. Commonly seen when you need to do something like change the beneficiaries on your health insurance.
“Client-server” paradigm came out in the 90s when PCs became powerful enough to run a “thick client” application, and was considered revolutionary.
In other words, the eternal cycle continues… :)
GUI application patterns predate the 90s (Mac, X11, Apollo Domain, Xerox Star, etc)
1 reply →
>Back before the web people made C++ and VB user interfaces that interact directly with the data source. SPAs are an attempt to make the web closer to that well known paradigm.
I wish more web developers were aware of just how damn good UI tooling was for native systems. Stuff like WinForms/WPF/Visual Studio and Cocoa/UIkit/Xcode on OSX. Perhaps we could get away from the insanity of rebuilding a select component for every new project.
> POST REDIRECT REFRESH cycle was an insane programming paradigm that wasn't found in any previous edition of programming
Actually I'm old enough to remember old mainframe CICS programming that was a lot closer to the form-based HTML server-side programming of old. When "the web" came out in the mid-90's, it was actually a "blast from the past".
Most SPAs don't interact directly with the datasource, but interact with a middle service. Also many older architecture do draw entire "pages" on the screen at once, rather than manipulating only individual components. (at least not on every interaction)
Clearly, we can't have an SPA front end performing an SQL query directly. The HTTP/GQL/REST services are the SPA equivalent of that data source (they are still a data source). The C++ and VB apps written back in the day were single user programs so yes that's a difference but not by much architecturally.
"Pages" are similarly in SPAs too. We usually have a router that helps the app decide what main "page" is on the screen.
I showed an interviewer a piece of something I built in a traditional page-per-view design, with some xmlhttprequest where appropriate, and a sprinkling of Vue where it added usability to some of the modal dialogs. Their only response was "why didn't you build it in React?".
I stopped interviewing for front-end work since then. The landscape changes frustratingly too often.
I think SPA tooling solves a composability issue that people didn't realize they had, and so SPAs are used in a lot of instances where MPAs make way more sense and would be more performant, because the developers want to utilize the composability of components. The fact that SSR is a feature for React and Vue makes me think a lot of projects were really just aching for composability, not interactivity and dynamic data features of SPAs.
A think a lot of backend frameworks offer some attempts at frontend composability on the serverside but it's usually not the same approach that SPA tooling uses. I would love to get people's thoughts on backend tooling that is attempting to solve composability in a serious way, not just tacked onto an existing MVC framework.
This. I'm keeping an eye on the newer server side renderings like Remix because most of the time what I want is to be able to write components and have them render to HTML, with a few remaining interactive.
If Web components had got this right we the developers could have been happy and using composable components a decade ago.
I agree, I'm am pretty disappointed by how web components turned out. I still use them actually, on personal projects. But that developer experience is absolutely not where it needed to be, then the cool kids showed up and stole their lunch.
But components in web apps aren't really new. That's what ASP.NET and JSF was all about, waaaay back when.
Having worked with ASP.NET and other templating engines way back when and now working with React, I can say that there is a world of difference between the ease of composability of ASP.NET templates and React components.
People really want composability and sometimes they need a tiny bit more interactivity than their server rendered stack offers without hacks (even if it's just more interactive forms)
The fundamental conclusion I reached is that all of the pain originates by having your state divided between client & server, and then being forced to synchronize the two.
Doesn't really matter what technique or framework is involved. The worst trip I've had is with angular 2, trying to put humpty dumpty back together again via tons of janky API calls.
The best solution I have used so far is probably Blazor. In server mode this gets you pretty damn close to 100% state lives on the server. I've had to write some javascript, but even then the abstractions for interop make it very clean throughout. I use eval to dynamically run methods against the client. This allows me to avoid having to serve any custom javascript source (aside from the blazor client js).
If it's an "application" there are no "pages" as that's an old (very old) and deprecated construct. Now if it's a "web site" with a collection of "web pages" - that's another matter. I've been building commercial SPAs now for over 20 years and I can say with much authority that users prefer "applications" over "web sites" for complex business management tasks.
I've also built some pretty huge static web sites (longwoodgardens.org for example) and it an absolute joy to do those as well. I would never recommend to such a client that they build an SPA.
So I'll state this opposing view - that "web sites" were a mistake when used for complex business applications.
To me one of the biggest distinctions here is the overuse of the term "App". I agree that a lot of websites written as an SPA were the wrong tool for the job. There are tons of examples besides the mentioned media websites where SPA is the way to go. Most, but not all, of the applications I work on feel like desktop class applications and the traditional server side rendered approach simply would not work. This includes when I was on the iCloud Web team working on the iCloud Drive App, the Mail App and some others behind icloud.com.
I think a lot of companies that default to SPA would benefit from a very quick traditional website. However, some of the applications that I've been fortunate enough to work on would never be possible.
It's funny how author reinvents caching on service workers in next daily tip instead of relying on browser caching.
It's seeming pretty fashionable these days to bash SPAs. I disagree that SPAs were mistake (or that it's often a mistake to reach for a SPA, even today) SPAs are now and have been a great tool to leverage when you want to build an application without needing to think about servers. Yes, there are tradeoffs. Yes, you should think about the thing you're building for. Yes, you should think about the skills of the developers working on it. That doesn't change the fact that SPAs can be great choice and not something to be perceived as a mistake.
If the choice was between building a traditional app from scratch, or building an SPA from scratch, then I think the article would have a solid leg to stand on: building an SPA from scratch does involve finding ways around things that browsers provide out-of-the-box.
However, pretty much no one writes SPAs from scratch, and there exist many very popular frameworks that handle the vast majority of the common SPA tradeoffs out-of-the-box, so that in reality, you don't really have to think about e.g. whether links are internal or external.
That's not to say that SPAs are always a good idea, or that they do everything well — the author's point about scrolling to the right place, especially when navigating backwards and forwards, is one thing that many SPAs don't get right, for example. And the rise of next.js and the like have shown that there are other benefits to hybrid approaches, as well, and there isn't a one-size-fits-all solution.
As for why SPAs have become so popular, I think this can be summed up pretty neatly: everything is code. There's something appealing to a software engineer about being able to control everything about how your app behaves, control when and how it loads or preloads data, how navigation works, etc. This comes with tradeoffs, you have to be careful about breaking user expectations and making things accessible, and if you go too far you can end up with a big mess ("just because you can make everything custom doesn't mean you should"), but that underlying freedom to make those choices is appealing.
No shit, Sherlock. Of course, all of this was obvious to any of us with more than 5 minutes of industry experience, alas this field seems super prone to reinventing the same things over and over again, making the same mistakes and never learning from the past.
Also, this article does not even mention the fact that SPAs are terrible for SEO. Of course, that's not an issue for YouTube, but it might be a huge issue for your clients, unless it's ok to not have any search traffic.
SEO for SPAs is a solved problem
It is definitely not solved for the vast majority of SPAs out there. Where it is solved, it is not solved for free or cheaply, as it would've been if these apps used server-rendering tech.
2 replies →
The issue is you need some of both for an "optimal" solution.
Unfortunately, Javascript and the basic "controller" capabilities of a web browser just aren't up to the task.
Here are your "controller" options:
1) the server is the controller
2) the web page is the controller of itself (which sucks)
When what is probably needed is:
3) a controller that lives as an extension of the browser.
Frames, for all their issues, basically enabled #3. A controller frame could manipulate the view frames, and those frames were scoped/contained web page "processes". There were issues of course, if you hard-refreshed the overall page (and the "controller" frame) it would lose state, so I don't want to say that frames were a complete solution.
Client storage is half of the equation, and that was added. Good caching infrastructure, multiple asset delivery, connection multiplexing, that seems to be working so you don't need a "big bertha" first page. Standardized DOM capabilities and the like seem to be fairly well solved, and maybe the "Javascript problem" will be solved once ... crap the thing where you have an IR bytecode so you can code in anything in a browser... well that will be solved.
Frankly this needs to be solved. Apps and app stores are a pox upon the land, and the web browser can still save us from that.
"SPAs were a mistake"
Meanwhile essentially every major tech property develops SPAs and users enjoy them far more than traditional hypertext web round-trip-every-change pages
Big tech companies love wasting money and developing a SPA is a good way to do that.
Whether users prefers SPAs or not is debatable. Amazon, Github, and Aliexpress aren't SPAs because poor usability will cause users to move to competitors. If Hacker news turned into a SPA, I guarantee that it would suck big time.
SPA developers seem to be living in a tiny bubble oblivious of simple solutions to simple problems.
> Github
In what world is this not an SPA? I don't see page transitions hardly anywhere, except when you're switching from marketing material to repos maybe.
Additionally, the fact that GitLab (which is devops/issue tracking/wiki/etc.) ISN'T an SPA drives me crazy every day. I have to wait for so many rerenders that could just be seamless loads, it's actually insane to me how unoptimized of a user experience it is, especially when my happy path is super clear with respect to what content I load.
> SPA developers seem to be living in a tiny bubble oblivious of simple solutions to simple problems
I think it's hilarious who you consider to be living in a bubble, and what simplicity really means. Client side interactions need to be smooth. Web applications are consistently and increasingly presenting meaningful user workflows that can be made more resilient and responsive with SPAs. I develop tools for dataflow/workflow editing, scheduling, visualization, etc., and the idea that these things can be made to feel good without a dedicated client layer is truly an archaic attitude.
1 reply →
> users enjoy them far more than traditional hypertext web round-trip-every-change pages
"Major tech" often monopolizes its market so it's not really fair to say users enjoy it when there aren't any alternatives.
I've been thinking about this a lot, and the one thing I love about SPAs is that everything the user can do from the front end. They can do from the API. The trend has essentially tricked tons of corporate apps into opening up APIs to their users. My screen scraping skills are starting to get rusty, but it's worth it.
I sometimes daydream about a framework that allows me to build a spa and a server side app at the same time using the same url scheme.
Here's the thing: so-called "JAM stack" apps are the cheapest to run, right? I realized this while I was thinking about how to create the cheapest site possible. Mainly, you want to minimize bandwidth. Well, SPAs are designed to do this. The site gets cached on the first hit, and runs usually JSON requests in the background after. So I think a big motivation for building SPAs is because they're cheap to host/run.
This article doesn't seem to be thought out properly. I mean the name already suggests what Single Page _Applications_ are good for. They are useful when you want to build an application in a browser and not just a regular website.
State is probably the main factor why you would like to do this. I can agree on that SPAs are used in some places where they don't fit (mostly content heavy sites). But they are not a mistake.
> Browsers give you a ton of stuff for free
True, but irrelevant. I have written an OS GUI, including full file system support, in the browser that performs faster than native OS GUIs. My biggest learning from this is talking about performance in a job interview is the fastest way to kill the interview. Performance, like security, requires trade offs that deviate from comfort. If the common developer is insecure comfort is the only thing that matters.
JS hiring expects the following: React components, 2-6 weeks of JS practice, the ability to use map/filter on arrays, and CSS. If you overshoot that you begin to enter unknown territory that intimidates other developers. The better you are the less employable you become as the further from the bell curve you drift.
If you are wondering why this is or how we got here the answer is trust, or the lack thereof. In software there is a long standing bias: if you can see it visually its worth less. I have been doing this work for more than 20 years and that bias predates my work, so its been around for a while. Bias is continuously reinforced by the lack of standards in software hiring and the inability of employers to train their employees.
This lack of trust means that employers do not trust their employees to perform original work and likewise the developers don't trust each other. This is why absolutely everything, I mean this literally, is a downloaded NPM package, because the developers will trust an anonymous stranger to write original code before they trust anyone they know. There is all kinds of excuses to qualify this, of which some are bizarre and nearly all lack any kind of merit.
This is why its irrelevant what the browsers provide. Its baked into the framework, an NPM package, or ignored.
For me, things like react and vue are DEDICATED to the front end. They are great for building UIs and have great ergonomics.
Backend frameworks that I LOVE (asp.net, laravel) have templating languages that feel like an afterthought, and passing data to them sucks (I usually have to redeclare what data they receive somewhere, or it’s entirely a dynamic paradigm) editor support is ok AT BEST… all of the sudden part of my app is dynamic c#, which c# isn’t good at.
My choice of backend should be absolutely divorced from my choice of front end. I can write an api in node, c#, go, etc and I don’t have to totally change how my front end works.
And splitting state between front end and backend (as mentioned throughout the comments here) is awful and error prone. There is a reason large scale apps aren’t using vanilla js or jquery and hand rolling state management etc.
It’s all about the size of the app, complexity, division of labor (I can hire a front end specialist who spends 70-80% of their time on front end)… the only goal isn’t JUST performance but if you do it right you get that too.
These types of posts always miss a common reason why an SPA might be desirable in the real world: cross-company collaboration.
The assumption made in these posts is that you have total control over your entire application stack. Infra, Backend, Frontend, Ops, etc. In the real world, often times different companies are collaborating to build a final product for a client.
I worked at an agency that built an SPA because the frontend and backend were built by two separate companies at the same time. We’d meet to agree on what the APIs would look like and what shape to expect in the data payloads. Once we had some sample data, we could build a UI against that data.
When the real API was ready, we just switched the URL in the app config and everything started working.
If we didn’t build that as an SPA, we wouldn’t have been able to make the deadline the client was aiming for.
In a perfect world, would this have made sense to build as a MPA? Probably. But in the real world, you sometimes have to build things given some non-ideal constraints.
I also notice how much longer it takes to build the same crap we built 15 years ago with just html/css/js, and no, projects these days are not more sophisticated. Same old form submissions, but with a monstrosity of a project and crazy rates of devs who wants to constantly upgrade/update/migrate so some newer JS framework :shrugged :evilsmile
Many projects are absolutely more complex than they were 15 years ago. The web is now a space for fully-interactive applications, not just interlinked documents and forms
I am comparing apples to apples (CRUD to CRUD), not some random websites.
2 replies →
SPAs are ideal for web applications where users are manipulating application state in real time. There are many situations where this is applicable, you can't build something like e.g. Office on the web without an SPA, calling SPAs a mistake is trendy, but betrays an ignorance of the practical tradeoffs of an SPA.
I usually bite my tongue when these articles pop up weekly, but let’s ask ourselves a question: did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake? Or did this guy with a blog miss something?
I’ve recently worked on converting a large code base to an SPA and the improvements in DX, UX and performance are enormous. Even the old timers that resisted the project have all come around.
This doesn’t mean your blog should be an SPA. It shouldn’t. but reducing the valid use cases for them to Youtube is equally ignorant.
I generally agree they are being overly applied, but that’s not an indictment on the technology whatsoever. Fads in technology happen (“rewrite it in rust” is a recent one). The fact that many people are falling into this fad says nothing about Rust as a technology other than people love it enough to overuse it.
> did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake? Or did this guy with a blog miss something?
Today I opened the Music app on my Mac to cancel a subscription. It asked me to use Touch ID to authenticate (fair enough) but then immediately fell back to asking me for my Apple ID & password.
This is on a Mac that's been logged into iCloud for ages, has a working iCloud connection (exchanged some files through it today) and I installed an app from the App Store today (without being asked to reauth, suggesting my session is indeed still valid).
The fact that MacOS frequently asks for Apple ID credentials seems to be a common and widespread problem that I myself experienced for years (sadly this occurrence wasn't a surprise for me - if anything the initial Touch ID prompt was more surprising as I couldn't believe it would actually not ask me for my password this time), so I wouldn't use big names as a sign of quality - if anything it's the opposite, big names means lots of employees who might have their own reasons for doing certain things or preserving a status-quo that might benefit them & their careers at the expense of the user experience.
> did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake?
Is that so impossible? There are many other considerations that go into technology choices at these companies. There are trade-offs involved, and for companies with huge teams of developers the considerations need to be very different than for small–medium sized groups of developers.
I would argue that a smaller group of developers can focus much more on user experience and engineering efficiency, whereas a large company has a organisational scaling issues and a significant bureaucracy to support. At a large company, engineering considerations come second to very many things. It would actually be surprising if the trade-offs and choices those companies made were correct for other very different companies.
ANY modern site uses something like nextjs or any other static site generator. The q is then if you make the site isomorphic or not and how the need for dynamic content looks.
There are no other viable options today for large professional sites.
If you have the problems described in the article you probably are not using a web framework.
SPAs exist for a reason. Same with SSR. Developer ergonomics play a bigger role than you think. And if you think that the choice is either SPA or SSR then you haven't been paying attention to recent developments in the frontend world.
Websockets+SSR (PhoenixJS) attempts to store state on the server rather than the client; in that way you can still have stateful interactions with minimal JS. NextJS does an amazing job patching the bridge between SPA+SSR by having the same codebase run on the backend and the frontend. What I would like to see more of from this industry is less "grass is greener on the other side" and the unification of a single tool that allows for the cross-collaboration of SPA + SSR without having two distinct codebases that one has to context-switch between.
I think one of the main reason SPAs are overused is because it's hard in 2022 for your users to wait after clicking on a link. Users are now used to instantaneous, especially since they all have a smartphone with apps on it. We, as web developers, try to give the best UX to users.
I agree with you and I think there are some good SPAs. In my case what makes me angry is opening a presentation website and seeing a loader because someone decided to make that a SPA.
It is annoying to see titles such as this, since SPAs are most certainly not a mistake (the article itself points out that the Youtube SPA is not a mistake).
The truth is most devs struggle to implement SPAs well. To implement an SPA well, you need to understand browser APIs extremely well (such as the History API), and in my experience, most devs don't, hence the broken back buttons etc.
To me, there is nothing nicer than a well made SPA, and often, the best SPAs are faster and lighter than the desktop apps they replace. I believe they are the best way to deliver software in the current age, and the sandbox that the browser offers actually provides users with a more secure execution environment than traditional software delivery mechanisms.
I personally LOVE SPAs.
I am mostly on the SPA-hating camp. There are two issues that annoy me the most. They are not a framework's fault but some kind of "mental model" fault:
First. When doing SPAs, APIs tend to leak a lot more info than needed, opening the door to attacks not commonly seen on server-rendered pages.
Second. Applications' bundle tend to have way more than users needs, even UI's they should not have access due to security/permissions. Most developers are not even aware of this problem and don't know that sensible info/features/endpoints are leaking.
As I said before, those are not faults at the framework level, but the development style that I seed used when making SPAs always led to them.
My company wouldn't know it.
I'm lead on a large Angular 13 app used by tens of thousands of companies, it works and it's very fast.
I wouldn't call SPAs a mistake. I have 2+ decades in the industry and come from an ASP.Net / MVC background prior to Angular.
They were necessary from a perspective of "we need a way to develop a company's web presence in a way we can send kids to code camp to get the gist of." Of course they weren't a wonderful thing in terms of actually building sustainable infrastructure, but what's that to stand in the way of business's need to go to market yesterday?
Code camps don't have time or resources to educate their students so we got the reinvent-the-world half-solution that is the SPA. SPA frameworks won't ever go away but you'll get the chance eventually to go work on something better-architected than your run-of-the-mill NodeJS shitshow.
I don't think that's accurate. SPA's arise from the desire to put something like Slack in a web page. If bootcamps are responsible for that, I don't see how. Isn't it more likely that they meet the demand rather than create it? And bootcamps taught Rails long before they taught React.
And let's be honest, making a server rendered site with some traditional Python framework is in many ways just as easy or easier than making a SPA.
Most major frameworks do that. Barring some devs who navigate using onClick over a link despite having that option.
Outside of some lasting mistakes made a decade ago, is this still an issue?
On top of that, “SPA” is a misnomer, as many frameworks give you a hybrid anyway.
I don't know why routing is the sole focus of the article. In all my SPAs it has been a set up once and forget about it deal. No one is constantly reinventing the wheel there, the churn is in other areas like reactivity and state management.
well summarized.
its easy to make bad SPAs nowadays. imo more time needs to be spent in the tool/environment/framework/language selection and evaluation process.
also, many SPAs cant even handle basic forms correctly anymore, because developers learn more javascript than html5. like the author pointed out, rebuilding features in js that already exist, just because one is unaware of the fact that it exists or what the underlying design choices have been, often is a bad idea.
are there actually still people that care about noscript? i mean, i get that most people dont care and js is enabled by default in most browsers, but the no-js-web-world is also quite interesting.
Traditional dynamic web servers can solve a lot of the same problems that SPAs and event front-end frameworks like React solve, by just applying software engineering principles to the whole stack. That's what Novo Cantico[1] does, and a lot of what I've been trying to say in my blog posts[2] that explain Novo Cantico.
[1] https://github.com/sdegutis/Novo-Cantico [2] https://www.novocantico.org/blog
If not SPA, which technologies would you suggest for a web app similar to an IoT dashboard, with gauges and other UI elements that update every second? The server is written in ASP.NET Core.
I was considering Blazor server side but it does not seem to be very popular (compared to react, Vue, angular, etc) and I am not sure it's a good choice for the long term (MS likes to kill UI technologies). Approaches like htmx and unpoly do not seem to be appropriate if a large portion of UI needs to update frequently (feels similar to implementing the Blazor approach but inefficiently).
I love SPAs. When used correctly.
SPA stands for Single Page Application.
It makes sense when what you expect is an actual application. Tools that just happen to be running within a browser for convenience. The browser just happens to be delivery mechanism.
On the other hand if the user expects navigable, hyperlinked content, SPAs just get in the way of navigation and make users' lives miserable for no good reason.
I want to move forward, move backwards, make a bookmark, open multiple tabs. It is frustrating when the application makes it impossible when those would be completely reasonable operations on, say, news site.
Users do stupid things regardless of the implementation. The extra work to implement a SPA is worth it because you can swap material in and out on demand without constructing a complete new web page.
100% disagree with OP.
I think SPAs are awesome, there are just so many cases that SPAs can handle easily and more gracefully. From non-redundant input checks over interactive elements to optimizations for spotty networks or even offline usage.
Anyway, it's painful when a page won't load or it takes 10 seconds to load for no apparent reason. That's why profilers need to be used, loading indicators within the elements and also there's the trend towards frameworks with small footprints or even to go framework-less.
Using them for everything and everywhere as a default option might have been a mistake. SPAs in general are not a mistake (but generalised headlines do bring in the clicks so there's that).
As a user, when I'm using an "application", on the web or the desktop, the last thing I want is for the entire UI to be reloaded for me after every action. For applications it makes sense to be run on a single page, fetching only the data when it's required and that's it.
I'm still bullish on the potential for Web Assembly apps to overtake mobile binaries.
And instead of Single Page Apps, we'll have just plain Apps that run in browsers.
I would much rather program in any language that is compiled to web assembly rather than JavaScript.
Since I assume you know about it a bit more, what is realistically timeframe it could happen at best?
No idea on timeline. But I'd speculate Apple has no incentive to cannibalize their AppStore ecosystem and make Safari more than a web browser.
So Google/Chrome or Firefox are the only 2 players with enough incentive to make Wasm an Internet app standard.
Or possibly the next Wasm-first, cross platform browser will come along with a Wasm AppStore?
Unless you already have a SSR in place(or you're familiar with it, e.g. Django, Laravel, Rails,etc), I feel SPA(or MPA) is actually a decent choice albeit the learning curve. Separation of concerns is always good. With SPA frontend developers can develop the UI using restful or some web APIs provided by the backend, while backend engineers can advance the server side and keep the API consistent.
I had the pleasure (aka hell mode) of building a content site as a SPA because some non-technical manager kept pushing it (it was one of those companies).
It was an insane task to meet all the SEO requirements, we ended up doing server rendered pages, and keep in mind this was years ago so there was not a whole lot of support or tutorials on how to do it.
Oh well, I got paid to learn a bunch of new stuff so I can't complain :D
Yeah, I was gonna say SPAs are not really good for marketing type of sites. Doesn't work easily with SEO. I learned this the hard way, but there are other use cases for SPAs. Just don't use it for sites that require good SEO.
I am pushing for a rebuild of that site using Laravel and minimal amount of javascript, actually :D
That was the worst manager I've ever worked for. He also never pronounced my name right even after I told him, so he can go f** off. Still triggers me to this day :D
He pulled the SEO requirement at the last minute, since he would not invite the technical people to decision meetings.
If it makes you feel better, SPAs were a mistake when they were all the craze in Flash. Also way before that in Director.
In those two cases, they signified (or accelerated) the end of the useful lifespan of those languages.
SPAs, like frameworks, always make some things easier and some things harder. As long as you stay within the lines of what is easy, you are good. As soon as you stray outside those lines, you get punished.
SPAs are great, not a mistake. If you use the wrong tool for the job you can make look anything like a mistake. Sure, your two-page hobbyist blog won't benefit from being an SPA, having a well-partitioned Cassandra cluster holding your three-paragraph posts nor having a serverless autoscaling architecture, but that's how people like to build it.
I was writing comment explaining how we can use new browser API's to get rid of SPA for 30 minutes.
Accidentally pressed F5 and all my message text disappeared in void. The same way it happened 15 years ago, same now, browsers not improved.
That's why we do SPA, we want reusable text input component out of box which automatically saves user generated content in forms on typing.
Lame opinion, but I miss the (pre-license-change) ExtJS days
Unified library of tools. An actual GUI designer to design layouts in.
Now everything's just a mess
The argument appears to be that browsers give you a lot of things for free that SPAs need to recreate.
But that's not true in practice. In practice most SPAs are created on top of a handful of extremely well tested libraries/frameworks that do all the work for you that the browser would do in an MPA.
That's not really a good reason that SPAs are a mistake.
I think people have forgotten how easy it is to set up a traditional server-rendered site with Spring Boot or Django or whatever framework. These days I see people adding a SPA as the default starting approach, which adds an entirely separate additional tech stack & deployable to the mix when it's not usually clear why.
If you don’t start with an SPA, you are looked at funny. Like maybe if you were to choose COBOL for the backend code.
SPAs are just Flash 2.0, except it's not popular to hate on them like it was popular to hate on Flash websites.
My dev was asserting that a modest change to how a certain form control works would be "easier in React" (and this is on a piece of our application that's not even in any SPA right now). I marvel over the eagerness with which developers reach for React and friends nowadays.
> SPAs were a mistake. Tomorrow, I’ll show you how we can build MPAs that are just as performant as SPAs, with less complexity and fragility.
You could just show people Unpoly: https://demo.unpoly.com/
lol another developer who hasn’t built an enterprise web app that requires The be benefits of a spa… and hasn’t taken advantage of the best practices around redux state management.
Have fun with managing state in the server while building apps that work internationally and offline.
This is probably true if you're writing an SPA from scratch, but in reality much of that complexity is handled by libraries like Next.js. I also think it's much easier to learn a React-like library than to learn various server-side template frameworks..
This opinion gets reiterated over and over and it's still wrong no matter how many times you say it. SPAs are just apps.
I'm sorry people can't tell the difference of when you need a site and when you need an app. That doesn't make web apps a mistake.
But it is so strange, most SPA's are basically just power point presentations. Why did it go like that? It isn't like people look for programmers to replace their power point presentations or PDF's, but for some reason that is exactly what they do on the web.
At this point most articles like this or tools addressing the problem discussed here replace one local optima with another, I'm holding out for something radically different, maybe something like makepad or bevy like ECS with good support for UI.
I wonder how you would build an encrypted messenger like like Element (app.element.io) without SPA style.
I think it's not even possible, since you are required to process incoming messages client side and must not send any private keys to the server.
This is irrelevant in practice because the SPA's code is also loaded from the server - if the server is malicious it'll just serve you backdoored JS, unless you load from a separate domain and have the main server allow cross-origin requests.
If you want to defend against a malicious server you need to make sure your client doesn't load & execute code from said server - it needs to be distributed as a stand-alone application instead of in a browser.
> unless you load from a separate domain
Which is the case... app.element.io doesn't host a Matrix server. Servers are completely independent of that.
Also, the majority of websites on the web are landing pages, blogs, news websites or e-commerce sites, all of which are inherently multipage.
SPAs should be used creating "applications" (as stated by the "A" in SPA), not websites.
Luckily we don't have to use them. Go ahead and do a full page reload when the user navigates to another page. Go ahead and implement interactive elements using jQuery. It all still works just as well as it did in 2012.
I fully subscribe to this notion and hate it that our field is riddled with hyped technologies which everyone chases.
Just because something works for Google (Angular) or Facebook (React) doesn't mean it works for your SMB application.
>This is, in theory, supposed to result in web apps that feel as fast and snappy as native apps.
What a bizarre premise. We don't build SPAs as alternatives to native apps. We build them as alternatives to server rendered web apps.
For me, I mostly work on applications, the UI just happens to be in a browser. This is different from server rendered sites that may make more sense in some scenarios.
I happen to really like, React, Redux, Material UI, etc... ymmv.
Also, more SPA framework logic needs to become part of the web platform; APIs beyond pushState, service workers, etc. You have to integrate it into the browser to really remove the confusion and the boilerplate.
The worst is when you have to use a piece of tracking or support software in your product and it pulls in a whole SPA with its own react/angular/whatever even when nothing is shown...
If our whole industry is wrong about SPAs, and a whole generation is wrong about SPAs, what is the best practice then? Does anyone have a comprehensive resource on the right way to do things?
I just wanted to note that the example - YouTube - is not an SPA. A click on a video from the homepage loads a distinct page, along with user profiles and other areas of the site.
Not the reasons I expected
I don’t see Navigation as a main problem and it can be solved quite neatly, not that much more complex than a normal site. Was expecting something about bundle size etc.
Agreed. The blog doesn't seem like a very thought out examination, and I expect most of the HN replies are just debating the title.
For me, the biggest con of SPAs is lack of SEO.
I found that Blazor to be a right mix between server rendered pages and SPAs. The programming model is good and adding interaction is easy.
The only issue is with scaling.
While Web2 is moving to SSR, I think SPAs will be a huge part of Web3.
SPAs are perfect for decentralized infrastructure like IPFS and friends. Same goes for mobile apps.
What exactly from SPA is making them good for decentralized?
Can be put on IPFS without much hassle.
Nextjs is a great way to make multipage web apps in modern day. Imo it should simply be the default for most use cases
Controversial opinion: SPAs are great and also SPAs are an admission that Java applets were along the right lines.
I guess Blazor WASM is the elephant in the room. OOP as much as you want, js codebase required near to 0.
the frustrating thing is that i rarely find a page that doesnt take at least 20 seconds to load, even if i only want to see an 100x100 image. This happens no matter how fast computer i use and it 's despairing
The term "server-side rendering" gives me giggles every time
Anyone else encountered NG routing locking up upon return to the web app with Safari back button?
Seaside on Squeak (now Pharo), is still my happy place for web application development.
I'm still insisting that progressive enhancement was the way to go.
This article could of just said “use NextJS” and saved a lot of words
I have always wondered how people gain this self-confidence.
The web is a mistake.
Of course, but who would believe us if we told u sooner?
The article does give good examples of where SPA works.
htmx.org the one and only frontend revolution
webapps were a mistake.
no they weren't, stop with these clickbait bad takes