ccachor

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.

I'd also add, moving to components doesn't rely on DOM structure either (ex. $(this).parent().parent().find(:el)...)

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.

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.

"(whose idea of a standard library is adding an underspecified `fetch` after 15 years of people writing wrappers around XMLHttpRequest)."

So true.

Yes!!!!

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.

Is it really worth the trade-off? I remember eCommerce sites trying to do similar levels of interactivity with Flash too. I just think, for a catalog site, it seems like you're trying to swim upstream. Especially on mobile.

Web Monkey

Based on previous work experience, like-ability, references, and a take home exercise.

Ha! I've had to do a few of those recently. Unfortunately, they were the ones where you write code as the hiring manager watches.

Not a fan of those...

My understanding of full stack is frontend + backend web development. Sysadmin/devops is it's own discipline.