Downsides of choosing popular tools
Nobody questions a programmer’s decision of choosing the most popular tool, but does that mean that this choice comes with no trade-offs?
You have probably heard enough about all of the advantages, that’s why I’ve written this blog post only listing downsides, including the ones people might usually see as benefits.
Large ecosystem
The more tools emerge around a popular tool, the more choices you will have to solve a problem. That will cost time to evaluate options and it increases the risk of betting on the wrong one.
Inexperienced developers are more likely to solve problems by adding dependencies instead of finding solutions themselves, which prevents learning. This might help in the short-term, but is bad for them and your company in the long-term.
Large ecosystems tend to form dependency packages. Tools recommend or implicitly require other tools, which leads to depending on more code than initially planned.
Dependencies cause complexity. One might think that discipline could prevent us from falling into this trap, but it doesn’t, because complexity is incremental.
Complexity comes about because hundreds or thousands of small dependencies or obscurities build up over time.
John Ousterhout
The more choices an ecosystem offers, the more opinions you will find as well, which brings us to the next bigger topic:
Large community
More people means more communication needs to happen. Unfortunately this includes ill-informed opinion pieces and people following dogma. Or you find blog posts with completely opposite opinions, which makes decisions harder.
If there are a lot of meetups and conferences happening, not all of them can be informative or inspiring and allow you to form personal connections. So you need to find the events which are worth it.
A higher number of people increases the likeliness of new ideas. Since only very few inventions turn out to be valuable, it means there will be a lot of bad ideas too.
Lots of job opportunities
There will be more competition.
As an applicant, there are more people with the same knowledge.
As a company choosing the most popular tool is a lost opportunity to stand out.
Companies also miss out on those senior developers, who have felt the pain of using that popular tool in production for a long time and have found a better one. They will go to the company that offers them to use that instead.
Mature & production-ready
Depending on the financial support of the tool, your bug report/issue might be one of many and can lead to a slow response time.
Having lots of users means that the tool will get constant feedback. This feedback will result in new releases, which therefore come in higher frequency. This includes breaking changes. Your code will need to handle these to stay up-to-date with the rest of the ecosystem.
To stay popular tools need to find a balance between supporting new/upcoming hardware/software and being backwards compatible to not lose existing users. In case your software is only relevant for one side of the spectrum that balance comes with complexity.
Since that tool is used by a lot of users, it will need to run in more contexts and cover more cases including the ones your code wouldn’t need to handle. These decisions can lead to a less coherent API design and they increase code size and obscurities, hence complexity.
Conclusion
I hope these downsides could show you that there are a lot of reasons, which speak against choosing the most popular tool. It doesn’t matter, if that decision is about languages, frameworks or libraries.
In the end evaluating options before making a decision is one of the most important responsibilities we have as programmers. Therefore don’t stop questioning choices from time to time, so that you continue growing as a developer and prevent following dogma.
The most dangerous thought, that you can have as a creative person, is to think, that you know what you are doing.
Bret Victor