> when we hire somebody familiar with React, they can hit the ground running and start contributing immediately

This is one of the selling points, but never really realizable in a large scale project. I've seen people become productive with an in-house template system, vanilla javascript + custom libraries even faster than on a "standard" React project.

As they emphasize in their own docs, React is not a framework. The amount of moving pieces you need around it for a working project ends up being more complex than your cut-to-size custom framework. There are many other positives to adopting standard tools, but this one is a red herring.

We've adopted a framework as a small team and it has nothing to do with onboarding new people. We adopted it became clear that if we stuck with vanilla JS, we'd end up re-building something like jQuery to keep our code and abstractions manageable. And then we'd build something like React, while doing a much poorer job of it. Once your app has some "click X and A, B and C should update" logic you quickly descend into a tangle of tracking dependencies by hand.

> Once your app has some "click X and A, B and C should update" logic you quickly descend into a tangle of tracking dependencies by hand.

I managed to deal with moderately difficult scenarios with about 7 files in typescript. I ended up using webpack but that is a dev-dependency which doesn't really count.

I built this for me, but if you employ some basic patterns and use something that is a little more powerful than JavaScript it isn't that hard. I also very rarely ever use a DOM selectors in my JavasScript.

I don't particularly like frameworks these days because you end up spending more time dealing with the framework than actually getting things done.

You could learn to pick better frameworks. I can’t remember the last time I dealt with a framework bug in react and I’m working on multiple teams on about two dozen web apps. And that’s without including other jobs.

It sounds like you’re not really working on apps frameworks like react are supposed to deal with, (7 files of typescript) so why do you care?

> You could learn to pick better frameworks. I can’t remember the last time I dealt with a framework bug in react and I’m working on multiple teams on about two dozen web apps. And that’s without including other jobs.

I have used quite a few frameworks over the years and there is always some PITA issue you have to deal with.

> It sounds like you’re not really working on apps frameworks like react are supposed to deal with, (7 files of typescript) so why do you care?

You don't need large frameworks to scale something. You can just do it with applying the right patterns (that these large frameworks use) and get 80% of the benefit. However that requires (shock and horror), thinking for yourself and learning how things work properly.

Could you share this? I'm a backend developer and I just want to make light frontends with flexbox, grid and javascript. But it'd be nice to scale to more complex UIs also with a few functions.

Unfortunately not. However I can give you some pointers.

I've basically have an implementation of Observer Pattern, PubSub and I have written something similar to hyperscript.

https://github.com/hyperhype/hyperscript

https://webdevstudios.com/2019/02/19/observable-pattern-in-j...

https://codesandbox.io/s/vqq4vvxl20?view=preview

Just use vanilla JS to begin with. If your app has a lot of interaction, you can use React with create-react-app makes things easier.

You can still use vanilla JS, HTML and CSS. And it's not morally wrong.

Assess the requirements. Lots of moving parts and not a whole lot of time? React or Vue lets you draw the big lines quite simply. Need something simple or with fancy animations? Vanilla may be your best bet.

Personally I use vanilla for simpler stuff and React for more complex apps.

Don't worry, just make cool stuff. Nobody ever cares how you built it, just that it works.

Trello still uses CoffeeScript. It really does not matter as long as it works.

PS: You can combine if and when needed.

Most of the complexity comes from state management and tracking data dependencies, not dom manipulation.

If you like keeping things light this library gives you a lot of bang for the buck:

https://github.com/MaiaVictor/PureState

It's similar to how pub/sub works but it does the topological sort that prevents data with diamond shaped dependencies from being triggered twice, in less than 500bytes minified (before zipping).

"descend into a tangle of tracking dependencies by hand." What is your definition of "by hand"? What constitutes by hand and what does not constitute by hand?

My definition is declaring each dependency explicity. "A, B and C depend on D or E." Add a watcher on D and E to go update A, B and C. Repeat for every combination of dependencies. When app is complex enough I threw that away for a framework that tracked dependencies for me.

Sorry, I don't understand. How would the framework know what the dependencies are if you don't declare them, even indirectly in some fashion? In what sense are they dependent?

Isn't this also simply true in the corporate world in general? Frameworks and best practices of doing something means that things are standardized. Standardization means that a vocabulary is shared and people understand each other.

You want to make people as swappable as possible. At least that's how I look at it from a management perspective (not a manager, but one can dream).

Not necessarily. Using popular frameworks will always widen the pool of contributors you have access to, no matter what "sector" your project falls under.