Comment by brundolf | Hacker News Reader

Comment by brundolf | Hacker News Reader

Parent Full thread

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

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

There is a NPM package lodash.debounce if you only want this feature from lodash. Lodash is available splitted in many small packages.

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.

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?"

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.

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

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

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!

"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

That's react-native. React (http://npm.anvaka.com/#/view/2d/react) does have... several: 5 of them.

Guess I'm wrong then! Thanks for the correction.

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.

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?

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.

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.

That React has a lot of dependencies isn't a problem in itself. At this point, React is stable. It's backed and relied upon by a gigantic company called Facebook. It's used by millions of developers around the world.

If there's a major problem with one of React's dependencies, it will be promptly fixed.

React doesn't have a lot of dependencies. The person you are responding to linked to React Native, which is an entirely different thing.

I think it's a bit misguided to think that code quality won't be visible to users. As someone who has used both React and React Native, the quality of these two projects from a user perspective is worlds apart, and I have little doubt that their different approaches to dependencies are partly to blame for that.

That's not React, that's React Native.

Reply on news.ycombinator.com