One thing my job hunt taught me so far is that React is all over the place (surprise!), except at large companies that have in-house front-end teams working on their own sites. Those companies prefer vanilla JS over frameworks. Interesting, isn't it?

Recruiters always ask for React, because their clients do. Still, it seems React is mostly added to the skill list by their clients' "full-stack developers" (i.e. Java people), who don't necessarily know a lot about front-end.

We're currently allowing non-front-enders to take crucial front-end decisions, and their silver bullet is React. (Used to be Angular, will become Vue.) The very fact that they're still looking for silver bullets is maybe the most serious problem we have in front-end right now.

Perhaps, but this is free market demand resulting from delivery on business objectives. Employers aren't hiring for the art of it...

My point is that employers trust back-end developers more than front-end developers when it comes to front-end decisions, and I think that has a negative impact on the state of their front-ends.

Perhaps, but when frameworks are as prevalent in the market as you're observing, shouldn't we consider that the approach advantages...

...for the business, and isn't just the result of a systemic bias toward the opinions of BE developers?

Ah, but who tells the business people what kind of business impact specific technical solutions will have? Senior developers, i.e. back-end developers. Business people almost never have the technical skills to decide for themselves.

Why would that be your assumption? The market's not making wild guesses, it's a significant sample size of completed projects....

I have no great faith in the Market as an objective arbitrator, I must admit. What we'd have to compare is two very similar sites, one created with frameworks and one without, and see which one performs better - also in the sense of page speed, which hugely impacts conversions.

I have this data *in spades*. Not looking good for the folks who blindly hire for framework skills.

Any chance any of that data might be opened in the future? That would, like, really help. Not that you didn't know that already.

I run a large site (3M monthly uniques) and I'm about to move us to Vue from vanilla+jQuery

Generally I see it in consultation with sites pre-launch or early in their process; don't want to shame teams.

Contra @stubbornella, I don't see framework use link with "top talent"; it's nuanced.

Specifically, I see a strongly bi-modal distribution. A tiny fraction are amazing and would thrive w/ any toolchain...

...those teams adopt FWs but also take them apart and put them back together in leaner, meaner configurations.

Those teams also tend to have a bias toward less-opinionated stacks (because rebuilding/reconfiguration).

For the other side of the distribution, those choices are *toxic*. And that's basically everyone.

Most folks aren't using frameworks as an accelerant to what they know they wanted, they're using them as a level-up. Access to a higher tier

...but they don't know what they don't know, so when the community leaves things as an exercise to the reader, it's pure perf/UX #fail

*this is nearly every app I trace* Opinionated stacks are better for nearly all, but not "cool".

For ~every team in '17, starting with a framework and not an opinionated starter-kit that gets build, code-splitting, etc. right is 🤦‍♀️🤦‍♀️

Unless the framework is one of the heavyweight desktop-era dinosaurs, FW choice not hugely important. Architecture matters more.

The point of a framework is supposed to be one that encapsulates architectural best practices, but that’s lost on most.

Most frameworks do this at the component level, not app structure level. It's when things scale up that they go to the dogs in these traces.

I always suggest teams start with tools that set them up for success. Most don't.

What is an example of a starter kit you think works well?

Polymer App Toolbox (polymer-project.org/2.0/toolbox/) and Next.js w/ Preact (github.com/zeit/next.js) jump to mind.

Wego.com is what makes me happy on a regular basis: webpagetest.org/video/compare.…

Something like ~200KB of critical-path resources to get to interactive, granular resource loading, killer pre-caching. So good.

The kicker? Built by 1 engineer in 3 months...and that engineer _hadn't done web development before_. Previously an Android dev.

Is the experience perfect? Nope! Is it better than 95% of traces I see and done for a fraction of the cost? Yuuuuuuuuuuuuuuuuup.

Wouldn't want you to do that, but could you write something with anonymized data? "E-commerce site X uses React; Y uses vanilla JS; we saw that X's time to first render is 170% of Y's and we estimate this loses them 1,000 transactions per day."

Framework could be the correct choice, would be interested to see diff between companies, one backend driven and other front end “driven”...

Framework might be same, but perf optimizations, progressive enhancements, responsiveness and a11y will be more present in one of them.

back end teams tend to go more for developer convenience then customer happiness.

It’s logical as well, as on the backend, developer convenience has less of an impact on customer happiness.

also, backend tend to develop for a ‘stable’ platform, as front end knows that everything can break on the client side and develop for that.

Impact is more likely to be reported by program managers or project managers than any type of developer.

Performance gains vs time to market / developer time. I'd go with lowering time to market first and address performance when it's an issue.

It's fine to be a craftsperson, but also, these people need to have jobs and pay the bills.

I would also hedge bets on framework developers to address performance in the same way that browsers do and not try to prematurely optimise.

This doesn't match my experience at all as a front-end person who has brought React to or used React at many places.

