No More jQuery

May 30, 2019 - 7 minutes reading time

jQuery is a neat thing. It has lots of useful little things like DOM-manipulation, AJAX and bad-performing animations. I used jQuery since my early days of developing frontends because it allowed me an easy foot in, and there were always tons and tons of plugins that used jQuery.

For many things that in jQuery were solved with a single line, browsers didn't have an equivalent alternative. That is completely ignoring cross-browser compatibility. jQuery united all browsers into one codebase. You didn't have to implement certain things in a certain way for the script to work same in Safari as it did in Firefox. An example for making code more understandable is AJAX, asynchronous exchange of data between browser and server. Let's look at an example of sending the contents of a form and reacting to the response:

// Post form data in native JavaScript via XMLHttpRequest
document.getElementById('button-submit').addEventListener('click', function(e){
	var formData = new FormData(document.getElementById('form-signin'));
	var xhr = new XMLHttpRequest();
	xhr.open('POST', 'https://example.com/signin');
	xhr.onreadystatechange = function(){
		if(xhr.readyState === 4 && xhr.status === 200){
			console.log(xhr.responseText); // When all wenn through
		}
	}
	xhr.send(formData);
});

Das selbe dann nochmal mit jQuerys POST-Methode:

// Post form data via jQuery
$('#button-submit').click(function(e){
	$.post('https://example.com/signin', $('#form-signin').serialize())
	.success(function(data){
		console.log(data); // When all wenn through
	});
});

The jQuery solution is not only shorter, but easier to understand, because there's a clean API that shows us what will happen in what order. Additionally, jQuery will automatically detect an XML or JSON-formatted response from the server. In the data-variable we get a JavaScript Object with which we can work without parsing it manually.

Generally speaking jQuery is a win-win: You don't reinvent the wheel and get lots of small helpful pieces of code for shorter notation for often-used functions. It's also so widely used, that caching the .js file is no problem by linking to jQuery hosted on an often-used CDN, like Google's.

That's all well and good, but still my website didn't reach 100 points for mobile devices in the Google PageSpeed Insights test. Granted, 98 is almost perfect, but a lightweight page such as mine should be able to make it to 100. So I went on the search for a solution.

Searching for a solution

I quickly noticed that jQuery was taking a pretty long time loading from Google's servers, at least relatively compared to the rest of the page. The at this point dated version 3.3.1 weighs around 30KB compressed with gzip, uncompressed it's about 85KB. First of all this is not a trivial amount of code that the browser has to parse on every page load. And secondly, including jQuery from Google's CDN incurs a hefty overhead in form of the additional DNS request and SSL handshake.

For the latter issue there's a solution: Just host jQuery myself, or don't use jQuery. The second solution solves both issues. When there's no jQuery, there's no large script that needs to be parsed.

GitHub famously has refactored its frontend to free itself from jQuery and has reimplemented the functions through native JavaScript. And so I've decided to try out a life without jQuery.

Replacing jQuery

But jQuery has such neat advantages! Well, yeah, but the JavaScript implementations in modern browsers have evolved, and the things I used jQuery the most for, have been implemented in the most widely used browser (versions). And for the rest there are wrappers and libraries now that will be much smaller than jQuery. I'm basically tree shaking jQuery at this point.

What I liked the most about jQuery was the simple way of defining events, the easy DOM node selection, the class utilities and AJAX.

Events

I think jQuery has a great API for event definition, especially for binding multiple events to multiple elements, and event delegation. As an example, here I'd like to give text input fields a red border when they're empty. I created a CSS class for that, which I want to apply based on the text field's contents.

The following code block in jQuery:

// Defining multiple events on multiple elements via jQuery
$('#name,#message').on('change input blur', function(e){
	var el = $(e.target);
	if(el.val === ''){
		el.addClass('form-control-error');
	}else{
		el.removeClass('form-control-error');
	}
});

Turns into:

// Defining multiple events on multiple elements in native JavaScript
document.querySelectorAll('#name,#message').forEach(function(el){
	['change','input','blur'].forEach(function(event){
		el.addEventListener(event, function(){
			if(this.value === ''){
				this.classList.add('form-control-error');
			}else{
				this.classList.remove('form-control-error');
			}
		});
	});
});

For this simple action I need two for-loops. I know that there's actually no difference, jQuery's API just hides those loops and string operations behind this inconspicuous call. Generally, jQuery is not a lot slower than the native solution.

But jQuery also does event delegation. This only works if you differentiate the clicked element manually in the event handler. If you don't want to do that, you can check out events.js by Chris Ferdinandi. It's 1.24KB in size and makes defining events much easier. I chose not to include it, because my website is small and I could solve it that way in that one specific case.

Class Utilities

This one's pretty simple. The solution is called ClassList and can be used in relatively modern browsers. The API is similar to jQuery as you can see above. $(element).addClass('example') turns into element.classList.add('example') ClassList works with limitations in Internet Explorer 10, and poses no problem to newer browsers.

AJAX

As can be seen in the code example above, AJAX via XMLHttpRequest in native JavaScript is not very pretty.

Behind the contact form on my website I have a server-side API that tells whether the user has typed in a real email address, and if so, whether this email address is from a disposable email provider. Here I used a wrapper for XMLHttpRequest by Fernando Daciuk called ajax.js that is 1.97KB in size. It works similarly to jQuery's $.get(), $.post() and $.ajax() functions. The corresponding AJAX call looks like this:

// AJAX Get via ajax.js
ajax().get('/contact/checkmail', {
	email: email.value
}).then(function(data){
	if(data == true){
		// Email address is allowed
	}else{
		// Email address is not allowed
	}
});

There's also an alternative, the relatively new Fetch API. The example above is written in mostly the same way. Using the Fetch API is only slightly more complicated:

// AJAX Get via Fetch API
fetch('/contact/checkmail', {
	cache: 'no-cache',
	body: JSON.stringify({email:email.value})
}).then(function(response){
	response.json().then(function(data){
		if(data.json == true){
			// Email address is allowed
		}else{
			// Email address is not allowed
		}
	});
});

The Fetch API only sends plain text, so the server has to parse the JavaScript Object coming in. The Fetch API lets you decide what format you want to transform the server's response into, for example via response.json().then(). Personally I wanted to be on the safe side and took ajax.js to support more browsers.

Result

The result is pretty obvious: By removing jQuery I reduced the amount of data transferred on page load, removed one request (including the DNS and SSL overhead) and a large script that in large parts goes unused. My homepage now reaches 100 points in the PageSpeed Insights test.

With jQuery:

Without jQuery:

It's noticeable how Google assumes that mobile devices with their slower processors will take longer to parse the page and show stuff on the screen, when jQuery is linked, versus when it's not. Especially the time to Firs Meaningful Paint has been reduced by a second. The First Meaningful Paint indicates the point in time at which all visible elements and webfonts have been loaded and rendered. This metric is important not only for the user experience of a website, but also for rankings in search engines.

In tangible numbers, here's the timeline of loading the homepage:

With jQuery:

Without jQuery:

A last optimization I did was that I included webfonts as inline CSS in the <head> part of every page. Through http2 the webfonts are loaded in parallel with the rest of the pages now, and don't have to wait for main.css to load first. Aside from the 30KB saved from removing jQuery, I saved around 10% of loading time for newly arriving visitors (where the DNS lookup and SSL handshake has to be done) until everything is displayed on screen. When reloading the page, or visiting another page, the savings are slightly higher.

All in all nothing really necessary for my website, but I'm happy about the little 100 and the realization that jQuery thankfully is not really needed these days.

I think I'll try not to use jQuery in future projects. Can't hurt in any case.

---