6 ms·

Agreed. This is my main issue with the "you don't need frameworks" rhetoric. If you're a small team or a solo dev working on a simple app, and you know the sou

Agreed. This is my main issue with the "you don't need frameworks" rhetoric. If you're a small team or a solo dev working on a simple app, and you know the source code very well, frameworks might not be the best choice. However, if you've ever worked on a team of revolving contributors, constantly shifting requirements, or have any reason to reuse code across apps/repos, frameworks help immensely. The biggest benefit to using something like React imo, is that when we hire somebody familiar with React, they can hit the ground running and start contributing immediately. Unless your app is dead simple, you won't be able to have the same velocity in a homespun framework (and given enough time, most "vanilla" apps turn into homespun frameworks).

mettamage 7y ago
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).
- x3haloed 7y ago
  Not necessarily. Using popular frameworks will always widen the pool of contributors you have access to, no matter what "sector" your project falls under.
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 ago
    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.
    - mattmcknight 7y ago
      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?
- 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 ago
    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.
ricardobeat 7y ago
> 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.

mettamage 7y ago

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

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

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 ago
  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.
  - mattmcknight 7y ago
    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?
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 ago
  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.

ricardobeat 7y ago

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