4 ms·
I disagree. For a huge majority of projects and teams, it is infeasible to build everything in-house. The way I see it, you can either 1. take an extremely imp
by fullstackchris 5y ago
I disagree. For a huge majority of projects and teams, it is infeasible to build everything in-house. The way I see it, you can either
1. take an extremely impractical amount of time reinventing the wheel in house, or
2. take a (IMO a relatively much smaller) hit when you fail to take the 10 minutes to read the breaking changes on the dependency. Read this, make fixes, and everything is working again. If you hit a major issue like this with your own tooling, you're at the mercy of your team's ability to quickly build a fix.
A refined version of this point may be something like "only use dependencies which are very well tested, documented, list known issues, and have an active community of development and releases" - don't just install any package or library because "it appears to solve my problem"
- dustinmoris 5y agoMy point is take dependencies, just skip the magic ones because they are vile