sure but there are very few websites in the world that need to publicize an api, basically only sites that need to be able to function as applications. once you have a site that needs to be an application arguing for it to be single page is not that great a leap.

Sure, I meant to make the point that developers are drawn to SPAs for more understandable reasons than just being a bunch of lemmings.

Also, it's hard to realize how much work a SPA actually entails until you get your hands dirty. SPAs generally sound great on paper from a technical standpoint.

If you have a mobile app, you need an API, even if you‘re site does not function as an application.

The great majority of websites, though, DON'T need a mobile app; they need a website that works on mobile. Most smartphone users are unwilling to download more than a few apps for websites, anyway; if your website is a restaurant, a news source, or anything else that works well on a website, most users are unwilling to download and install your app anyway. So, if you want their business, you need to make your website work for mobile. Once you have done, that, in most (not all) cases, you don't need to develop an app anyway.

unless you use Turbolinks with IOS/Android adapters or another hybrid app alternative

exactly that. since 2012 i build all my websites as SPAs for this reason. more so, i am not even writing any new backends. i reuse the same backend over and over. most websites (at least the ones i have been building) are just CRUD and don't really need a custom backend.

SPAs bring back the client-server architecture we had before the web. you build desktop clients that consume server-api's.

server-side html generation now feels like cruft and an awkward way of building applications.

It should be trivial to build a server-side client app in the same manner, using an API for any persistence instead of directly accessing the database. Most of the full-stack frameworks (Django, Rails, Laravel etc) are unfortunately still conflating the persistent state entities with business logic objects.

you are of course right. there is no stopping anyone from doing that. in fact the university which initially developed the backend i am using has been doing just that, using the backend like a database, creating "frontends" in PHP.

though that doesn't negate the point of SPA which enables building clients that run directly on the users devices and are not hampered by the difficulty of emulating stateful clients on a server.

You are falling into a comfortable trap where it is easier to do the same. If you took the time to learn laravel your development time can be cut in half.

the backend i have is of course written in such a framework. (it's not laravel[0], but it could be)

i am not trying to diss backend frameworks here as bad. any of these would be a good choice for the backend.

the point is that thanks to SPA and CRUD i get to reuse that same backend over and over with little or no modification. (modifications amount to fixing bugs and very rarely adding new features to the API)

my backend development time now is effectively 0!

[0] (i have been working with laravel, django and others (primarily roxen and pike) before, and while i am not a fan of php, i did find laravel pleasant to work with)

You can do this with a non-SPA website just fine if the website's backend is the API client. Sure, it adds an extra layer of indirection between the browser and your data, but if the separation of concerns is really your goal, then that's probably as good as it gets.

Well, with a SPA, 0% of your website may be rendered on the server just like your other clients. That's basically the defining feature, though of course they can be rendered on the server as an optimization detail. They even still use AJAX, so I didn't quite understand that bit.

I'm not sure what you meant with the rest of your post. There are technical upsides to having zero web client presentation logic implemented on the server at all. But it's just trade-offs.

Maybe you're suggesting with your "grunt work" comment that most complexity for most applications lives in the UI rather than the API? I'd agree. It's why there are upsides to keeping UI implementation off the server.

I just like to avoid the HN cargo cults of "this = good, that = bad" and "the people who do $X are probably incompetent."