the differences are rather in the architecture.

you can win or loose a lot there, by choosing the right or wrong one.

by creating an SPA you win a much simpler backend, you separate data storage and processing from data presentation.

you win the ability to have multiple different frontends against the same backend, or run multiple backends against the same frontend.

you win the ability to upgrade/replace backend or frontend independently.

you win the ability to develop with multiple independent teams because the connection between frontend and backend is smaller and easier to define.

you win the ability to reuse generic backends over multiple projects...

these are a lot of advantages, if you need them.

but there are downsides.

you no longer have a single codebase.

you need to maintain an API

rendering is slower in the browser.

depending on what kind of application you create, you may need to be careful to not put any business logic into the frontend. (anything with business logic goes into the backend with an api to access it)

it should be clear by now that i am a strong supporter of this architecture.

i may miss some downsides of an SPA and i'd love to get more input on other potential downsides, however, loss of productivity from writing javascript is not one.

You are obviously writing more code for client side HTML generation based on JSON than regular server side rendering... I am saving effort if I need to write fewer files...

Your feature requires a JSON route, html rendering, and javascript that pulls everything together. Mine is just a route that returns HTML. Why is there absolutely no difference in effort? You have 3 files, I have one.

separating data from presentation is not new. It has nothing to do with SPAs

i have used different backend and frontend frameworks, and i found that backend frameworks do not make things simpler in the sense that you are talking about, if you want to create clean and maintainable code.

sure you can put everything in one file, but the number of files is a meaningless metric. more useful is the number of functions and abstractions. an API is an abstraction. you can do away with that if you generate html in the backend, but the price you pay is with a much closer coupling of interface and business logic that will make future changes harder. in any sufficiently large site you can't afford that and you end up rewriting your site to create the same architectural complexity simply because you need it.

SPA frameworks query the server for JSON and then render HTML right?

Simpler in the sense of what? You prefer to not have all of the variables available when you render HTML? It's simpler to only render client side HTML and to query 4 different AJAX endpoints for resources?

Why are you trying to separate business and interface logic? Why are you displaying anything that the business logic doesn't understand?

The entire point of good code is that I can edit 1 file instead of editing 3.

Back end frameworks don't help you organize code? That's kind of their point?

The end result looks very similar to the server side frameworks of old, so it's a bit of a circular evolution. I think only using one programming language (the one that is part of the web platform) and a solid, template free component framework make it incrementally better though.

You can still and should have an API but it will be an internal one(in-process, not at the network boundary).

The code inside the API is an abstraction.

> you win the ability to upgrade/replace backend or frontend independently.

> you win the ability to develop with multiple independent teams because the connection between frontend and backend is smaller and easier to define.

> you win the ability to reuse generic backends over multiple projects...

None of these are really specific to SPAs, they apply to any architecture with a separation of concerns.