[acqq]

So you want to have the URL for every content but you don't want to provide the content as HTML, instead expecting that once the page is by client, the client only then separately loads the content? Only because it's easier to you to program, you want to deliver me the content much slower than you can?

There is some strange logic there.

[marknutter]

Slower in some respects and faster in others. Suppose I cache the data I get back from the server for page 1 and page 2 of content. Now, if the user switches between page 1 and page 2 they don't needlessly ask the server for the HTML every time like they do when relying on the server to render templates.

And I'm not sure where you're getting that it's "easier to program" single page apps than it is to simply rely on the server to render html on the server. The fact that it's not easy is the very reason we have so many competing front-end frameworks to solve the problem elegantly.

[workhere-io]

The whole point is to make the experience better for the user: When going to each new page on the site only involves fetching a bit of JSON and not an entire HTML page including header, footer, JS, CSS, etc., that makes the user experience faster. Add to that the fact that since the front page HTML now no longer contains any dynamic elements (you would get those dynamic elements via JS), you can put your front page HTML (the one HTML page there is) on a CDN and get faster load times.

As for speed: Sure there are exceptions when developers go crazy with tons of heavy JS, but that doesn't need to be the case at all.

[Touche]

Only the first load is slower. If you click on any links within the page they will render much faster as you skip the whole full page load thing.