All of these monolithic libraries have one thing in common: they try to solve the same problem, and the scope of this problem is a big one. It’s not easy to provide a fully cross-browser environment and API for DOM manipulation, data crunching, class-based OO and more. And this shows in code bloat. These libraries are HUGE, being 100+ kilobytes in code size, and even minified and gzipped they are pretty big.
What’s wrong with that? A whopping 100% of sites or apps using these libraries don’t use all the features they provide. That wouldn’t be so bad if we didn’t have to transfer these libraries to the client every time. Some solutions exist for making it better (say, Google’s Libraries API), but it doesn’t really get down to the root of the problem.
Here is just a small selection of these micro-frameworks (this list is far from complete):
- Underscore.js (functional programming)
- Backbone.js (lightweight MVC)
- Qwery (selector engine)
- LABjs (script loader)
- Mustache (templating)
- JSON-js (JSON polyfill for older browsers)
- By yours truly: Emile (CSS animation), Zepto (WebKit-only jQuery API)
What you’ll find these libraries have in common is an emphasis on small download size.
Small code is good code: the fewer lines in your source, the fewer bugs you’ll have, plus it will download and execute faster.
And an other big advantage is that all the building blocks work stand-alone, which counteracts the this needs to be implemented as a jQuery plug-in for no reason
There’s even work being done on meta-micro-frameworks, like Ender.js that strive to provide a “homogenized” mix of useful micro-frameworks that gets you started quickly, but you can later cut off parts or replace modules.