Is npm the new jQuery? 🔊
Npm could be going through something we’ve already seen before
If you work in the front-end nowadays, there’s one thing that comes to mind when starting to build something:
… there is an npm module for that
Does it sound familiar?
It wasn’t that long ago when if you had to build something, the answer was:
… there is a jQuery plugin for that
In the past, many developers from the JavaScript community were heavily driven by Cargo Cult Programming. There was this famous StackOverflow question (now defunct) which raised a funny discussion, in a time where jQuery was considered a Silver Bullet for all web development problems:
How to add a number to another number in JavaScript?
This satirical question perfectly shows how this “jQuery effect” was influent at the time.
Just so you know and to give a little bit of context, many years ago the DOM APIs were in a very bad state. There was no document.querySelectorAll
and the browsers implemented the existing APIs inconsistently.
jQuery was initially created to make it easy to traverse the DOM using JavaScript. But what it also did was to help to fix the existing browser inconsistencies and provide an easy way to be extended by plugin authors.
Those last things were never the core purpose of the library.
Instead of using it to extend the generic DOM handling functionality, some people started using the $
namespace to create widgets and full featured applications as jQuery plugins. The community was eventually caught up in the bandwagon and started creating jQuery plugins to solve all sorts of problems, including ones that were unrelated to DOM handling, like adding snow or gravity to the website, converting colors from RGB to HEX, etc.
This effect is similar to what we can observe happening today with npm.
Npm initially served as a repository of modules for NodeJS. However, now it’s being used by web developers to publish everything, from one-line modules to all sorts of plugins, libraries, and frameworks. It stopped being nodeJS oriented and became de-facto code distribution service for the whole web. Bower was supposed to be more web focused but was eventually killed by npm popularity.
When using jQuery, you had to copy/paste the code of the plugin to be able to consume it. Now with npm, the distribution of code for all “plugins” are automated through the registry. While that makes things more convenient, that convenience doesn’t come without tradeoffs.
The jQuery Plugins Site was just for discovery, not for code distribution. It’s been in a read-only mode for a long time, due to the de-prioritization and lack of resources to maintain it. It was recommended to be replaced in favor of the jquery-plugin
tag on npm.
Bottom line: we all depend on npm for code distribution now, even for jquery plugins.
Is npm the new jQuery Plugins site?
Most people love small snippets of code that works and have no problem of depending in a third party. This is evidenced by the sheer amount of popularity of the former jQuery Plugins and now npm.
However, people tend to overuse those tools and tend to build everything on top of it. Npm is becoming a silver bullet for distribution of code in JavaScript, the same way jQuery was a silver bullet for web pages.
Maybe this is a good thing, or maybe it’s not.
One thing for sure is that making your code dependent on a single technology can make it hard and risky for you to change it later once the technology becomes obsolete. If you put all eggs in one basket and it drops, you have lost everything.
I hope I’m wrong.
I hope there’s no tendency to overuse things and it’s everything in my head.
There’s a famous show that used to say “All of this has happened before and will happen again”.
Well… For npm, I hope it doesn’t…