Whether you like it or not, jQuery changed a lot of things in web development. Not only has jQuery made it simple to edit the state of the DOM to the point of creating and deleting nodes and changing CSS style sheets, but it also unified the API to perform most of these tasks.
Before jQuery, Web standards were quite evanescent and nearly each browser felt it had the right to implement its own way of doing the same things.
It turns out that jQuery, for example, requires about 30 KB of download once minified and g-zipped. Do developers need all of it? Other, more specialized, libraries (notably, jQuery UI, Angular and Bootstrap) take a module-based approach. The codebase of such libraries is split in distinct modules and developers can download and link from their web sites only the modules they really need. This is a step in the right direction; but the real effectiveness of such a modular approach depends on the level of granularity at which modules are created.
The Case for Size
For a desktop site, nobody really notices the effect of having a few hundreds of kilobytes in script code because those script files are then locally cached by browsers rather than being downloaded over and over again with each and every request. By using Content Delivery Networks (CDNs) effectively, even the initial download of libraries is a breeze.
But if size is not the main issue, does that mean that we should always go with a full-fledged framework such as Angular, Bootstrap or both, in a single download request?
Next, the advent of Single-Page Applications (SPA) revealed that jQuery had one key drawback which was also voted as its best strength: plugins. The jQuery library doesn’t offer all functions that a team of developers may need, but plugins are easy to write and form a rich ecosystem that covers almost any piece of functionality one may need. There is something of an embarrassment of riches here, which means that selecting the right plugin can be quite a task for the team. This is made worse by the fact that jQuery was missing support in key areas of modern pages such as data binding, navigation and rich UI components. The consequence of this was firstly the creation of jQuery UI and, later on, Bootstrap and Angular.
It is difficult to avoid having to use them all, which isn’t a problem for web sites that are visited mostly through desktop browsers; but what about mobile devices?
The Case of Mobile Devices
Micro frameworks are very small, probably fast, and surely going straight to the point. You can mix up many of them together, whilst making sure that you likely end up loading just the code you need, when you need it. With jQuery or Angular, you bind yourself to a huge library that certainly offers what you need, but likely also a lot that you don’t use; Worse yet, with Angular you also choose an unusual programming paradigm that renders your code almost unusable if have to switch away from Angular. Angular illustrates some of problems of too close a reliance of a particular framework: The recently-announced breaking changes with Angular 2 triggered a negative reaction from people who perceived that large chunks of their existing Angular investment were apparently ‘legacy’ overnight, for no good business reason. A framework publisher such as Angular can decide to refactor the code without introducing any obvious benefits, but merely in order to make the framework better designed and architected. If these are breaking changes, the users of the framework are faced with the difficult and unpleasant choice of updating their code for no business benefit or staying with the current version, at a risk of being bound to a framework no longer supported and declared obsolete.
Just because micro frameworks are small and direct, the task of replacing them with a new version of the same framework or an analogous framework is much less painful. In a way, it could be said that a micro framework applies the principle of single responsibility that we may know from object-oriented code. A micro framework does one and only one thing; if it’s referenced in a web site it’s because its features are really used somewhere.
To form an idea about what using a micro framework can be, and the micro frameworks available, I invite you to visit http://microjs.com. There you will be a long list of frameworks for very specific aspects of web site programming such as responsive images, observers, promises, modal dialogs, data binding and much more.
Wrapping Things Up