Like many software engineers, I oftentimes get caught up with wanting to learn about the next new thing without critically evaluating whether it's worth the effort learning and using. Even if I don't end up using it, it can still be a time sink to read about every new tool that's out there. As many people on Hacker News have lamented, the Javascript world especially seems to churn rather quickly.
So I have decided to create a set of heuristics for picking the next xyz dependency for the latest project. In other words here some general "rule of thumbs" that I've decided to follow for myself:
- Popularity is important, but not the most important thing. Of course popular libraries and frameworks like jQuery and Angular have gotten big for a reason, but you shouldn't pick them solely for that reason or even primarily because of that reason. You should pick the right tool for the job, which sounds so obvious, but it's easy to forget about this in your pursuit for using the latest library. For example, Meteor.js is very powerful real-time full-stack Javascript framework, but unless you're creating a web application that has demanding real-time capabilities (e.g. a task management app like Asana, which incidentally inspired the Meteor framework), it's probably an overkill.
- Pick the simplest tool that gets the job done. Having used Angular for a little bit now, I have a more balanced perspective than when I first heard about it and started using it. The two biggest benefits of Angular in my mind is that it enables you to write web apps more quickly (e.g. two-way data binding, powerful HTML templating) and has testability baked into the framework. The biggest problem that I have with Angular is that it's a very complex framework with many concepts that are significantly if not radically different than vanilla Javascript and its documentation is not that... wonderful. When you have too many abstractions built in a framework, you end up learning about the framework itself and less about the underlying language.
- Sidebar: For example, if you read the ngTransclude documentation (https://docs.angularjs.org/api/ng/directive/ngTransclude), unless you have a solid understanding of transclusion to begin with, you are probably scratching your head. On the other hand, I think Facebook has done a very nice job of providing accessible documentation for its open source libraries. When Flow Type was released, on day one it had a very comprehensive of documentations and a few tutorials. This leads me to my next point...
-
Pick a library that has good test coverage and ample documentation. Why do I care about these two things? They usually are markers for a library developed and maintained by a responsible team. Sure, you can have lots of documentation and still have a clunky tool with an awkward API, but at least it shows that the maintainers at least put effort into making their tool usable by others. The same thing with test coverage. You can have 100% code coverage and still have a buggy software, but I'm willing to bet that any library with less than 50% code coverage probably has many, if not at least a few bugs. Some libraries like Lodash really emphasize code coverage and boast 100% coverage (https://lodash.com/) but my general belief is that ~80% is already pretty good.
-
Licensing - stay legal. I'll keep this brief, but if you're doing proprietary software development and you want to use open source dependencies, you'll need to be careful to avoid certain open source licenses or you might run into some legal troubles. See my earlier post: http://willchen.posthaven.com/open-source-licenses
-
Lastly - don't get stack in analysis paralysis. When I was first learning about CSS, I spent days reading about articles discussing the differences between Less and Sass. Eventually I decided to use Sass because I had a subscription to CodeSchool and they had some pretty well-developed tutorials on Sass specifically but not Less. In the end, I think the few days I spent researching the differences could have been better spent just writing toy projects in either of the language. After a couple hours of researching and analyzing the different options, I think it's time to just pick one. After all, once you learn Sass, it's a lot less hard to pickup a similar precompiler language like Less or Stylus.
Hopefully this guide helps. And as I started out in the beginning, these are really just 'rules of thumbs', so don't feel like any of these are unbreakable rules.