jQuery & others vs. Vanilla Web

disclaimer: although debating the usefulness of full-featured libraries in general, the arguments are based on many aspects of the most popular one, jQuery. They should still hold mostly true for the other ones.

A very interesting conversation just happened as Christian Heilman proposed the idea of a book about modern Web authoring without libraries such as jQuery. It turned into a heated debate between Vanilla Web and full-featured libraries supporters. It is obvious that both sides share the common goal of improving the Web and helping Web authors, they also both have valid arguments to defend their vision.

I personally don’t know where to stand so I tried to list the arguments that have been raised by libraries and Vanilla proponents there and in other places.

File-size. Size does matter?

jQuery weighs around 32Kb minified and gzipped. At the time of writing, the average weight of a page is 1 239Kb and it only keeps increasing. The size of a single lib appears to be insignificant and a developer should first look into image compression and lazy-loading to reduce the payload.

Average page size: 1239Kb

On the other-hand, it is quite common to pick UI components that requires jQuery UI, some Bootstrap plugins and Raphael based visualizations. Soon enough, the file-size of script and style-sheet dependencies can become significant. Using CDN hosted libraries (from Google’s CDN or cdnjs) increase the chances for these resources to be loaded from cache, but version fragmentation mitigates that benefit; and modular builds aren’t available for the libs that allow it (jQuery UI, dojo).

Conclusion

Most of the time, using one library in a website isn’t a problem, but dependencies can add up to the point where their size becomes a problem.

Performances. It’s how you use it.

There’s a funny “Speed Comparison” table on vanilla-js.com that shows how far better document.getElementById("test") performs compared to jQuery("#test"). That is undeniable, but what matters is that any code outside hot loops doesn’t need the extra-speed; that best-practices can help avoid most bottlenecks (use event delegation, modify class names instead of inline styles, …); and that libraries benefit from many clever optimizations that are not always found in Vanilla code.

Conclusion

By using best-practices, it is possible to write code that performs equally well with or without libraries. The opposite is true.

YAGNI vs. Don’t Reinvent the Wheel

A single UI component doesn’t need all features exposed by generalist libraries. There might even be a lot of useless features for an entire application: code for backward compatibility with IE6-7 (e.g. a selector engine), JS animations or complex XHR. All libs have switched to a modular architecture, but their granularity will never be good enough to bundle “just what this component needs”.

On the other hand, there are still many features offered by these libs that aren’t trivial to implement even when targeting the most recent browsers: delegated event listener, node-list looping, white-listed DOM builder or offset getter, to name a few. Embedding those features into a component isn’t reasonable: developers need reusable, reliable, documented and maintained utilities implementing these features. Isn’t it what our current libraries are?

Conclusion

Current libraries are bloated… but they’re so useful and their level of quality so hard to match!

Moving the Web forward.

Time spent rewriting features already available in current libs is time not spent building tools that have never been seen before. And time spent learning about low-level DOM stuff is time not spent learning about the tools that can improve productivity.

But as the Web changes, being able to question the way websites are built is fundamental: “Can I adopt a gracefully degrading approach and use CSS here instead of JS?”, “How hard would it be to implement X when targeting only IE8 (or 9) and better browsers?”. If this leads to better websites and tools, who would complain?

Conclusion

Learning what picks one’s curiosity is a good way to move the Web forward, whether that is low-level or high-level knowledge doesn’t really matter.

General conclusion

Including a full-featured library or sticking to Vanilla Web in a project shouldn’t be a reflex but the result of a well informed choice. A good lib will still prove useful in most cases, but I personally appreciate all efforts to build lib-independent components that give developers the ultimate choice of using a library or not.

You see additional reasons to use full-featured libraries or to leave them behind? Feel free to share!

4 thoughts on “jQuery & others vs. Vanilla Web

  1. Miller Medeiros

    I feel that the modularity of current libraries isn’t good enough. The fact that you need to load the whole lib to use just a few methods isn’t optimal, of course you could use Google Closure compiler to remove the unused pieces of the code or use custom builds, but that doesn’t work well in all cases and it can be hard/tiresome to configure it right. Having this problem in mind was one of the biggest reasons why I decided to code [amd-utils](http://millermedeiros.github.com/amd-utils/) and also why I use AMD modules on almost all my projects.

    There is a huge advantage on using abstractions instead of the actual browser API, consistency. If the API changes in the future or something new/better shows up you don’t need to update everywhere on your code, you just replace the “adapter” code. Nicholas Zackas gets into more details on his free ebook [The Problem with Native JavaScript APIs](http://oreillynet.com/oreilly/javascript/radarreports/native-javascript-apis.csp) – highly recommended reading.

    1. louisremi Post author

      More modularity is certainly good, but this is shouldn’t be done at the cost of quality. I’m currently very interested in all efforts on that matter so I’ll have a look at your project.

Comments are closed.