It's obviously fine to not like React or think it objectively bad, but please don't invent a sociology to label people who disagree.

I've found the opposite. Backend folks I've worked with liked stateful OO solutions like Backbone. Took effort to make them use functions.

INB4, yes, I wrote old-school JS code. Know how to use prototypal inheritance. Still would use plain js for individual projects.

But if you need dozens of people to work on a UI together, it helps to have React, or a home-made component system that implements the same.

The sad truth, is there are more frontend devs out there that know gluing some thing in a framework than using prototypes which is worse

They probably trust the most (only) senior person in the room who happens to be a back-end developer. Which is a rational thing to do.

Can confirm. Had a job converting a KO app to ng. It had been religiously adhered to for years. Was a nightmare to decouple.

Who do they pay more? That’d validate your theory.

I kinda agree... Backend and frontend paradigms diverged a bit lately.

There could be arguments for pros of native over frameworks, and React specifically, but they would need to be quantifiable in biz terms.

I so agree. even after 22 years of experience I have to do stuff a 25 year old back end developer has decided without enough knowledge.

How do you address your concerns? Why don't they have any impact?

Time to market, cost of developers, integration costs: these would seem to favor frameworks. Even a11y is reasonable in React.

I would like to see solid numbers and figures that support that position, preferably controlled for the experience level of the front-end developers. I mean, if you're an excellent front-ender you don't necessarily want to work in an environment that doesn't value your knowledge.

Sure, but if I can pay a Jr. dev to deliver on my objectives with a framework, why would I pay a Sr. dev to deliver on them without one?

The idiocy is in thinking that the story ends when you do the first delivery.

All the more reason to use frameworks that abstract towards your goal and get fixes and improvements without your involvement

A senior dev can deliver a feature way faster and better than a junior dev. Using frameworks or not. It all depends on the kind of devs

And that's an extreme example, but what's the measure of "excellent front-ender" if not quantified in business objectives?

Never seen a serious study that even comes close. But if you find one I would love te read it.

You can practice your craft for the sake of the craft, or you can sell your skills to an employer, but seldom both at once.

Consider that a Front End developer or Web Designer is completely secondary respect to a Pure Back end Programmer. Design matters!!!

Nice to have my assumptions (I'm on the inside of a big org) confirmed. Been very suspicious of React/Angular.

I don't get it. What are the assumptions and what is your suspicion?

Biggest assumption is that they are not sustainable for a large code base. And suspicion I'll jump in at the wrong point!

Read thread by @stubbornella

Food for thought, thanks for the heads up.

I think we have finally cleared out all the Fortran...

You're welcome. I understand the concerns!

Isn’t everyone looking for a silver bullet at some point?

Yep, people seem to often be looking for the ‘shortcuts’ to skip ‘boring’ parts of development, even though those parts make the difference!

people still don’t see front end as ‘proper’ programming and tend to downplay the actual problems. tools can’t solve those.

Yep, 100% in agreement. I have no issues with frameworks or tools, just with using them willy nilly

Backenders already know from experience that self made scripts will grow and grow and will eventually bite you.

Everybody hates js, but it’s part of the web, and it’s fine to build websites relying on it. Frameworks help, we use them in every language

Another way to look at this is that small teams without a very experienced front-ender now have a better way to achieve high quality results

The prediction doesn’t follow. React is the most programmatic of the three, that explains why it is more popular. Vue fills the space of $

It’s only natural to look for a silver bullet. The real problem is back-end folks making decisions for front-end. Seen it so many times...

are they actually using vanilla JS, or have they just built their own, proprietary framework which is now entrenched?

Vanilla JS === proprietary framework there's no way around that

Not always. I think there's a big difference between some lightweight helper functions and a full-fledged framework. Yes, sometimes people reinvent the wheel. But not always. There's an in-between.

Don't know yet. But proprietary frameworks are a step up from React and the likes, since they're amenable to change. And they specifically say "vanilla JavaScript" in their job openings.

Seems logical to me. When I was at an agency it was easier to experiment with new tech cos of frequency of new projects and shelf-life

Not that surprising. Large companies invested in rolling their own JS ahead of frameworks being released. Wonder if they’d change now?

I haven't found such a place. Big companies use Angular in my experience. I also met one switching to vue. So no clear conclusion here

Everything you talked about are very small data sets. Depends largely on type of company, product and rest of tech stack.

Yup. When asked about angular, people use argument, that it allows writing fe apps on so called enterprise level.

Sure, but it seems back-end developers have an outsized influence on the front-end stack, even when they know little about it.

BigCo’s are slower, as always, in picking up new tech. What’s new or interesting about that?

My place has a sizeable pro-React front-end team, backend devs generally couldn’t care less about frameworks we use.

I'm working in a large company with different products. We have an in-house front-end team (in fact, I'm in the enablers team) and we're using React. It's helping us a lot in so different ways. 😀⚛️