The danger of lazy development
Too lazy is not always goodJune 07, 2019
It proved itself in the front-end field, as well as back-end with quite some success. And it’s now expanding into more fields like IoT and machine learning.
Bad code & performance
Many developers work on bad code daily. Bad code organization, insane requirements, refactor abandoned halfway, inexperience, the list goes on.
This is not only a problem for the developers working on the code. Almost every dependency has a cost in code size. Your end users are going to feel your application slowing down as its size increases.
Bundlephobia has a nice tool to analyze the cost of each dependency, give it a try with a few dependencies you use.
There are countless reasons why a dependency can become a problem for developers. Below the most common ones.
End of life is a grim reality in the world of open source. Projects get abandoned for many reasons, meant to be a draft, too much work, too little benefit, and so on.
Regardless of the reason, no package lives forever, no matter the owner.
Draft-js by Facebook has been drifting into nothingness for more than a year. There is currently no official alternative.
Splits in the community
Projects created to cover a specific need can struggle to find a new purpose as needs change. This often results in a split between the users. Forks start to appear with different philosophies in mind.
This can lead to developers jumping ship and having to rewrite important parts of their code.
Typescript-React-Starter by Microsoft is a fork of Create-react-app with Typescript added in.
It’s sometimes easier to rewrite an entire project than to fix it.
angularjs deprecated in favor of angular (2). Left the community in disarray, with many switching to other frameworks.
Some packages can get hacked, usually, pull requests adding malicious code.
Event-stream is a package with more than 1 mil download/week. A malicious dependency made its way into the project, hacking Copay, a bitcoin wallet.
Countless more reasons can make open source packages obsolete.
When considering adding a new package to your project, try to see the pros and cons of doing it without.
Will it cost more or less in the long run?
Is the community behind it stable?
Are issues resolved on time?
Does it often introduce breaking changes?
How much will it increase the size of my final bundle?
Not all packages are worth the cost, learning where the equilibrium lies is the essence of our job.
Using a lot of dependencies is not a display of skill. Focus on the language and use packages to enhance it, not out of laziness.
The lazy developer manifesto is a small guide on how to use laziness in a smart way.