ccachor's comments

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.

Pretty badass. In addition to Turbolinks, there is also http://instantclick.io that has the benefit of prefetch which helps with perceived snappiness.

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.

Probably except this one: A balance of technical, business, and social/emotional intelligence.

More than likely someone with this sort of technical capacity doesn't score well in other areas.

Really? At what point does basic become deep?

See my reply above...

I'm not sure you parsed the description correctly. They're not looking for someone with a mere grasp on these technologies.

=========================================================

* Deep understanding of front-end JavaScript development using libraries such as React, Angular, etc.

Deep understanding of means you know these frameworks and libraries well. If you know these libraries well, you're a front end developer. The title front end developer exists solely because people need to focus exclusively in this area because the job is both challenging and complex.

* Expert in CSS/HTML5

Ok, not too crazy. But I wouldn't expect the Bootstrap guys to know sysadmin tools.

* Deep understanding of development using either Python, Node, or Ruby

So in addition to deep understanding of the front end, we also want someone deeply skilled in a general purpose programming language. AFAIK you can't have a deep understanding without being deeply skilled.

* Desire to pursue AWS Development Certifications toward expert-level achievement

Ok, so sysadmin/devops guy.

* Experience with orchestration tools such as Ansible, Salt, Chef, or Puppet

Sysadmin/devops guy.

* A balance of technical, business, and social/emotional intelligence

Basically we want someone that can do it all. Don't let all those requirements break your confidence. Leave that imposter syndrome at home!

========================================================

I wouldn't say it's an unwillingness. It's just not realistic. There's a reason cardiology and neurology are separate fields.

This job description to me doesn't read as "we're looking for someone who's handy". They want three people for one job. To me it's a bit appalling.

I imagine it is a more senior role. While it's not uncommon somebody has "experience" in those items listed, it all comes down to what exactly that experience is. Dabbling in miscellaneous AWS services IMHO is a lot different from someone managing 11 billion requests/day and the challenges there.

So true re: binary search trees, merge sorts, and the like. I think web dev's need to realize their real world work has more to do with plumbing than it does dealing with programming puzzles.

Unless you're FB or operating at web scale.