Maybe the front-end (SPA) ecosystem, both in terms of technology and use-cases, just isn't stable enough for a Rails-type framework? I've only worked on a few

Maybe the front-end (SPA) ecosystem, both in terms of technology and use-cases, just isn't stable enough for a Rails-type framework? I've only worked on a few SPA's in the past years and every single one of them had some unique fundamental demands that led to some equally unique and fundamental differences in how the app was built. Maybe I'm just not creative enough, but I find it difficult to come up with one Rails-size solution that would've been useful for all of these apps. On the other hand, I remember when Rails took off, it seemed like an obvious batteries-included solution to a whole set of rather typical CRUD websites. Few random thoughts of things that make SPA's less 'standardized' and perhaps, at this time, less likely to benefit from Rails-size frameworks: - with SPA's you often have to work with the back-end that is provided to you. That's usually not an issue with Rails. - since the significant logic is now client-side (routing, etc), you have a large number of possible ways to synchronize server-side routing with client-side routing. - code size is an issue, so in some cases choosing a simpler solution for one part of the stack is necessary, plus for anything big you need to deal with code splitting and all that this entails. - performance is an issue so we can't just re-render the entire page. React and similar solutions have been one of the best improvements in this regard and take out a bunch of complexity (but add some of their own). With a non-SPA solution this is just not an issue. - browser compatibility is still an issue. With an SPA solution you need to consider all the same stuff as with a non-SPA framework, but now you also have to deal with things like javascript version support, event handling inconsistencies, local storage, animations, multiple forms of interaction (slide, drag&drop, etc.), loading indicators and potentially a whole bunch of async stuff. But perhaps most fundamentally: in a 'typical' Rails setup, the basic form of interaction is basically url -> page. It's turning one string into a bigger string. But in a typical SPA, there are tons of different types of interactions that lead to tons of different results. Any interaction with the page can mean: change state, send or retrieve something to or from server, save something in a cookie, go to a different page, load a different piece of content without changing the route, load content and animate to it (so simply navigating to a different route is not enough), and that's just off the top of my head. And you generally still need some kind of back-end on top of that with its own complexities and odd ways of interacting with your client-side code.