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.
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.
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?
