The State and Future of Shopify Frontend/Theme Development

I think the reason why frontend “theme” development on Shopify matters so much is that themes on Shopify aren’t just “themes” to most merchants. A Shopify merchant that is just getting started might buy a theme from the Shopify theme store or Theme Forest, but over time as they grow and evolve their Shopify theme becomes much more than a “theme”. Part of the reason for that is that besides building apps, there is not a simple way to create your own backend logic in Shopify. So most merchants and developers have inevitably built a fair amount of custom code and logic into their themes. And many apps require some theme customization for the installation process.

ThemeKit is the Shopify development tool that allows you to work with a theme on your store through your local code editor rather than the Shopify Admin. It has just a few basic functions to download themes and watch for changes on your local files and then upload them to Shopify. This is extremely helpful for frontend developers as doing significant development in the Admin theme editor is laborious.

Shopify has been appreciated among many developers for its simplicity and flexibility of frontend development. Instead of having a very opinionated frontend framework they’ve left it up to the individual developers to use the frameworks and libraries they choose. That lasted for many years until Slate came along.

Two years ago Shopify also released a node.js wrapper for ThemeKit so you could build your own build process around ThemeKit. And that formed the foundation of Slate.

Slate was the first official build toolkit for developing Shopify themes. Slate was the opposite of a “no rules” development approach and that could have been great because Shopify theme development can be a bit of a wild west as I’ve inherited sites with very custom themes that were a Frankenstein of many different JS frameworks. In their documentation, it specifically states Slate is an “opinionated” theme framework. And in theory, it was supposed to be a build system that would speed up Shopify theme development by integrating a lot of modern frontend build features like Webpack, local development asset server, and multiple deployment environments.

But however well-intentioned, I think it missed the mark. I’ve found Slate to be able to expedite initial theme development, but it poses many problems maintaining themes long term that I don’t think make it a suitable framework.

• MacOS support only – The first of these issues is that for all of its life, Slate has never officially supported Windows. I (Mark) am a Mac user, but our development team has a mix of Windows and Mac users so this poses an immediate problem. I ended up having to set up a MacOS build server for our developers on Windows to be able to update Slate themes.
• Agency Transition – When a Shopify merchant changes agencies, unless the prior agency freely gives their Slate build files, the new agency can’t really edit/maintain the old theme because all the Javascript and CSS files are compiled on the server and basically unreadable/uneditable.
• Admin Them Editor – Because the JS and CSS files are stored on the server compiled this also means that it’s not really possible to edit these files from the Admin. Some agencies might view that as a bonus because they don’t want pesky clients editing their theme, but I view it as a net negative because you don’t even have the option and merchants are kind of taken aback when they find out they no longer have the control with Shopify that they thought they did.
• Beta – Despite Shopify pushing Slate as their theme development platform for the future, it has never gotten out of beta. Even v1.0 is considered beta and there have been many breaking changes along the way. So if you were working on building a theme on one version of Slate, the next month you might have to rewrite significant parts of your theme in order to stay compatible with the latest version.
• Low Maintenance – And finally Shopify announced earlier this year that they put the project on “low maintenance”. And what they explained that means is they will only fix bugs if “Shopify developers own work is blocked”. This seems kind of like a gut punch to all the agencies that invested time and resources into building clients’ sites in Slate and now they’re kind of on their own if they find bugs unless an internal Shopify developer is facing the same issue.

So rather than going on more about what is wrong with Slate, I’d love to talk about what is “right” about Slate and what I’d love to see more of in a future Shopify frontend development framework (This is for you Tobi!).

• Multi-platform support – From the start, the tool should both support MacOS and Windows. I say this as Mac user, but the reality is that we live in a multiplatform world and if there isn’t Windows support from the start, you’re excluding a very big part of your userbase.
• git Version Control/Deployments – Shopify does have its own form of version control in the Admin theme editor, but it would be great if themes were built with git version control in mind since that’s what most developers use to control the source and you would also be able to control deployments with git (i.e. push to a repository and it updates the live theme). We do use git already for Shopify, but we have to do a bit of a funky workflow to make it work.
• Local development asset server/Auto Browser Refresh – I think one of the most valuable aspects of Slate is that rather than having to wait for a change to be uploaded to Shopify by ThemeKit and then having to manually refresh the page, Slate creates a local proxy server to serve the static assets from and has an auto browser refresh that is almost instantaneous. When building a theme or making big modifications to an existing theme, the seconds saved by not having to wait a few seconds for every change to show up really adds up over time.
• Local/Server Build System – I think things like ES6+ support and compilation are great in Slate, but I think it should never come at the expense of Admin theme editing capabilities. Any true “building” should be done on the server side so if you edit a file in the Admin theme editor, it auto builds it. This build tool should also be available locally as part of the local development asset server so if you don’t want to wait for the file to be uploaded and compiled, you don’t have to. But ultimately you should always have to upload the raw build source so that a merchant doesn’t ever get into a situation where they’re locked into their old agency for theme maintenance because they have the build files and won’t release them.
• Auto-Optimization – This one can be tied to the build system, but I think at a minimum, you should have the option to auto-minify CSS, JS, and HTML files like Cloudflare does, without having to use any sort of build system. Other features like Rocket Loader to reduce blocking JS and Mirage to optimize images would be amazing as well. Shopify even currently uses Cloudflare in some regions so this shouldn’t be out of the realm of possibility.

I’m sure there’s a lot of other features that would make life easier for frontend developers who work on Shopify. I’d love to hear anyone else’s comments/feedback on here or Twitter.