Why We Don’t Use JQuery at Drake Cooper

jQuery has been the de facto for normalization in the web industry for years now, and its relevance in recent iterations of both the web standard as well as browser support has been brought to question by many community members.

Anymore, it seems jQuery’s true purpose – to provide maximum compatibility with a wide array of browsers and to abstract otherwise arguably complex APIs behind a simple interface – has been blurring given the recent slew of W3C specification updates with the upbringing of HTML5.

Instead of saying why we use jQuery at Drake Cooper, I’d like to point out some common concerns when considering when not to use jQuery.

It’s Slow

If there was anything that could undeniably be true without a single thread of doubt, jQuery is indeed very slow.

While the above test is specifically for selectors (one of jQuery’s main selling points), any other test on jQuery yields similar results. jQuery generally performs about 60-80% slower than vanilla (native) Javascript, and considerably slower than other frameworks that do similar or the same things.

Along with the inherent performance hit, jQuery is often used incorrectly. Chaining selectors, not caching result-sets, and performing massive CSS changes or animations on the Javascript end are often showstoppers for mid to low end computers.

It’s worth pointing out that CSS is often hardware accelerated and many graphical operations are performed directly on the GPU, leaving the CPU more room to breathe.

jQuery, being a Javascript library, provides no such thing – and even worse, Javascript is usually executed on a single thread – at least for vanilla scripts.

This means if you’re running presentational logic (such as fading an element in and out) using Javascript, you’re preventing many other operations from occurring that could slow down more critical parts of page execution.

Vanilla isn’t hard

A common misconception is that the basic Javascript API’s provided by the browser are convoluted or difficult to use. While this is completely subjective, it’s almost definitively not the case anymore.

One thing I’ve noticed is the continual surprise from our UX/front-end developers with how simple vanilla is compared to how it is perceived.

For example, one of the preliminary concerns with dropping jQuery was How can I easily query elements using selectors?

document.querySelector[All], of course! Oh, and it’s faster.

There were other concerns, such as easily adding events (through $.click(function(){})) and fading in and out. While writing less code is (arguably) faster, there’s little to no excuse for not leveraging CSS (in lieu of Javascript) where possible.

Most other concerns centered around coding speed – that is, how easy it is to build up a page using jQuery vs. vanilla – also easily answerable by building up a simple code base to help you with any strenuous activity you perform frequently.

The unfortunate part about all of this – most convenient bits of code are targeted specifically for jQuery. This is one of the only reasons we’ve not dropped jQuery completely from Drake Cooper’s workflow.

Let’s get real

Alright, so jQuery is arguably unnecessary in most cases, and provides virtually no performance or usability enhancements.

That’s not to say, however, that jQuery doesn’t have a place. If a site needs to be supported on older browsers – namely IE8 and below – jQuery is the sensible choice. Since the demographic for these browsers, however, is so small, there is very little point in supporting them.

Further, jQuery supports certain things CSS hadn’t introduced until (sometimes recent revisions of) CSS3, such as animations and rotation. While Firefox and Chrome have undisputedly been quite good sports about supporting new specifications, Internet Explorer has always been a culprit for missing or sometimes incorrect functionality necessary for modern sites to function – often polyfilled by jQuery.

With that being said, Drake Cooper does not support IE8 or below. While it was an easy decision to make, it was one worth definitively making in a web design and interactive development environment. By throwing out this one browser, we’ve eliminated the need for many polyfills jQuery has provided us.

Ultimatum

Ultimately, we do use jQuery for quick or presentational bits of sites here at Drake Cooper. However, our mindset does not center around jQuery, and we try to find every opportunity to not use it.

Most of our internally developed Javascript libraries are written jQuery-free. All interactions with servers through AJAX are now written jQuery-free. Even large frameworks for presentational elements of our sites are now written jQuery free.

If you ask me, an interactive developer and programmer, jQuery is nothing but an impediment. That is why we don’t use jQuery at Drake Cooper.