jQuery is used on over 50% of the top 1M sites in the world and is often synonymous with JavaScript, the language used to build it. jQuery’s steady increase in usage from the largest of websites to the smallest can be attributed mainly to it’s ease of use, ubiquitous and consistent support among browsers, and lightweight structure. Just as jQuery was borne out of a need to simplify JavaScript, browser standards have taken note of jQuery’s ease and started following suit with default functions which could ultimately cause the demise of jQuery itself.
Before jQuery’s birth in 2005, if a developer was using front-end code to develop a website (not Adobe Flash) he or she would need to write substantial JavaScript for the most basic functions. Something as simple as selecting a piece of text on the page and making it fade off the page would require a good deal of code and logic. JavaScript developers found themselves writing core functions to repeat tasks which we take for granted today.
The communal sharing of these most basic functions led to a JavaScript library called jQuery. This library distilled some of the most cumbersome functions in JavaScript down to a syntax that a non-developer would understand. Some of the core advantages of jQuery:
With such useful core functionality and simple syntax, jQuery has catapulted to the main spotlight within JavaScript libraries. However, a decade after its creation, jQuery could soon find itself replaced with native browser support.
When I first started becoming involved in web development, this was always an easy yes. However, I’ve come to realize that modern browsers are integrating upgrades at a blistering pace and that much of what was once the bread and butter of jQuery is now shipped with the browser. This means that developers can now slowly start using native JavaScript with less worry about cross compatibility amongst browsers. A great resource to start the weaning process off of jQuery is @adamfschwartz and @zackbloom’s simple site You Might Not Need jQuery. Personally, You Might Not Need jQuery changed the way I looked at jQuery. Since I learned jQuery before JavaScript, a life without jQuery always seemed scary and overly complex. However, with Schwartz and Bloom’s site, I have approached JavaScript with an open mind and jQuery with cautious skepticism. I try to only use jQuery when its benefits and simplicity far outweigh the workaround I would have to develop without it.
One instance of jQuery being replaced is through the slow rise of ECMAScript 5’s querySelector() and querySelectorAll() methods. While the querySelector() method is notably slower than its older sibling getElementById(), it has built in flexibility that comes close to mimicking jQuery’s awesome selector attributes. For those developers who are coming from a background of first learning jQuery, the new ECMAScript 5 methods for element selection prove to be an easier-than-anticipated transition. Once a developer is able to select an element on the page, the next step is often how to navigate through the DOM (Document Object Model).
Traversing through the DOM using jQuery is very straightforward once the underlying concepts of the DOM are understood. However, traversing through the DOM with plain JavaScript is not necessarily more complicated, but certain traverses can be uglier than the simple syntax jQuery provides. Despite a slight difference in syntax, a simple reusable JavaScript function can be employed to mimic the functionality of jQuery without the added weight of the entire library. While selecting DOM elements and traversing the DOM go hand-in-hand, jQuery’s animation methods stand apart from the other definitions the jQuery library offers.
With the introduction of ECMAScript 5 standards (and eventually ECMAScript 6), we are seeing a slow replacement of jQuery functionality with native JavaScript support in the browser for much of jQuery. So what’s different with animations? Well, it seems that CSS is poised for the eventual takeover of many jQuery animations functions. While it is still fairly early on this front, I predict that CSS will eventually offer near similar support for animations as that of jQuery.
Animations in JavaScript are no joke. Often times, animations require calculations and a good deal of knowledge regarding how a page re-renders itself. With the advent of CSS3 transition properties, CSS is slowly encroaching on these complex calculations with simple one line statements. Modern browsers now have built-in calculators to produce the desired effect as well as rendering support to ensure a smooth transition. This new baked-in functionality not only allows more complicated items to be easily developed, but—and perhaps more importantly—it can lead to a smoother and faster experience for the end-user.
Animations solely done in CSS is not without its controversy. It is universally known that jQuery’s animation engine is slow, however, some research has shown that other JavaScript libraries that focus only on animations have proven faster than the native CSS methods described above. While this research is valuable for today’s model of animations, I believe that CSS animations are the future. I think the transition of animations from JavaScript to CSS is only natural as CSS has to do with the rendering/appearance of the page, while JavaScript has traditionally been intended for functionality and DOM manipulation.
Traditional AJAX requests in JavaScript can be cumbersome and difficult to use if different types of AJAX calls are required. jQuery effectively cleans-up the AJAX calls and allows for them to be handled in a much more concise way. As outlined by Eric Rowell, jQuery AJAX calls can greatly simplify complex browser-server interactions. However, jQuery not only makes AJAX calls look cleaner, but also allows deferred functions.
Deferred functions in jQuery are powerful when used with AJAX as they will wait until data is loaded from the source before trying to use it: a common problem with JavaScript’s asynchronous nature. But jQuery’s deferred methods might be short lived. As detailed by Adrian Hall, ECMAScript 6 standards will ultimately allow for a native method of deferral for AJAX calls. While consistent support for this is several years away, this example is evidence of how native browser support is slowly chipping away at the foundation which jQuery has built.
I believe that time will force jQuery to evolve in what it offers to developers. As web standards become more advanced and united, jQuery will no longer need to provide the cross-browser compatibility it once did. However, I do believe jQuery is here to stay in some form. For instance, jQuery UI, which focuses more on user experience than replacement of utility functions, still has a strong life ahead of it. jQuery itself could also still be in use, although I believe the core library as we see today will become slimmer as browser support overtakes the necessity for jQuery.
While this post is just a brief look at how some core functionalities in jQuery are being replaced with different web standards, I really owe my understanding to the pioneers who have questioned the importance of jQuery. Todd Moto created a great resource that goes in depth and includes different aspects of code with examples. Of course, as mentioned above, You Might Not Need jQuery has been an ongoing resource for me as I explore different methods in my exodus from jQuery.