I tend to agree. But in defense of the SPA, my experience is that over time, most screens accrete complexity.

You start out with a simple content screen. Then the client wants comments. Then they want richer comments. Then they want live comments. Etc.

Over time, most of my web applications tend to require richer and richer interactivity on each screen. As a result, it's nice to have started out with a client-side framework, rather than hitting some threshold where you suddenly need to switch things over.

Your last paragraph summarizes why I default to a client-side framework if there's going to be much of any JS interactivity at all on a screen.

Even something that seems simple like a search form can be surprisingly interactive.

> As a result, it's nice to have started out with a client-side framework

You mean like Angular or Ember?

Because you can perfectly use Vue, React, Inferno, Svelte, Imba, etc, on a multiple-page application.

I'm not a fan of Angular, but how many times are we going to have this conversation. At this point, this is a completely off-topic comment that has no place in this thread. I'm getting javascript fatigue fatigue.

> With some exceptions, there is really no benefit

This is just a contradictory sentence of hyperbole. Who cares if there are plenty of use-cases to not write a SPA. There are also plenty of use-cases for it, and many benefits.

Angular is a popular library and therefore this is newsworthy and we should respect it as such instead of devolving into a played-out asymptotic argument.

> There are also plenty of use-cases for it, and many benefits.

I obviously disagree, but please elaborate.

I would like to read your elaborate opinion of why there's no use-cases for it.

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.

> Everything depends on what you're building.

Obviously, that's precisely my point.

> ...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.

I've spend the last decade building highly dynamic data visualization applications. Building them server-side would be a huge pain.

A visualization doesn't need to be a SPA.

No, but one that's highly interactive and is constantly re-fetching/updating data does.

Small, internal business apps have been a good use case for me. I'm working with few dev resources (me, myself & I), so the "batteries included" approach of Angular is nice, and knowing it's always served over a fast corporate network alleviates the filesize concerns somewhat. Plus, we're in a situation right now where some of our clients are being sort of amorphous on what server platform they'd like to migrate to and when, so the browser is a more stable target (ironically).

It's an unusual situation perhaps, but having done similar apps with other frameworks and paradigms over the past ~10 years, Angular 2+ just feels like a good tool for the job.

> Plus, we're in a situation right now where some of our clients are being sort of amorphous on what server platform they'd like to migrate to and when, so the browser is a more stable target (ironically).

Right, but you could still do server side rendering by consuming a third party API instead of a DB directly.

Maybe bloating is not an issue in some use cases, but client side rendering can have a major impact on the CPU.

The "server" part of the "server side rendering" is necessarily on premises, and likely to move to... something? Soon? I deliberately wrote it as thin as possible, because it will need to be rewritten, without question. The db, fortunately, is on a stable platform.

I don't disagree with the bloating issue, but in this case, these are all decently capable desktops, and it hasn't been even close to a problem.

I'm kind of with you.

I think SPA's can be suitable (sometimes) for internal line-of-business applications, where you have a degree of control over the environment the end user will be using your application on (ie the device/browser (+version)/etc) and bandwidth isn't a big issue.

In this sort of environment, Angular can work pretty well.

For public facing applications, where you can't say with confidence that your end user will be on a modern computer, using a modern browser with a good internet connection, etc, you are better using a server-side rendering framework and progressively enhancing using something like Vue.js.

That's my 2 cents anyways.

You can do severside rendering with Angular Universal.

Also Angular has helped me a lot with bowser compatiblity in the past (IE 9).

True, you can also do it with more mature frameworks such as Rails/MVC Core/Django etc.

I don’t have experience with Angular Universal, I do with Nuxt (Vue SSR) and it was great, but frustrating to work with as things got more complex.

SPAs aren't classic websites, they are web applications and should only be used when you need to create a web application. If a SPA is created for every usecase a regular website would do is a bad management decision but nothing wrong with SPAs per see. And yes, in this particular case is a waste of resources.

I've been building Angular apps for 3 years now, and all projects I've built have had a "relatively light" frontend, meaning little to no business logic there.

Angular as a framework doesn't prevent you from doing anything on the backend. It's all about the re-usable components imo.

It's all about the use case. If you're on an ecommerce website and click between category and PDP pages 5-10 times browsing, a SPA is going to make that transaction an order of magnitude faster. Since you're only loading the smallest possible payload (JSON) that contains only the things that have changed, it is optimized in a way that is never going to be achievable with server-side rendering.

At least that's why I opted to push for a SPA.

Yes it's all about the use case, but I generally don't buy that argument.

First, because the largest ecommerce websites are not SPAs and are generating a shit ton of revenue. Not only Amazon and Ebay but also stuff like Magento and Shopify.

Second, while it can be argued that after a number of clicks the total kbs will be lower by using JSON and rendering on the client, the vast majority of users really care about the initial load. Much like monthly payments, it's generally better to have a consistent 500ms lag than a 3000ms lag on the initial load and then 200ms on every click. Of course I made these numbers to explain my point.

This does not apply to all use cases obviously. In some cases such as an application like Gmail an SPA is completely justified and my arguments do not hold, but in the case of e-commerce I think there are no valid arguments for an SPA.

Exactly! Initial load is IMHO far more important, since as I travel the world some sites (including allmighty new GMail) just won't load. No load, no sale. And maybe perfectly crafted JSON will be very small, but a classic HTML page it's not gonna be much more than that (compared to cached assets).

Angular has server side rendering capabilities, called universal angular app, which allows sending HTML pre-rendered to the client similar to Next.js or Nuxt.js.