Listen to the audio version!
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
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.
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.
Another satirical answer of a StackOverflow member, in the same thread. It’s written “I think there is a jQuery plugin for that. Google for jQuery basic arithmetic plugin”. There are two comments below. The first is “yeah. jQuery is definitely the way to go” and the second is “I used the jQuery diet plugin and lost 10kg in a week”. The answer is upvoted 4 times.
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.
A masterpiece. It sings that “if you want to do anything, there is a benalman.com jQuery plugin for that”. Ben Alman is a former jQuery contributor, he coined the term IIFE and built the “Grunt” task manager.
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.
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…