Yep, this is a thing I push with my team all the time. Always vet your deps. In the long run is is WAY worth it. In the short run the cost is rather minimal unless you have devs that cannot actually deliver on the needs the dependency covers.
Why I Don't Use React Router
11–20 of 79 posts
Re: Why I Don't Use React Router
#12We use React Router on our project. Looks like 4.0 does break pretty much everything. My thoughts on the upgrade are pretty much: - Do we actually need to upgrade? Old react router works fine. - If we do need to upgrade - how long will it take? If it's just a few hours to shift some code around, maybe it's not that bad. Especially if it's moving to a cleaner more "react" API. At the end of the day, we could write our…
> but save the upgrade for a day where we've got nothing else to do, or if an engineer has some free time.
Or when you stumble on a show-stopping bug right before a deadline, that is only fixed in supported newer versions.
Re: Why I Don't Use React Router
#13This is a very important dimension to consider when making technical decisions. I've never been able to find an easy way to assess this risk, beyond hearsay and word-of-mouth. Is anyone aware of an easier way to assess these longer-term risks of a piece of technology? Things like API stability, community strength and responsiveness, backwards compatibility, upgrade paths, etc.
It's hard. 1) Gain experience. 2) Talk to tech veterans and journeymen. 3) Look to other communities for lessons.
Re: Why I Don't Use React Router
#14I generally agree. I've been using RR for a while, and I'm not the biggest fan of their APIs. Nothing wrong with it, it just doesn't do what I want it to do; or rather... It does too much stuff, most of which I don't use. Just my opinion.
With that being said, they claim you'll be able to migrate slowly to v4, so hopefully it's not so bad. If they just broke backwards compatibility without a migration strategy, I'd certainly feel much more frustrated. I went with RR largely because it's widely used. I also don't think it's an unreasonable expectation for a widely used library to provide a migration strategy. Not that they're under any obligation to do so, of course.
My personal bar for adding dependencies is asking myself: would I feel comfortable debugging and fixing this? I recognize that it's not a free ride.
Re: Why I Don't Use React Router
#15This is a very important dimension to consider when making technical decisions. I've never been able to find an easy way to assess this risk, beyond hearsay and word-of-mouth. Is anyone aware of an easier way to assess these longer-term risks of a piece of technology? Things like API stability, community strength and responsiveness, backwards compatibility, upgrade paths, etc.
A large margin of safety / margin for error / margin for refactoring is the correct way to deal with uncertainty of any kind.
Humans are very poor at reasoning about low probability events that have serious consequences, i.e. large earthquakes with very long return periods.
For this reason, it's difficult to assess the 'risk' of external code because risk management processes don't work very well when high uncertainty is involved.
If you decide to use external code that has a high degree of uncertainty, just make sure to have a generous allowance of time/money/effort for future problems.
Re: Why I Don't Use React Router
#16It's great to someone express this point. Though it's hard to beat the convenience of dropping someone else's library into your codebase, each new dependency adds more security surface area and bloat to your application. I wish people considered this balance more carefully. In general I think a littlw NIH is a good thing. Even if there exists a library that does what you want, it might also include much more that you…
An idea of open source is that it's very likely that your own implementation is buggier, slower, and more poorly specified than the existing state of the art open source implementation. https://en.wikipedia.org/wiki/Wisdom_of_the_crowd https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
It's much easier to implement something for your application than something for a library. You have a specific problem in a specific context, but the open source library must solve a general problem in thousands of contexts.
Re: Why I Don't Use React Router
#17I recently started working seriously with node.js (I've tinkered over the years since it was launched, and we provide some support for it in our products, but never actually built anything with it). I went looking for a library to deal with logins, authentication, password resets, etc. Normal stuff that most web frameworks have some solutions for.
I found a package on npm that sounded like it did everything I wanted (plus a few extra things, but I figured I could ignore those). It took longer than I expected to install...so, I did a little digging. It had installed over 53,000 files, and the resulting directory was 110 MB in size!
I was absolutely flabbergasted. I couldn't believe installing one package, for something seemingly simple, could balloon up that large. I won't name names, as I did a little more poking around, and realized that most npm installations pull in thousands of files via automatic dependency resolution, though this one was a particularly egregious example. I've gotten to where I only install stuff via npm when I'm on a free connection; I normally work on mobile broadband, which is very expensive (and adds up to almost $300/month even before I started playing with npm).
Now, to be fair, it was pulling in a web framework...maybe Express or Hapi, I don't remember which, and all of its dependencies, so it was actually a lot more than just the login module. The kind of annoying bit was I already had a global installation of both of those frameworks from following tutorials, but it still seemed to insist on pulling in its own preferred versions of stuff, and putting them into the project directory.
I come from the Perl world, where if you don't spend at least half your time looking for and evaluating libraries before you start writing code, you're not being very productive. I'm, frankly, overwhelmed by how big and unfiltered the npm ecosystem is. I've found myself relieved to start tinkering with more "all in one" libraries and frameworks, because I don't have the time or knowledge to evaluate libs on my own. I ordinarily prefer a more a la carte approach, where you just pull in what you need, and so big libraries and frameworks don't fit that. But, I can't make sense out of the ecosystem without some guidance. There are over 70,000 npm packages! Curation really has turned out to be one of the big problems in computer science.
Re: Why I Don't Use React Router
#18Earlier quoted context omitted.
An idea of open source is that it's very likely that your own implementation is buggier, slower, and more poorly specified than the existing state of the art open source implementation. https://en.wikipedia.org/wiki/Wisdom_of_the_crowd https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Even if your code is better than the OSS alternative now, are you going to be able to maintain it at that level, given all of your other responsibilities? I'm dealing with a bunch of people now who did something like that. At the time they made these decisions they might have had good reasons, but now they're doing other stuff and the custom things they wrote are a huge liability. Don't write it unless you intend to…
I think a good heuristic is, is it your business?
I'd try really hard to avoid implementing address verification. Unless i worked at UPS or FedEx.
I'd try really hard to avoid implementing spellcheck. Unless i worked on Word.
If it's a core to survival thing, yeah, you should probably roll your own. If you can't beat OSS state of the art, well, you've got a problem.
The other heuristic i think is generally good, go for a couple of big dependencies over a whole bunch of small dependencies. Coping with the interaction between 3 huge libraries is so much easier than 100 tiny libraries.
Re: Why I Don't Use React Router
#19Justin I think you are conflating a couple issues here:
1). OSS critiques should be more polite
2). People are stupid for not doing due diligence
Secondly, it's already obvious people are responsible for their own projects. The motivation for stating the obvious seems to be to emphasize people should seek to blame themselves before criticizing others. Wrong. These things are orthogonal - Regardless of one's due diligence, it's perfectly acceptable, indeed beneficial, to critique OSS, when done in a productive way.
Re: Why I Don't Use React Router
#20I recently started working seriously with node.js (I've tinkered over the years since it was launched, and we provide some support for it in our products, but never actually built anything with it). I went looking for a library to deal with logins, authentication, password resets, etc. Normal stuff that most web frameworks have some solutions for. I found a package on npm that sounded like it did everything I wanted…
> I've gotten to where I only install stuff via npm when I'm on a free connection; I normally work on mobile broadband, which is very expensive
You could always use this:
https://www.npmjs.com/package/npm-proxy-cache
It caches the package listings and the packages that you download. It will act as a pass through that with a limited TTL on the cache, but there is an option to fallback to the cache if you can't connect to upstream.
Granted, you have to have already installed something for it to work as an offline cache.
Also, part of the problem with all those files is that npm allows packages to installed pinned dependency versions. If package-a requires lodash 2.x and package-b requires lodash 3.x, then both will be installed within the respective package's directory. For example let's dive into the node_modules/ in one of my projects.
$ ls node_modules/**/lodash.js
node_modules/cordova-lib/node_modules/lodash/chain/lodash.js
node_modules/findup-sync/node_modules/lodash/dist/lodash.js
node_modules/findup-sync/node_modules/lodash/lodash.js
node_modules/globule/node_modules/lodash/dist/lodash.js
node_modules/grunt-contrib-less/node_modules/lodash/dist/lodash.js
node_modules/grunt-contrib-less/node_modules/lodash/lodash.js
node_modules/grunt-contrib-watch/node_modules/lodash/dist/lodash.js
node_modules/grunt-contrib-watch/node_modules/lodash/lodash.js
node_modules/grunt-curl/node_modules/lodash/dist/lodash.js
node_modules/grunt-curl/node_modules/lodash/lodash.js
node_modules/grunt-legacy-log-utils/node_modules/lodash/dist/lodash.js
node_modules/grunt-legacy-log-utils/node_modules/lodash/lodash.js
node_modules/grunt-legacy-log/node_modules/lodash/dist/lodash.js
node_modules/grunt-legacy-log/node_modules/lodash/lodash.js
node_modules/grunt-legacy-util/node_modules/lodash/lodash.js
node_modules/grunt-ng-constant/node_modules/lodash/dist/lodash.js
node_modules/grunt-ng-constant/node_modules/lodash/lodash.js
node_modules/grunt-protractor-runner/node_modules/lodash/lodash.js
node_modules/grunt/node_modules/lodash/lodash.js
node_modules/jshint/node_modules/lodash/chain/lodash.js
node_modules/lodash/chain/lodash.js
node_modules/phantomjs-prebuilt/node_modules/lodash/lodash.js
node_modules/preprocess/node_modules/lodash/lodash.js
node_modules/protractor/node_modules/lodash/lodash.js