4 ms·
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
by sgustard 7y ago
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.
- mattmcknight 7y ago"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?
- sgustard 7y agoMy 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.
- mattmcknight 7y agoSorry, 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?
- uk_programmer 7y ago> 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.
- nsomaru 7y agoCould 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.
- uk_programmer 7y agoUnfortunately 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://github.com/hyperhype/hyperscript https://webdevstudios.com/2019/02/19/observable-pattern-in-javascript/ https://webdevstudios.com/2019/02/19/observable-pattern-in-j... https://codesandbox.io/s/vqq4vvxl20?view=preview https://codesandbox.io/s/vqq4vvxl20?view=preview
- adrianhel 7y agoJust 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.
- DEADB17 7y agoMost 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 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).
- ulisesrmzroche 7y ago