I'd argue they're a lot worse. More often than not, these sites kill the back button or the ability to bookmark a piece of content, are slow on barely old browsers and devices (still using an iPad 1st gen), tend to have fixed headers and footers that needlessly take up screen real estate or crazy pagination solutions, override scrolling and make it choppy and dysfunctional as a result, or outright crash mobile Safari by triggering out of memory errors.
It's a small advantage, but it's enough for me to prefer it.
I appreciate the benefits of a 'batteries included' approach when, realistically, anything I build on my own is not going to have to horizontally scale across 50 EC2 boxes, although some of Rails's choices in terms of batteries are peculiar to me.
A full stack framework doesnt(and shouldnt)force you to use its view layer.I fail to see how it is overkill.
What is overkill is using different frameworks for an app that spits json and an app that spits html.A good framework shouldnt care wether you return one or the other to the client,that's exactly what Rails does.
I can see highly interactive sites switching, but most sites are not highly interactive and would have no reason to switch to an SPA. For any content (as opposed to interaction) heavy site, like a blog, I can't see any advantage of an SPA. Server rendered pages can be cached and served lightning fast. For an SPA, in addition to the time to transfer the page content and assets (which is required for both server and SPA apps), they have to load a JS framework and then render the page browser side. This will cause slower load times, so I don't see many sites choosing this trade off unless they are highly interactive.
Actually I suspect that a lot of these kinds of sites will primarily migrate to native mobile apps.
A full-stack framework is overkill as a backend for SPAs.
I'm not so sure. HTML rendering is a pretty small part of what a complex framework like Rails does. You still need a database/ORM layer, user management and auth, routing, caching, etc. The same things that make Rails productive for traditional web apps also make it pretty nice for building REST APIs.
Currently 99% of websites are not SPAs, but I think a lot of sites will switch to SPAs in the future, since they offer a better UX(no full reloads, more interactivity etc) in most cases. I'm sure customers will demand these sort of sites once they start using more SPAs.
> Why would you need a different framework for a "rest-backend" and a website that displays html?
A full-stack framework is overkill as a backend for SPAs.