On Vanilla.js and js libraries

I recently came across the Vanilla.js site and I couldn’t avoid but to smile.

I have no idea who the authors are or what are their intension, but I think it’s a good reminder of the power of JavaScript for programmers coming to the language in these times of plentiful frameworks.

Blame the browser vendors.

The main reason for the proliferation of these libraries in the first place is the inconsistent implementation of the DOM and other browser specific API‘s by the browser vendors.

The secondary reason, but significant less important, is the different versions of JavaScript or ECMAScript.

This changed in the last few years with both Firefox and Chrome frequently releasing new versions.

If you remember the early days of Ajax (or even before that trying to do DHTML) you will have in mind the number of hours we spent creating our own libraries to encapsulate 30 or 40 lines of feature checking before calling that remote end point or inserting a new element into the document.

Some of this work started to get documented and shared in different sites and some of the first libraries started to pop out.

Prototype was one of the most popular thanks in great part to be bundled with Rails.

Even Microsoft tried to get into the js libraries for some time with Atlas, later re-branded as Microsoft Ajax something or the other.

JQuery was a bit like the horse that starts the race in the middle of the pack and starts to pick up ground little by little until suddenly is the leader and everybody is trying to catch up to him.

So, we should use libraries or no?

I think that you should be asking that question with every project.

I see how most of us now starts each project with a minimum set of libraries without taking a moment to consider if we will even need it.

I still think that for doing any non trivial UI js programing that needs to support a wide range of browser, you should try to use a well known library and save the time you would spend debugging the app to make it better.

But I think that at the same time we should try to make sure that we considered what are we going to do and bring the smaller library possible.

The future of libraries and client side js.

We are already seeing a tendency to custom build our libraries, pick and chose the pieces that we need; instead of just using a big, bloated, feature reach monolithic one.

Even established libraries are starting to provide custom build systems or moving towards that.

If your library of choice doesn’t had the feature, take it upon yourself to trim it down to only what you need.

This may prove to be more difficult than it sounds.

Or see if there is an alternative that provide that option.

Conclusion

The increasing popularity of assets pipelines and the already established practice of minifying and concatenation of code, in combination to the other tools already mentioned are indication of exiting times ahead.

Libraries are here to stay and that’s a good thing. Good libraries allow you to concentrate in the problem at hand. As with any language, you have to make sure to chose wisely.