4 ms·
I'm not saying it's a silver bullet, and it should not be treated like one. But everyone here is a fairly experienced dev. Working with junior devs is difficul
by jorblumesea 10y ago
I'm not saying it's a silver bullet, and it should not be treated like one.
But everyone here is a fairly experienced dev. Working with junior devs is difficult, especially frontend devs who usually lack comp sci fundamentals.
Frameworks provide structure to what would normally be an absolute spaghetti mess, even at the cost of overhead. I would rather have bloated but maintainable code. It's hard to even unit test vanilla js properly. Those who rail against the current framework world forget how bad the vanilla world was...spaghetti code, no real design patterns, terrible class design, no standard lib...the list goes on :(
It's frustrating that the counterpoint to the "framework everything" crowd is the "never framework" pattern. Both are bad for different reasons right? I would never want 10+ devs working on the same project without some kind of framework, either homebrew or open source. But also running react for your tiny little dev blog is equally bad.
- z3t4 10y agoI buy your argument about frameworks providing structure. And most software projects are a untestable spaghetti mess, it's not because of vanilla JS though, spaghetti code have been written in many different languages. The problem is inexperienced engeneers, and old design patterns in school books, like Classes ;) I've been designing software for over 15 years and here's some tips that works well for JS and probably other languages too: 1) Avoid code couplings, if you keep couplings at a minimal, you only have to test the code once and it will never break. 2) Modular code: All dependencies should be contained! Dependencies should be branched, not entangled/complexed 3) Independent functions: Functions should not have any dependencies from the outside scope, not even other functions if possible. Use lexical modules and sub-functions. 4) Event listeners: Have independent "micro services" that listen for events instead of orchestrating. 5) Abstractions: Make it possible to use functions/modules without knowledge about the abstracted code. 6) Avoid state =)