jQuery 3.0: Which build do you need? Full or Slim

JQuery 3.0 is available in a full fat and skinny version. Here’s the pros and cons to help you decide which one is best for you



Widely understood
JQuery can be considered the bread and butter of web frameworks: most, if not all, web developers have used it at least once during their career. Deploying the full version of jQuery provides minimal friction – everything will be just as it has always been.
Readers might scoff at the thought that developers could forget that their product is based on the light version – given that a famous arms company once lost days tracing down a problem caused by an oscilloscope not being connected to the DUT, so reducing potential for wetware issues always is worthy.

Decreased coupling
Ted Faison introduced coupling mathematics to common developers. Reducing the amount of external libraries always is a good thing: if your developers find themselves adding an extra framework, you just have yourself one more partner on whose decisions your future depends. JQuery’s all-encompassing approach and its widespread popularity make the library one of the most trustworthy partners. If a feature is offered by jQuery, use it even if another library is slightly more convenient: no one knows whether the vendor of library foo will still be around when you need them the most.


Increased code size
For many a developer, one byte of space saved is one byte saved. If you are a person who values small code size above all, jQuery’s 6KB size penalty might tilt the table in favour of jQuery Slim. Switching to jQuery Slim is not just for pedants, however. In many cases, applications must stay under a certain size limit (like for the app store) and tend to be above it by just a few kilobytes courtesy of Murphy’s law. Being able to save a bit of space by swapping out a library can be a godsend – so remember that jQuery Slim is great for this purpose.

Lack of flexibility
If a library comes in two actively maintained versions, it is very likely that each one of them has its individual strengths and weaknesses. This is also the same case with jQuery. The various features embedded into jQuery mean that developers are likely to use them when encountering a problem that requires a library to solve. Due to the human nature of favouring things which are already there, library choices can become less than ideal. Keep in mind that jQuery once was a DOM manipulation library which evolved into other markets.


Smaller code
JQuery slim gets built with the exclusion of the following modules: -ajax, -ajax/jsonp, -ajax/load, -ajax/parseJSON, -ajax/parseXML, -ajax/script, -ajax/var/location, -ajax/var/nonce, -ajax/var/rquery, -ajax/xhr, -manipulation/_evalUrl, -event/ajax, -effects, -effects/Tween, -effects/animatedSelector and -deprecated. As of this writing, the minified libraries can differ by a code size of about 6KB. In addition to that size difference, developers can replace any of the omitted modules with a library that they may consider to be better or are more comfortable with.

Somewhat standardised
If web designers had a nation, creating slimmed-down versions of jQuery would be its national sport. While the motivation behind optimising the behemoth is easily understood, going custom has significant penalties in terms of interoperability.
Developers and framework suppliers tend to assume that the presence of jQuery means that the complete feature set of the library is available. Missing features can lead to all kinds of odd behaviour, which is extremely difficult to track down – this doesn’t mean that it will happen in your app, but be aware that it very well could.


Possible compatibility issues
Even though jQuery Slim 3.0 is an ‘official’ release, its relative newness ensures that plugin and framework vendors have not had particularly much time to adapt their products to the feature set. If your company is currently going through a rocky transition adapting its products to jQuery 3.0, adding the extra grief caused by a deployment of the slim version is unlikely to be worth it. Problems caused by missing or incomplete implementations of support libraries tend to be among the most difficult to debug. Avoiding them is recommended to experienced and novice developers.

Is it worth it?
Let’s be honest: as web connections and workstations get faster and faster, efficiency is not as important as it used to be. Running code in JavaScript always has a high efficiency penalty – if you need true speed, going for C or Assembler would be the better choice.
Deploying jQuery Slim saves you the princely sum of 6KB: many applications waste more than that on in-line comments in the markup. Of course, compile and parse time is also reduced – but does that really matter in a time when an octacore smartphone can be bought for fewer than 200 euros?