jQuery in Magento 2

by Michael Moores

jQuery in Magento 2

by Michael Moores

by Michael Moores

Magento 2 brings numerous new features and changes to the architecture, but none seem to excite developers more than the shift from using Prototype to jQuery. While this change will have a huge impact on developers working with Magento, there will definitely be some aggravation as we transition our sites (or client’s sites) into the future of Magento.

Note: This post should no longer be used as a technical resource on Magento 2 as it is out-of-date and may not reflect the current released state of Magento 2.


There are many reasons to get excited about Magento switching to jQuery, but the top is clearly being able to easily leverage the mountain of jQuery libraries that are already available on the internet. From sliders to modal chat dialogs, nearly any front-end problem can be solved using off-the-shelf libraries that are almost universally free (both in terms of speech and beer). Even now, if you google “Magento jQuery” you’ll find page after page with people either asking or explaining how to integrate jQuery in their Magento eCommerce site. Often the goal of all of these explanations is to leverage a great library. Well, now you can! You no longer need to fiddle with loading from a CDN through layout (does not work well) or adding your own file just to handle the call to enable ‘no conflict’ mode (to play nicely with Prototype).

Now, I don’t intend on disparaging Prototype, as there are many libraries out there that utilize it. However, as jQuery’s popularity has been soaring, the result is a greater catalog of choices to suit your specific needs. Prototype just doesn’t have the volume of choices to satisfy everyone.

Another advantage of jQuery becoming a first-class citizen in the Magento ecosystem is having a standard expected version of jQuery and jQuery UI. Many libraries require a specific version range for jQuery and they may fail if that is not satisfied. This can be complicated when 3rd party code (Modules) include their own version of jQuery, which happens a lot. Let me paint an example:

You are building a modern, clean, expressive template (work with clients and you’ll hear this a lot) and you decide to leverage an excellent image gallery library that requires jQuery 1.7.0. Later, someone installs a Magento module that adds a floating popup “chat with us now” dialog to every page which includes version 1.5.0 of jQuery. Suddenly, your gallery isn’t working! Then your boss starts throwing things at you again. Not my idea of a good day at work.

The current revision of Magento 2 in Github uses version 1.7.1 of jQuery. Therefore, if you are a Module developer worth your salt you will be coding solely against that version. If some hotshot designers are “re-imagining what it means to shop online” and they need a responsive slider library, they will be sure to choose one that is compatible with version 1.7.1! Everything working together in harmony. An end to violence in the workplace.

The last two things I wanted to touch on is what really makes me excited about the switch: testing and debugging. I could go on for a whole post (or two) about what a headache it is to debug Prototype. To avoid going into the nitty-gritty technical details, Objects created through Prototype are represented as functions named ‘klass’ that do an excellent job of hiding internal methods and data from the Chrome developer tools. Additionally, Prototype adds a great deal of functionality to existing objects including the DOM. In contrast, jQuery libraries typically express objects using just simple javascript hashes. Although this does not allow for the easy inheritance of functionality you find with Prototype, it is very simple to debug. For me, simplicity wins out since there are a number of jQuery libraries that add the inheritance functionality if you truly need it. Also, jQuery is self-contained and does not modify the DOM or any other existing objects, which is why it is able to run in compatibility mode!

Finally, a comment on testing. Prototype has their own Unit Testing framework that amazingly requires Prototype! The team that makes jQuery has written their own (QUnit). However, it is standalone and does not require jQuery at all. It may seem strange to you, dear reader, but I just feel better with that fact.

And with that, discerning Magento developers and designers, I conclude my rant on the advantages of jQuery over Prototype. It should be noted that, as of this posting, Prototype still exists in Magento 2. So, don’t go throwing around dollar signs in your scripts just yet. Either use the full object name(jQuery!) or alias it to another variable ($j = jQuery.noConflict). I can only assume that by the release of version 1.0 of Magento 2, it will be completely excised.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.