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.
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!
