6 ms·

I'm interested in your take wrt to the dependency hell GP mentions.

brundolf 6y ago
Personally, I: 1) Keep my direct dependency list slim and mostly limited to "too big to fail" projects backed by major companies 2) Avoid frameworks in favor of libraries I don't stress about indirect dependencies. If one of React's dependencies stops being maintained, or has a security problem or a bug, Facebook isn't going to not address it. Far too much money is riding on React as a whole, so whether they have to switch to a new dependency, or update the version, or reimplement the functionality themselves, they will. On top of this, the left-pad catastrophe can't happen again, because NPM publications are now impossible to remove after 72 hours: https://docs.npmjs.com/cli/unpublish https://docs.npmjs.com/cli/unpublish On the other hand I'm not going to add a direct dependency that I don't truly need. If it's a one-off function that I can write myself, or copy, I'll do so. On time I copied and pasted Lodash's debounce function into my codebase because that was all I needed, and I didn't want to bring in the whole library. Libraries, compared with frameworks, are easier to predict, to fill gaps in, and to replace if necessary. And even some things that we call ""frameworks"" like React can really be used as libraries. If you only use React as a rendering layer - what it's best at anyway - it actually has a very thin and elegant boundary with your code: you construct a data structure, and you hand it off. Others, like Angular and Aurelia, are truly frameworks and I tend to avoid them as a result. I wrote a blog post recently about the libraries/frameworks thing which got some attention/discussion here on HN: http://www.brandonsmith.ninja/blog/libraries-not-frameworks http://www.brandonsmith.ninja/blog/libraries-not-frameworks
- speedgoose 6y ago
  There is a NPM package lodash.debounce if you only want this feature from lodash. Lodash is available splitted in many small packages.
  - _bxg1 6y ago
    The point remains, though, that I avoided an unnecessary dependency. I copied that function once and never needed to mess with it again, because it was 15 lines and I could verify personally that it did what it needed to do. For contrast, we wanted to be able to incorporate new versions of React, because it isn't a simple enough thing that it can be written once and be done. It evolved, and offered real improvements in terms of performance and useful features. As in all things, there are costs and benefits to making something an external dependency or not. The key is to realize that there are indeed tradeoffs, and that outsourcing every single thing you can isn't necessarily ideal.
  - entropicdrifter 6y ago
    Right, but his point about that was essentially: "Why depend on that as a dependency rather than just have a copy directly in my project that I know will never behave any differently?"
    - speedgoose 6y ago
      Because it's one line to a dependency with a name, a documentation, a bug tracker, many users, and that could be improved in the future. If you are scared about packages behaving differently, you should know that npm has lock files that describes your full dependency tree with versions and checksums.
      - majormajor 6y ago
        "Could be improved in the future" is a risk when it comes to a simple utility function that does a simple thing that you don't want to change. In the same way that someone constantly tweaking your utility functions in your own project would be a risk - and you'd understandably want to code review all that - the more you choose to (or have to) outsource "trivial" stuff, the more brittle your project is.
        ioseph 6y ago
        Hence the lockfile, on the flipside if you've copy and pasted source across which contains a security update you'll most likely not realise
  - snovv_crash 6y ago
    In any other package ecosystem you'd be laughed out of the room for suggesting to add a dependency for a 15 line function, instead of just copying it into your codebase. And the 15 line function here is a fairly major function. People add dependencies for 2 or 1 line functions!
