There is an astonishing amount of JavaScript code to be found in today’s web pages. It is mostly business code, but there is also JavaScript code that is needed for web infrastructure: For example, any ASPX Web Forms page comes with some JavaScript, but in this case it has little to do with the business logic of the page and is only there for ASP.NET Web Forms infrastructure.

JavaScript has many merits when it comes to improving at least the perceived performance of web sites. What you do with JavaScript generally takes place within the browser and rarely requires interaction with the server. Because of this, the performance of a browser-based application is limited by the hardware, whether a desktop PC, a laptop or some kind of mobile device.

This steady increase in the amount of JavaScript begs the question ‘How much JavaScript is it safe and sane to have on a web page?’ In this article, I’ll try to summarize the arguments for, and against, increasing the use of JavaScript.

How Much JavaScript Do You Actually Need?

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.

In consequence, large chunks of the jQuery codebase deal with the logic that is necessary to unify DOM and CSS operations across browsers. Much of the JavaScript code that you download in your web pages is required only for ensuring cross-browser compatibility, and is never called from your code, even indirectly. This raises a more general point. Are developers using anything near the full range of functionality that is available in the JavaScript libraries that they reference?

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.

Why should we worry about loading JavaScript that isn’t necessary? Is the amount of JavaScript linked to web pages the real problem here?

The Case for Size

The download size of most commonly used JavaScript libraries today is not particularly significant for performance if you use minified and g-zipped versions, and you have a good internet connection. All in all, we’re talking about a few dozen KB. The entire Twitter Bootstrap library, including CSS and JavaScript code, sums up to 100 KB. This isn’t much more than a typical image. It’s a relatively small amount compared the overall size of some pages exposed by sites with heavy graphics.

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?

The downside of any JavaScript library for the web developer is not simply in the time it takes to download: There is also the time it takes to initialize and the time the developer needs to become familiar with it. The time it takes to initialize depends on the final memory footprint as well as the internal working of the library, which most typically involves setting up a number of events and related handlers. This has an impact on the actual performance of the page and, maybe more importantly, on the perception of speed that users have.

The advantages of using just one big library is that It takes one request to download, one chunk of time for setup and it is one API for developers to learn. How would you select the one library from the various alternatives then? Well, that depends on what you need to do within the various pages, whether you need touch gestures, dynamic DOM updates, CSS switches, data binding, navigation support and so forth. It may not be easy to find a single library that can support you for all of those things. The jQuery library was for quite some time going to be just the one-size-fits-all JavaScript library.

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

Where you are designing a site that seeks to attract Mobile traffic as well as desktop devices, you simply can’t afford to load a full-fledged, monolithic JavaScript framework, especially if you want to target more than just the top iPhone and Android devices. Still, it’s useful to be able to leverage the services of some ready-made frameworks. Today, most smartphones and nearly all tablets are powerful enough to happily survive some SPA implementations, especially if you manage to reduce the number of use-cases to support on smaller screens. Nevertheless, if you assume that your mobile users have good bandwidth, you’re likely to have a nasty surprise. However fast their device is, the users won’t appreciate your site.

There seems to be much less attention nowadays to making web services consumable through all devices including legacy devices, and slow ‘broadband’. In a way, it seems that either you go mobile with a high-end smartphone or table, and blazing-fast urban broadband, or you won’t be able to use many services. It seems that it is the developers who make this assumption of high-quality connectivity and browser-performance, but it doesn’t often survive the impact with real business and real users. You can be confident that those sites packed with JavaScript code that interact with their users locally via JavaScript generate a lot of work for the CPU on the device. While such a CPU is powerful, it is not in the same league as a laptop or desktop. Even if it was, the entire hardware platform is not the same. As a result, too much JavaScript definitely affects the quality of mobile access, even if the broadband speed allows it to be downloaded quickly enough. It is in these cases that JavaScript micro frameworks come to the rescue.

Micro-JS Frameworks

The major problem of JavaScript development today is there are too many different ways to do the same thing, and each different way is offered as a standalone framework. Inevitably, a given framework will offer only 99% of the features that one expects or needs, so a developer feels inspired to set up a new Github project for building yet another project that does the missing 1% and even more, but also misses some of the remaining original 99%. This is the perverse mechanics of JavaScript proliferation today that I like to refer to as “The 99% Syndrome.” Micro frameworks don’t really help stop the proliferation of JavaScript frameworks; quite the reverse I’d say. But at least these newly-added frameworks are really small and, once bundled in a single HTTP request properly g-zipped, they reduce the download and memory footprint. This typically happens at the cost of some extra development work; but as a fellow developer always reminds me, ‘we’re developers in the end; and we’re just paid to write code’.

There are quite a few JavaScript micro frameworks out there and their capabilities range from all sorts of DOM manipulation (for input forms, text, Ajax, events, canvas) to CSS manipulation and animation. A micro framework is usually around a size of 5 KB. In the end, if a micro framework can effectively do the job you need, why not pick it instead of adopting a larger but all-encompassing framework? Micro frameworks have pros and cons and these are asymmetric to those of full frameworks like jQuery or Angular.

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

I stopped making web-related predictions the day I realized that Silverlight was gone. I would have bet the farm on Silverlight and I would have lost. My bet on Silverlight and C# within the browser was inspired by the obvious need for more and more powerful interfaces over the web. Instead of this need being met by compiled and binary technologies such as Silverlight, it has been met by HTML, CSS and JavaScript. To me, it doesn’t seem smart compared with Silverlight, which I saw as the first step on the way to being able to write C# code and have it compiled to create better interfaces in the browser. With an eye on vNext, the idea can be expressed in terms of being like having Roslyn in the browser.

Having been proven wrong once in my forecasting, I now don’t feel so sure what’s in store for web developers; but I still feel confident enough in saying that the fastest web site is still the web site that places the fewest HTTP requests, downloads smallest files, and caches data properly. To get this, the primary issue is not so much the amount of JavaScript that you download, but how relevant it is to the code you’re writing. That’s why I think that micro frameworks are gaining ground.