I didn't say there are no use cases for a SPA, what I'm arguing is that in the vast majority of cases it's not a good option.
What constitutes a SPA? Essentially it is a JS application that handles all route changes and in consequence also has to handle application logic, state, etc.
To be able to achieve that kind of functionality development becomes much more complex. Not only you now get all the architectural nuances of making an app, which your typical JS dev doesn't understand, but the dev workflow becomes convoluted for a number of reasons:
1. Not all browsers support the same language features and APIs which introduces the need of using transpilers like Babel or Traceur.
2. JavaScript is objectively a poor language for complex projects hence the success of alternatives like TypeScript.
3. The JavaScript standard library does not live up to the necessities of the modern front end developer which introduces the need of using and managing more dependencies. For example, after all these years there is still no native reactivity.
For these reasons we now have to use bundlers like Webpack, NPM dependencies, and a very long etcetera. Plus a continuously changing dev landscape (see React hooks for example).
It is still challenging to make an accessible SPA. Common functionalities likes control+click on a link have to be re-implemented.
Of course sending all this functionality to the client can have a serious cost in size and CPU. It's not as big in leaner frameworks/libs like Svelte but it's always there.
The initial bytes can be mitigated by using something like Webpack chunks, but again this introduces more dev complexity.
Finally, in the vast majority of cases (if not all) SPAs also render the content. This requires developing an API (GraphQL, REST, etc) which introduces another layer of complexity vs doing the rendering in the server. In some cases this is necessary as there can be various clients, but not always.
IMO all these drawbacks make sense when the SPA model is justified and there is a need for sophisticated functionalities. Gmail is the perfect example. Soundcloud is another good candidate since audio needs to keep playing at all times.
So usually the arguments in favor of an SPA are that the UX is better or that after a number of clicks the user receives less bytes compared to receiving markup.
I think that the UX benefits of a SPA are exaggerated for common use cases (e-commerce, CRUD admins, enterprise apps, marketing websites, etc). Amazon, Ebay, Wikipedia, are not SPAs and they are still getting millions of visits every day and probably growing.
As for getting the data in JSON or WebSockets vs getting HTML, yes, after a number of clicks there are some bytes savings but after having paid a high cost in initial bytes and CPU cycles. This argument could make sense in very particular use cases, but I don't think it can be applied as a general argument on all websites. It makes sense for gmail, since there is a lot of clicking around and changing views, but that's not a concern for the vast majority of websites.
I should probably write an article about this since I've left out some points and haven't gone with much depth into others... but I hope this comment conveys my position.
"The vast majority of cases" doesn't mean anything. Everything depends on what you're building.
First I must say that this phrase: "Not only you now get all the architectural nuances of making an app, which your typical JS dev doesn't understand" is ridiculous and needlessly derogatory. There are a LOT of JS devs in the world, and the "typical" ones obviously understand this, or you wouldn't be on the internet right now.
Furthermore:
1. That's why JS projects use Babel. Or Typescript.
2. This point is objectively false, given the fact that most websites you use are complex JavaScript projects. Also, yeah, there's TypeScript.
3. That's why JS projects use libraries and "more" dependencies. It's very rarely an issue.
- "we now have to use bundlers like Webpack, NPM dependencies..." Have you heard of Makefiles, unix package management tools, "and a very long etcetera"? None of this is new by any means.
- "Plus a continuously changing dev landscape" - welcome to programming. Change is a constant.
- "It is still challenging to make an accessible SPA..." Of course! it is still challenging to build products, and make good UX. Welcome to programming for users. Good luck figuring out what they want and need. There are jobs for that too.
- "sending all this functionality to the client can have a serious cost in size and CPU." Sometimes. Sometimes not. Sometimes it doesn't matter, like in most of the cases of most of the customers using SPAs. When it matters, people figure out how to solve this.
- "Finally, in the vast majority of cases (if not all) SPAs also render the content" - definitely not all, maybe JUST the majority. And... "developing an API" vs "doing the rendering in the server" is rarely an issue or conversation and basically not a valid argument.
- "Amazon, Ebay, Wikipedia, are not SPAs and they are still getting millions of visits every day and probably growing." This is a fundamental misunderstanding of what a SPA is. Of course not literally every single page on the top largest websites in the universe are consistently in one single application with only client routing. But each of them have many pieces that are. Most popular web apps are hybrids like this.
- "It makes sense for gmail, since there is a lot of clicking around and changing views, but that's not a concern for the vast majority of websites." This leads to a philosophical discussion of the difference between a website and a web application, where one is mostly reading and displaying data, and the other is "a lot of clicking around and changing views" (which, it turns out, is what many, many companies and products fundamentally are), which isn't really germane to this. It's probably safe to assume most of us are talking about the latter. We can also agree that blogs don't usually need app behavior.
> ...is ridiculous and needlessly derogatory. There are a LOT of JS devs in the world, and the "typical" ones obviously understand this, or you wouldn't be on the internet right now.
I admit I speak from my anecdotal experience, but probably so are you. Also because something works doesn't mean it's properly coded.
> That's why JS projects use Babel. Or Typescript.
Yes, that's what I said. My point is that needing to use Babel is not a good thing.
> This point is objectively false, given the fact that most websites you use are complex JavaScript projects. Also, yeah, there's TypeScript.
First, you don't really know which websites I use. Second, I seriously doubt HN is a complex JS project nor classic desktop Reddit or StackOverflow. Third, TypeScript precisely validates my point.
> That's why JS projects use libraries and "more" dependencies. It's very rarely an issue.
> None of this is new by any means.
> welcome to programming. Change is a constant.
No offense but that is the typical JS developer Stockholm syndrome.
Yes, obviously, there will always be change in all aspects of life. In any other language things are much more stable.
> Of course! it is still challenging to build products, and make good UX.
You are missing the point which is: SPAs are solving problems that are already solved at the browser level.
> This is a fundamental misunderstanding of what a SPA is.
Not really, you are fundamentally cherry picking. The core experience in those sites are not SPAs, it is irrelevant if they have some SPA mini site somewhere.
> This leads to a philosophical discussion of the difference between a website and a web application
Exactly, and that's my whole point.
There is an abuse of the SPA architecture for websites that are not applications. Even when the development complexity is a lot higher with not many benefits for regular websites.
What constitutes a SPA? Essentially it is a JS application that handles all route changes and in consequence also has to handle application logic, state, etc.
To be able to achieve that kind of functionality development becomes much more complex. Not only you now get all the architectural nuances of making an app, which your typical JS dev doesn't understand, but the dev workflow becomes convoluted for a number of reasons:
1. Not all browsers support the same language features and APIs which introduces the need of using transpilers like Babel or Traceur.
2. JavaScript is objectively a poor language for complex projects hence the success of alternatives like TypeScript.
3. The JavaScript standard library does not live up to the necessities of the modern front end developer which introduces the need of using and managing more dependencies. For example, after all these years there is still no native reactivity.
For these reasons we now have to use bundlers like Webpack, NPM dependencies, and a very long etcetera. Plus a continuously changing dev landscape (see React hooks for example).
It is still challenging to make an accessible SPA. Common functionalities likes control+click on a link have to be re-implemented.
Of course sending all this functionality to the client can have a serious cost in size and CPU. It's not as big in leaner frameworks/libs like Svelte but it's always there.
The initial bytes can be mitigated by using something like Webpack chunks, but again this introduces more dev complexity.
Finally, in the vast majority of cases (if not all) SPAs also render the content. This requires developing an API (GraphQL, REST, etc) which introduces another layer of complexity vs doing the rendering in the server. In some cases this is necessary as there can be various clients, but not always.
IMO all these drawbacks make sense when the SPA model is justified and there is a need for sophisticated functionalities. Gmail is the perfect example. Soundcloud is another good candidate since audio needs to keep playing at all times.
So usually the arguments in favor of an SPA are that the UX is better or that after a number of clicks the user receives less bytes compared to receiving markup.
I think that the UX benefits of a SPA are exaggerated for common use cases (e-commerce, CRUD admins, enterprise apps, marketing websites, etc). Amazon, Ebay, Wikipedia, are not SPAs and they are still getting millions of visits every day and probably growing.
As for getting the data in JSON or WebSockets vs getting HTML, yes, after a number of clicks there are some bytes savings but after having paid a high cost in initial bytes and CPU cycles. This argument could make sense in very particular use cases, but I don't think it can be applied as a general argument on all websites. It makes sense for gmail, since there is a lot of clicking around and changing views, but that's not a concern for the vast majority of websites.
I should probably write an article about this since I've left out some points and haven't gone with much depth into others... but I hope this comment conveys my position.