- elagost 6y ago
  "one of React's dependencies" Which one? There are... several. (someone posted this here a while ago, and it's lovely to look at) http://npm.anvaka.com/#/view/2d/react-native http://npm.anvaka.com/#/view/2d/react-native
  - _bxg1 6y ago
    The point is that it's not my problem. Those things, together, comprise "React" as far as my application is concerned. React being a huge project which millions of dollars have been poured into, and which billions of dollars probably ride on, is going to be kept working, one way or another. As long as it continues to provide a functioning interface for my code, that's all I care about.
    - noobermin 6y ago
      The problem isn't just what you see, the problem is sustainability for the whole ecosystem as a whole. FB has a lot of money but how do you know they won't determine at some point this is not sustainable and in two years you have to learn some other framework?
      - _bxg1 6y ago
        I don't know if you realize how massive the React user-base is at this point. That would be like saying, "how do you know they won't determine at some point python is not sustainable and in two years you have to learn some other language?" I mean, I guess. But even in that scenario, I'm sure the hundreds of companies who depend on it would pick up the slack.
        deleted 6y ago
        [deleted]
        wolco 6y ago
        It happened to Angularjs. It didn't die just stopped evolving in the 1.x branch. Everyone had to accept 2.x or move on or stop evolving.

Personally, I: 1) Keep my direct dependency list slim and mostly limited to "too big to fail" projects backed by major companies 2) Avoid frameworks in favor of libraries I don't stress about indirect dependencies. If one of React's dependencies stops being maintained, or has a security problem or a bug, Facebook isn't going to not address it. Far too much money is riding on React as a whole, so whether they have to switch to a new dependency, or update the version, or reimplement the functionality themselves, they will. On top of this, the left-pad catastrophe can't happen again, because NPM publications are now impossible to remove after 72 hours: https://docs.npmjs.com/cli/unpublish https://docs.npmjs.com/cli/unpublish On the other hand I'm not going to add a direct dependency that I don't truly need. If it's a one-off function that I can write myself, or copy, I'll do so. On time I copied and pasted Lodash's debounce function into my codebase because that was all I needed, and I didn't want to bring in the whole library. Libraries, compared with frameworks, are easier to predict, to fill gaps in, and to replace if necessary. And even some things that we call ""frameworks"" like React can really be used as libraries. If you only use React as a rendering layer - what it's best at anyway - it actually has a very thin and elegant boundary with your code: you construct a data structure, and you hand it off. Others, like Angular and Aurelia, are truly frameworks and I tend to avoid them as a result. I wrote a blog post recently about the libraries/frameworks thing which got some attention/discussion here on HN: http://www.brandonsmith.ninja/blog/libraries-not-frameworks http://www.brandonsmith.ninja/blog/libraries-not-frameworks

speedgoose 6y ago
There is a NPM package lodash.debounce if you only want this feature from lodash. Lodash is available splitted in many small packages.
- _bxg1 6y ago
  The point remains, though, that I avoided an unnecessary dependency. I copied that function once and never needed to mess with it again, because it was 15 lines and I could verify personally that it did what it needed to do. For contrast, we wanted to be able to incorporate new versions of React, because it isn't a simple enough thing that it can be written once and be done. It evolved, and offered real improvements in terms of performance and useful features. As in all things, there are costs and benefits to making something an external dependency or not. The key is to realize that there are indeed tradeoffs, and that outsourcing every single thing you can isn't necessarily ideal.
- entropicdrifter 6y ago
  Right, but his point about that was essentially: "Why depend on that as a dependency rather than just have a copy directly in my project that I know will never behave any differently?"
  - speedgoose 6y ago
    Because it's one line to a dependency with a name, a documentation, a bug tracker, many users, and that could be improved in the future. If you are scared about packages behaving differently, you should know that npm has lock files that describes your full dependency tree with versions and checksums.
    - majormajor 6y ago
      "Could be improved in the future" is a risk when it comes to a simple utility function that does a simple thing that you don't want to change. In the same way that someone constantly tweaking your utility functions in your own project would be a risk - and you'd understandably want to code review all that - the more you choose to (or have to) outsource "trivial" stuff, the more brittle your project is.
      - ioseph 6y ago
        Hence the lockfile, on the flipside if you've copy and pasted source across which contains a security update you'll most likely not realise
- snovv_crash 6y ago
  In any other package ecosystem you'd be laughed out of the room for suggesting to add a dependency for a 15 line function, instead of just copying it into your codebase. And the 15 line function here is a fairly major function. People add dependencies for 2 or 1 line functions!
elagost 6y ago
"one of React's dependencies" Which one? There are... several. (someone posted this here a while ago, and it's lovely to look at) http://npm.anvaka.com/#/view/2d/react-native http://npm.anvaka.com/#/view/2d/react-native
- _bxg1 6y ago
  The point is that it's not my problem. Those things, together, comprise "React" as far as my application is concerned. React being a huge project which millions of dollars have been poured into, and which billions of dollars probably ride on, is going to be kept working, one way or another. As long as it continues to provide a functioning interface for my code, that's all I care about.
  - noobermin 6y ago
    The problem isn't just what you see, the problem is sustainability for the whole ecosystem as a whole. FB has a lot of money but how do you know they won't determine at some point this is not sustainable and in two years you have to learn some other framework?
    - _bxg1 6y ago
      I don't know if you realize how massive the React user-base is at this point. That would be like saying, "how do you know they won't determine at some point python is not sustainable and in two years you have to learn some other language?" I mean, I guess. But even in that scenario, I'm sure the hundreds of companies who depend on it would pick up the slack.
      - deleted 6y ago
        [deleted]
      - wolco 6y ago
        It happened to Angularjs. It didn't die just stopped evolving in the 1.x branch. Everyone had to accept 2.x or move on or stop evolving.