My plea: Stop using JQuery for production code

A salute to a job well done

Before I begin my rant (take a calming breath) I will acknowledge the valuable contribution JQuery has made to the development of millions of interactive websites and the positive influence it has had on the advancement of web technologies such as HTML5, CSS3 and JavaScript APIs. I will also confirm JQuery remains an immensely useful tool especially in the hands of in-browser web designers.

At the risk of being burnt-at-the-stake for heresy: for some time now I have found JQuery to be more of a hindrance than a help, but perhaps my perspective is unusual.

How many libraries have a built-in dependency on JQuery, or an expectation that the library will be available along-side? How many millions of tutorials and code examples involve JQuery unnecessarily (or just because that is all the developer understands?) What proportion of the web coding community know JQuery but have little understanding (verging into fear) of JavaScript?

Trouble ahead

“Write less, do more” and perform poorly – take a look at these Speed Comparisons ( if you don’t believe me. Let us not forget what JQuery is written in; JavaScript. Oh, and which version of JQuery are we supposed to be using?

As for cross-browser compatibility, it depends on your perspective regarding legacy web browsers. If, like many, you are of the opinion that only ‘evergreen’ / modern browsers should be supported now that IE6 has formally (if not completely) dropped out of the picture; the need to support code across different browsers has reduced significantly since the bad old Netscape/IE days. If your requirement is to support all (or the large majority of) web browsers then there are techniques such as Progressive Enhancement to consider and Feature Detection tools like Modernizr ( that do a very effective job of supporting is issue.

When I was at school, pocket calculators were rare. The education system was in turmoil over the rights and wrongs of allowing such devices into classrooms and exam halls. Very few of us can calculate square-roots with pencil and paper but imagine if we taught our children how to perform addition and multiplication only by means of pressing buttons. Nevermind learning to spell – that’s what a spell-checker is for, write? I am not suggesting we should never use such tools (god forbid) but I am suggesting we need to understand they are not the only tools at our disposal and having a foundation knowledge is critical. Most people do not need a calculator to multiply 10 x 10, because they learned their times tables at school.

My problem

So, I stated my perspective may be unusual to most – why? My involvement in web technologies started around the year 2000, when I co-designed an application for a large UK police force.

We decided to employ the MS IE 5.5 web browser to deliver the User Interface. Our application made use of the Microsoft.XMLHTTP ActiveX control to exchange XML documents between the client and server. This enabled us to perform more of the business functionality (data validation) on the client-side (in the web browser) and greatly reduced out network traffic demands.

This was more than 4 years before this technology was given the moniker “Ajax” by Jesse James Garrett, in his February 2005 article “Ajax: A New Approach to Web Applications“. It was 5 years before the standardisation of XMLHttpRequest (XHR) by W3C and its integration into web browsers as a standard feature (MS IE 7+).

Same solutions, different problems

Our perspective, from the Software Development industry rather than the (relatively new) Web Development industry, views the User Interface as a component of the application with no higher significance than the database or interfaces with external systems. In our world “Content is (not) King” (burn the heretic) but “functionality is foremost”. Our attention is not on what the visitor needs to see, but how we can best support the end-user in his/her daily business.

Many projects I work on are for large corporate organisations with very controlled environments and strict IT strategies. I regularly encounter clients who (for whatever reason) do not permit open-source software/libraries on their systems. Some clients have a protracted processes for reviewing external products that means the approved version’s are often well out of date.

One of the consequences of all this is, someone suggests using vanilla JavaScript and only standardised web technologies such as AJAx. Their suggestion is deemed unscalable or not enterprise grade by ‘serious’ application developer. This results in the C# or Java developers swallow up the entire development (middle and front-end), much to my despair (different rant).

When we commence a JavaScript development we encounter different problems, which is where my ‘beef’ with JQuery resides.

The term “Web Developer” is such a vague title. We are often presented with people more from a graphic design than software engineering background. Well versed in HTML, CSS and associated tools (Bootstrap), but their experience of coding is founded on JQuery with some JavaScript or, if we are lucky, PHP. They are often more familiar with SEO (Search Engine Optimisation) and RWD (Responsive Web Design) than OWASP (Open Web Application Security Project) and WCAG ( Web Content Accessibility Guidelines).

When we are able to employ a new JavaScript library (e.g. Angular) or CSS framework (e.g. Bootstrap), there is often a dependency on JQuery. Examples and code fragments presume JQuery will be used and, more often than not, is bundled with the installation package to ensure you are using the required version. But just because we can use the library does not give us the right to use all dependencies or different editions to the corporate approved release. Then there is always the potential for more than one component to depend on different editions of JQuery!

God forbid we find an error in one of these external libraries or get some form of conflict between two frameworks. Good luck on sorting those out.

Spreading the love

JQuery is not alone; I have similar contempt for other libraries such as Bootstrap, which serves designers very well to demonstrate how a screen needs to degrade gracefully with reduced screen space. But it is as if media-queries are the preserve of black wizards. We bolt in these frameworks, warts and all, bloat-out our own software rather than invest some time and effort in learning how to master the standardised technology ourselves.

There is a similar issue in the CSS technology with their use of vender prefixing (vp). For those unfamiliarly with the practice: before a CSS feature is fully recommended by the W3C the specification will have been circulating browser venders for months. Without a clear and authorised specification for a feature’s development, or its interface, manufacturers will offer developers their best guess. In order to minimise the impact of web presentations, the manufactures mark their (non-standard best-guess) implementation by prefixing a code such as -moz- (Mozilla – Firefox), -ms- (Microsoft – IE/Edge), -o- (Opera) and -webkit- (Chrome).

By itself this is fine and it provided designers/developers with early visibility of up-coming features. The majority of the time the interfaces and behaviours of these nascent features are very similar across all the vendors. The problem is not that their may be differences, that is what vp is intending to avoid by establishing a virtual namespace for their versions. The issue, I have, is what happens to the vp features outside of the design community. Remember, these features are immature, so when instructed to implement them, developers will often safeguard their code by declaring as many variations of the feature, of which they are aware, followed by the recommended version once approved.

For example:

/* Cross-browser css3 linear-gradient */
.linear-gradient {

/* Gecko browser (Firefox) */
background-image: mozlineargradient(top, #D7D 0%, #068 100%);

/* Opera */
background-image: olineargradient(top, #D7D 0%, #068 100%);

/* older Webkit syntax */
background-image: webkitgradient(linear, left top, left bottom,
colorstop(0, #D7D), colorstop(1, #068));

/* Webkit (Safari, Chrome, iOS, Android) */
background-image: webkitlineargradient(top, #D7D 0%, #068 100%);

/* W3C */
background-image: lineargradient(to bottom, #D7D 0%, #068 100%);


The problem arises once the recommended version becomes mainstream and the vp versions are dropped. This will not impact the effect but leaves debris in the code base. millions of now obsolete vp-features being sent over the network only to be ignored.

My advice, keep the vp editions in the design box labelled “aspirational”, never release them into the wilds of the WWW, never to be recaptured.