3 ms·

Not really. JS has no true concrete design patterns, no built in state handling, no built in tooling. Going straight into React/Redux isn't the best, because yo

Not really. JS has no true concrete design patterns, no built in state handling, no built in tooling. Going straight into React/Redux isn't the best, because you miss out on learning JS fundamentals, but it will produce a far more maintainable project due to the assumptions it makes and enforces. It also makes it easier for others to just jump in and make changes, given that they know x or y framework. You could not know any vanilla js and still probably make more long term maintainable code just based on how the framework is designed. Vanilla js would require the engineer to set patterns and make assumptions, something that junior devs might do incorrectly. You will reinvent the wheel and probably do it inefficiently unless you are a seasoned vet. Not only that but others who are not familiar with whatever homebrew stuff you have cooked up will not be able to just dive in and start putting pieces together without a fair amount of reading. It's not impossible, but hard with a large dev team. This is why frameworks exist, no? Don't get me wrong I hate the framework bloat and pace of frontend engineering but these frameworks do serve a very legitimate purpose. But this definitely goes against the JS hate trends as of late.

z3t4 10y ago
you also put on a backpack that cant be taken off. So once you no longer need it or want to put on another, it becomes a burden.
- 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 ago
    I 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 =)

z3t4 10y ago

you also put on a backpack that cant be taken off. So once you no longer need it or want to put on another, it becomes a burden.

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 ago
  I 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 =)