Angular vs Ember. RSpec vs Minitest. Haml vs Slim vs ERB. You have so many choices to make when you start a new project. There are vocal defenders on each side. And soon you start to realize that you could have started your project in the time you’ve wasted reading that fourth tutorial or 30-comment argument about whether Sass is better than Less.
So how do you choose the right library, so you can start writing actual code?
You’re under some serious pressure
The development community moves really fast. New libraries appear every day, built to solve all kinds of problems. Many of those solve problems that have already been solved before. And many of those are built as reactions to the libraries that came before.
These debates get personal. People have spent part of their lives building experience using these libraries. Some have been burned by the problems their new favorite libraries were built to solve. So the arguments for using a particular library are passionate and emotional.
When you read all these passionate arguments, it’s easy to feel like you’ll be looked down on if you make the wrong decision.
How do you get comfortable picking a library?
It’s clear that not everyone will agree with the choice you make. The best you can do is be personally satisfied with your decision. You’ll have to be happy with the library you choose on a technical level, as well as a personal level.
On the technical side, I wrote a guide to picking the right gem for your projects, and most of that advice holds for any of these kind of choices.
Your personal preferences will also factor into your choice. Without building an app that uses the library, though, it can be hard to predict which library you’ll prefer to use.
GitHub’s code search can help you make those decisions. When you search for some class names from the libraries you’re thinking of using, you can find projects that use each library. (You can usually get those class names from the README or gem documentation).
From the code, you can see how the library is used, how well it integrates with the code and other libraries, and how simple it is to use. This helps a lot, especially when you don’t have enough context to make a decision based on technical arguments.
Does it even matter?
Making the wrong choice can cause you some pain later on. But when it comes to building software, Failure 0 is failing to start the project. Spending too much time picking the right library for your app does nothing to help you prevent that failure. Most of the time, making any choice will help you much more than making the wrong choice hurts you.
You shouldn’t feel bad about the choices you make. There’s nothing wrong with learning new libraries, trying them out on projects, and making personal and technical judgements about which libraries you prefer to use.
Even if you change your mind later, the things you learned from the library you chose will always stay with you. You can learn a new library much faster as a diff against your existing knowledge than studying it from scratch.
A long time ago, I could have just as easily become a Pythonista instead of a Rubyist. I may not have been quite as happy with it. (Although honestly, who knows?) But I’d still be writing code, and I’d still love it.