Well, Angular has a very heavy initialization penalty, enough that I know of a few companies that ditched it for React. I'll also add, as your front-end becomes more complex and uses a number of different libraries, the bundle becomes huge. There's ways around this of course, but some of pure JS stuff can get ugly quick.
It is more maintainable (in the sense that functionality isn't bound to the DOM structure or class names). I'd argue there's a bit less repetition across your app, but it's not as significant if you're smart about code re-use.
Front-end frameworks are going to give you a few things: more control over routing, more "app" like behavior, instant state changes (easily done), and most of all: your front end isn't going to be DOM driven. Lets say you're tasked with redesigning an admin area and one really ugly area are forms. Rather than having the logic and styling bound to classes, that functionality is bound to a component. So, for large front-end applications the maintainability can be tremendous. I would say the big 3: maintainability, app like routing, and instantaneous state changes (across diff portions of your app) without doing much work.
With Rails 5, you get the benefit of both. You're not doing your backend in javascript, but it plays nicely with modern front-end libraries and frameworks.
> most of all: your front end isn't going to be DOM driven
I get this and all - but I also want to make a strong case for letting the traditional DOM manage application state.
Putting a "component" abstraction between what is being rendered on the front-end often feels like increasing complexity for perceived developer ergonomics and future-proofing your application. The only time I agree with this abstraction is when there is a clear need for insane complexity on the UI - something I actively try to hedge against during design phases. High UIX complexity generally means crap user experience/design.
Also - I would argue on how many different ways do we need to address a front-end component + tie data to it..? We've got ID's for singular selection, classes for group selection, HTML5 elements, name attributes, data attributes, etc etc. Yes, I understand that this conflates the UI DOM node's functionality (JS) and styling (CSS) but I've never felt the need to decouple that since they're both addressing/manipulating the same DOM; Which is what I consider the canonical state representation of the front-end.
Well, it would probably be built into the insurance carriers' web stack. Dev teams need to keep up with the latest tech so they don't lose talent and can justify ever increasing salaries. So I think that's part of the reason you're seeing things move towards client side.
And you're right that most sites don't see traffic numbers to justify exotic AWS setups. I personally think most web businesses grow pretty linearly, so the focus on "overnight" scaling problems is more of a sales tactic than it is reality.
I do think you're underestimating the amount of companies that do need these tools, though. It's not as binary as "insurance broker" and "Facebook". Logistics companies, payment processors, restaurant groups, grocery stores, etc. all have pretty complex backend services and some of these tools are critical to even compete in their industries.
Regardless of hits, React is designed for UIs that need to "React". That's the motivation behind the library. It's better suited to social networking applications than it would be to say an eCommerce store or a dashboard CRUD web app. You can still use it of course, but you probably won't be getting any of the main benefits because there's not much interaction with VDOM.
Thank god for speaking up about this. This whole thread has me contemplating a career change. I'd rather dig a hole and fill it back in. The OP is pondering what framework to use for the front end. How about you do the design/css/copy then worry about the framework.
I think the main problem is everyone insists on over engineering a fucking website.
