#SHOPIFY MOVEALONG CODE#

Nice and easy, no errors in dev tools, time to move on.

We started with the simplest file, one with a few functions and a few selectors. Our approach was to comment out each module we had, remove jQuery, and slowly add in each module or function one at a time while it was rewritten.

#SHOPIFY MOVEALONG CODE#

Removing our reliance on it and untangling it from ~6k lines of code (for each theme) felt insurmountable - especially when I couldn’t know for sure my performance scores would benefit or by how much. But when you look at the lifecycle of some JS frameworks that flamed out, jQuery has always been steady and that was familiar and safe to me. I knew jQuery inside and out and could make it pull off nearly anything I tried. I’m one of those developers who were stuck in the past. Shopify’s CEO made a push for pure JS in themes.We wanted to remove it for a few reasons: Most of all, it helped with cross-browser differences so developers didn’t have to think about it. jQuery is a way of using CSS-like selectors and developer-friendly syntax for things like animations and Ajax requests. Well, jQuery isn’t a framework like React so it’s a bit of a non-starter comparison. Why remove jQuery anyway? I’ve heard lots of arguments about this, such as its package size isn’t that bad compared to a framework like React. Then IE 11 support was dropped by Shopify and the clouds parted - it was our time. We had to support old IE, so it was just so easy to ignore any attempt at removing it. Writing Vanilla JS always seemed like a pipe dream. While going through these changes, it was the perfect time to rethink some more basic issues like how my JS was structured and how elements were initialized. Thankfully, Tobias Ahlin has a fantastic guide on some of the quick conversions away from jQuery. Moving away from jQuery was a blessing, but a long process. Standardizing code shared between themes (remove duplication).Remove Handlebars.js, as our templating needs were way too small for such a large package.Remove jQuery and rewrite ~6k lines of JS per theme in Vanilla JS.Our Goal Was Simpleīetter performance across the board. Our themes had pretty good speed scores for how much they offered, but they were undoubtedly bloated. The problem is that building new performant features will only go so far when some of your codebase is so old that it has old IE polyfills or IE10 CSS hacks. That meant there was a lot of modern JavaScript we couldn’t utilize without sometimes sizable polyfills.Įight years later, in 2021, themes are infinitely more complex because Shopify has released a ton of new features (to go along with our in-house ideas at Archetype Themes). The hardest part was that Shopify required themes to support IE8, and up until late 2020, IE11. When I worked in-house at Shopify in 2013, themes were fairly simple in terms of code complexity. I’ve been building Shopify themes for the better part of a decade. When tackling a big refactor, what are the things you should focus on and what performance improvements can you expect? Code evolves over time with more features, new or changing dependencies, or maybe a goal of performance improvements. The dreaded refactor of old code can be challenging. In this article, Carson Shold discusses how his team improved the performance and organization of their Shopify themes, and improved maintainability along the way. When dealing with themes for large platforms and CMS, legacy issues often become a bottleneck.

Shopify movealong