It took some time and flailing about in the community. But fortunately there was a relatively quick and massive structural change to programming large web front ends with compontent-based JS over the years.
Much like Rails, the problem wasn't the language per-se, but a broad consensus regarding the best approach and having structure community wide helps solve a lot of problems.
Now we finally have reached a pretty close consensus on the 'framework' side. Plus I'm also excited on the build systems side - as they are getting closer to just 'importing' other JS files instead of the endless magic of Webpack processors and similar hackery.
So with that area finally quieting down, performance optimization around SSR and pushing as much to the server-side in general is also finally reaching maturity. This is a critical piece of the puzzle. And probably the last major hurdle for serious performant JS-heavy frontends.
Heavily interactive web UIs are not going away no matter how many minimalist or anti-frontend-JS articles get posted on HN and elsewhere.
Countless SaaS products depend heavily on stuff we've had on desktop for ages (most legit critiques apply to miss-use-cases, not inherent issues). And their potential for serious interfaces with well managed client-side state, consistent abstraction layers with components, clean UI logic, etc, instead of ungodly spaghetti messes that were difficult for dev teams to manage - ones that would changed dramatically every time a new dev/manager was hired - or simply trying to hack full-on Rails style MVC but purely client-side (see: backbone.js), is finally coming to and end.
I'm personally a Vue, not React guy, but there's no question most advancements and experimentations happen in React's community first. Which a fine by me, as the good pieces always filter down to Vue quite quickly. SSR and deeper server integrations are clearly the way to go for any serious web app. The only downsides I've seen are they mostly JS server frameworks.