This article is homage to jQuery – a library that once was a great boost for the productivity of thousands of web developers around the world. In the near future, the benefit of using it will drop as web developers start switching to the web standards, including Web Components.

Status quo

As of early 2014, the current state of interactive web development heavily relies on established web standards – HTML, CSS and JavaScript, all of which have been subject to consistent iterative improvement during the last few years, with the support of all major web browser vendors.

As a W3 Techs report shows, 57.8% of all websites use JavaScript, of which a stunning 93.2% use the jQuery library to enhance the development (source). There is a long tail of other libraries and micro frameworks that are being used instead, or in complement to jQuery, but none of them have reached the popularity of jQuery.

jQuery has become the library of choice for the past seven years by providing three major advantages:

  1. Levels the differences between major web browsers – now replaced with consistent JavaScript and CSS implementations
  2. A simple, easy to learn API – now replaced with JavaScript and CSS additions
  3. Extensive plugin ecosystem – currently facing the possibility of being replaced with Web Components

Levels the differences between web browsers

In the times when Internet Explorer 6 ruled 90% of users’ desktops, the web developers were in desperate need of maintaining code that worked both in Internet Explorer and web standards-compliant browsers, such as Mozilla Firefox, Opera and early versions of Google Chrome.

jQuery since day one aimed at providing a consistent API that behaved the same way in all the browsers, handling each browser’s quirks internally. This was a huge relief for the developer, who no longer needed to care about implementation details of a particular browser. It led to a significant reduction of testing and bug fixing.

Since the release of IE10, all the major browsers support the web standards to the extent that lets them pass the Acid1Acid2, and Acid3 compliance tests.

What once was a great a major selling point of jQuery has become no longer significant; hence jQuery 2.0, released April 2013, dropped support for IE6-8 which resulted in 15% file size reduction and admittedly the loss of one if its original purposes.

A simple, easy to learn API

jQuery introduced a much simplified syntax over the regular JavaScript. With its short, multifunctional methods and the chainable flow of execution, it was possible to replace dozens of lines of JavaScript with just a single line of jQuery.

jQuery’s expressive syntax has given inspiration to many APIs that are currently part of the standard JavaScript and CSS, being now natively implemented in browsers.

Other websites cover this in higher detail, but I will name just a few that mostly used jQuery methods that now have a native implementation in browsers:

  • jQuery’s $ function that finds elements in DOM using CSS selectors is being replaced with standard querySelectorquerySelectorAll
  • jQuery’s addClassremoveClass methods are being replaced with standard classList
  • jQuery’s eachfiltermap methods for array traversing are being replaced with standard forEachfiltermap
  • jQuery’s animate method, mostly used to move the elements on screen, is being replaced with more powerful and efficient CSS transitions

Using the native implementation of the above features means better performance and interoperability, so it is recommended over jQuery where possible.

Extensive plugin ecosystem

One can’t argue that jQuery provides currently an unbeatable collection of plugins that implement behavior and UI elements used in websites and web applications. The official jQuery Plugin Registry holds more than 2,000 plugins, which is likely not even 10% of all jQuery plugins circulating around the web.

A jQuery plugin can be inserted to any website given that:

  • The web developer loads the jQuery and the plugin file in the HTML <head>.
  • All plugins on a page need to use the same version of jQuery; otherwise it gets very tedious (though not impossible) to integrate them.
  • The web developer adds some JavaScript to the page to enable the plugin. Usually they also need to add some ID or class names to the elements where the plugin needs to be executed. If the webpage content is dynamic (something is created on screen after the page is loaded), the web developer needs to make sure that the plugin will also work on the dynamically created elements, which is not always straightforward and requires learning how the plugin works.

Web Components share some of the above steps but in a simpler way:

  • The web developer loads the shim library (such as Polymer) and the HTML import in the HTML <head>.
  • All Web Components on a page need to use the same version of the shim library. Given that the shim library implements agreed standards, it is more likely that upgrading the library will not break the existing code.
  • The web developer adds a custom element to the page, most likely without a single line of JavaScript. This is very important for the novice developers. Also, because of being first-class DOM members, custom elements may be dynamically added to the website and will work as fine as if they were included during the page load.

Summary

With a background in jQuery development, I have an appreciation for its contributions to web development. However, as with any technology, jQuery is quickly becoming outdated as new innovations replace or improve its elements and methods. Web Components include upcoming standards for web development, and can offer developers a simpler and more efficient way to code. To learn more about Web Components, click here: Introduction to Web Components.