Increase your dependencies
Not so long ago an article was written by Mike Perham named Kill your dependencies. Although I'm not a Ruby developer, I believe that he has some pretty convincing arguments.
However, there are some points I do not completely agree with. For example, the following generalization statement:
This post talks about Ruby but it’s true of every language community: Python, JavaScript, Java, etc. The scourge of dependencies spares no one.
In this post I'm going to be more specific and will explain why I use micro-libraries and why I think they are ( and hopefully will be ) a trend in NodeJS and Front-end development.
Isomorphic and cross-browser code
In the following paragraph I will explain why I disagree with the statement “true in every language community”.
These days JavaScript is being used on the client- as well as the server-side. We have packaging tools that produce different code for the browsers and for the NodeJS environment. However, the client-code is run in different JavaScript engines with different versions.
Why is it better for you to use a library instead of the native implementation? Because of the same reasons websites, such as Can I Use exist. Your implementation will probably be broken and will not work properly in every browser.
Something that jQuery tried to improve is now delivered via small micro-libraries, exactly because
we also want as less bytes as possible in our final bundle.js. jQuery was "The standard-lib" for
front-end, but now people are trying to avoid it. People prefer to use more dependencies which do
small tasks, than using one dependency that can do everything.
For me it's ten times better to include libraries such as superagent, HistoryJS instead of implementing this on my own in a way that works on the client and on the server and instead of using a massive jQuery-like library to do that single job.
Micro-libraries & micro-services
Today, more than ever before, I'm modularizing not only the code that I write, but also entire projects. I'm talking about building micro-services, instead of monolith apps. This trend gained enough speed to influence even the module maintainers themselves.
I still remember when
ExpressJS 4.x was released.
This was huge. The days that you could do npm install express --save and start
developing your app were gone. For using v4.x, you needed to install additional "middlewares" as
a modules, for various simple and popular features, such as :
parsing the request body,
adding cookies &
sessions support. This was the biggest
Keep it simple, stupid action in the NodeJS
community for that year.
Nowadays, its effect is multiplied. Using micro-JS-libraries is encouraged exactly because it's better to maintain multiple really small libraries than one huge monolithic "standard-lib".
Let's take this approach to writing applications, instead of modules. Do you really need the whole
MomentJS for converting 60000 to 1 min ago? Why don't you include
pretty-ms instead and keep it simple? Do you really
need Bluebird, because you miss Promise.promisify()
function? Why don't you use pify instead and rely on the
native Promise implementation?
By using a small library and keeping it simple, you will see less this method is deprecated, use
anotherMethod instead and feel safe, because you can actually read the source code of your
dependencies.
DRY
Every JS-developer that I know had a problem which resulted in copying & pasting StackOverflow code in his app. I'm worse. In my career I've been in a situation when I copy & paste the same code in more than one project, because I forgot that I solved that problem before. I'm talking about simple stuff, that I don't have time to reinvent such as Regexp for matching a color, Random number in range, etc.
This approach was working just fine, until one day those lines of code showed in the coverage suite of a project as "untested". Jokingly, I said to myself : "Hell yeah, they are - they have 500+ votes on StackOverflow.” Anyway, I decided to do a test and of course the code had a bug, so I had to change it and copy & paste it back to all of my other projects. Lesson learned.
From now on, instead of searching StackOverflow, I first look at npmjs.org :
Do you have something that is reused across all your applications? Something that is between a boilerplate and a part of the application? You can't outsource it, because it's too opinionated and specific or because it's not OSS? Make it a private npm module and stop pushing multiple commits for one bug in those projects. Modularize it!
Performance
JavaScript can be slow. Lots of effort is required to find the fastest way of accomplishing basic tasks, like deep clone and many others.
Sometimes using a library could make you significantly faster, than using the native implementation.
Tests
Ten years ago I was a perl developer. Perl has a thing about testing. It's almost mandatory if you release a library on CPAN.
Back then I learned that a single one-line function could lead to 50 lines of tests. On top of that writing tests for isomorphic code is hard. Running them on multiple browsers is even harder.
Let's face it. I prefer to use something tested, rather than believing that "it will work". Even if we are talking about one line.
Recap
- Writing isomorphic code? Use libraries.
- Writing front-end code? Use libraries.
- Many micro-modules are better than one huge framework.
- Search NPM, instead of StackOverflow.
- Don't be afraid of increasing your dependencies.
References & Further reading
Follow Sindre Sorhus and what he's doing :