TL;DR
- Most Shopify themes ship a pile of merchant-facing flexibility you never use, so you spend the first week of a project deleting code instead of building.
- themex is our internal theme foundation at devx, built for developers rather than the theme editor, so the code that ships is code that gets used.
- Small stack on purpose: Tailwind, plain JavaScript, Web Components, no framework, no bundler.
- One source of truth for the cart, optimistic updates with clean rollback, queued quantity changes, and a checkout that waits for in-flight updates.
- Recently viewed, recent searches, and search all run on Shopify's own section rendering, so there are no extra apps or services to depend on.
Every Shopify store runs on a theme, and it does more than people think. It decides how the store looks and how it works, the home page layout, the way products show up, how the cart behaves, and how someone moves from browsing to buying. Most of what a customer feels while shopping comes from it.
The problem
Most Shopify themes are made to be changed by merchants. They come with a lot of presets, section options, and ready-made templates, so a store owner can move things around without touching code. That sounds good, and for some stores it is.
But it has a cost. To support all that flexibility, the theme ships a lot of code. And most of it goes unused on any given store. A brand that wants its own look usually rebuilds those ready-made templates anyway, so the ones that came with the theme just sit there. Over time that unused code piles up. The theme gets heavier, harder to read, and harder to work in. You spend your first week on a project not building, but figuring out what you can safely delete.
We hit this pattern on enough projects that it stopped feeling like an accident. It felt like the wrong starting point.
Why we built themex
So we built our own starting point instead. themex is our internal theme foundation at devx. It is the base our team begins from when we build a store. It is not a product, and it is not for sale. It exists to solve one problem for us: start every build from something clean instead of something we have to trim down.
The intention was simple. We wanted a base where the code that ships is code that gets used, and where a developer spends their time building the store, not clearing space to build it.
That meant making a choice most themes avoid. themex is built for developers, not for merchants clicking around in the editor. A non-technical owner cannot reshape it without a developer. For a theme sold to thousands of stores, that would be a real problem. For a tool our own team uses on every build, it is exactly what we wanted. We gave up the drag-and-drop side to get a base that stays clean and predictable.
How we built it
A few decisions shaped the whole thing.
We kept the stack small on purpose. Tailwind for styling, plain JavaScript for behavior, and only two patterns in the code: Web Components for the interactive pieces, and simple scripts for page logic. No framework, no bundler. For a Shopify theme, keeping the tooling light means less to maintain and less that can break.
We gave the cart one source of truth. A single place holds the cart state, and everything on the page that needs cart data reads from it. No component keeps its own copy. That one rule removes a whole class of bugs where two parts of the page disagree about what is actually in the cart.
We kept the code honest about what it targets. The JavaScript looks for data attributes, never CSS class names, so changing how something looks does not quietly break the code that makes it work.
And where it made sense, we did the work on the client or leaned on Shopify's own tools rather than reaching for something heavier. The variant selector is a good example. It resolves the selected variant on the client from a small set of data already on the page, then updates the price, image, and URL, with the color swatches coming from that same data. Filtering is the other. It runs on Shopify's Storefront Filtering API with section rendering, so applying a filter swaps the results in place and keeps your scroll position. Neither is exotic. They are just built the plain way, close to the platform.
None of these are clever tricks. They are decisions we held to everywhere, and holding to them is what keeps the base clean as a store grows on top of it.
What came out better
Some things in themex are a real step up from the way they are usually done. The clearest is the cart, so it is worth comparing how a cart normally works with how ours does.
In a lot of themes, when you change a quantity or add an item, the interface waits. It sends the request to the server, waits for the answer, and only then updates what you see. There is a small pause where nothing seems to happen.
themex flips that around. When you click, the interface updates right away, and the request to the server goes out after. If the server confirms, the cart settles on the real state. If something fails, the change is rolled back cleanly, so what you see never drifts away from what is actually in the cart. The trick is that the cart is always allowed to correct itself, so updating first is safe.
Two smaller things fall out of that same care, and both fix common cart problems. If someone taps a quantity button a few times fast, a naive cart fires overlapping requests that can land out of order and leave the wrong number, so themex groups those changes and runs them one after another. And if you hit checkout while a cart change is still in flight, themex holds the button and moves you along only once everything has settled, so you never check out against a cart that has not caught up.
A few other things are better than the common approach too.
Recently viewed and recent searches usually need a separate app or extra tracking. themex handles both on the client with a little local storage and renders the product cards through Shopify's own section rendering, so there is no app and no extra service to depend on.
The newsletter and contact forms are another. Many themes still do a full submit or send the shopper to a separate thank-you page. themex submits in place and shows an inline message, so the shopper stays exactly where they were.
Search is less about beating other themes and more about a choice we made. Rather than bolt on a separate search app, themex uses Shopify's own search with its Section Rendering API. On plans that qualify for Shopify's Search and Discovery features, that returns results ranked by meaning, and on plans that do not, it falls back to keyword ranking on its own. The credit there goes to Shopify. We just built the theme to use it well, with a search box, live results as you type, and recent searches on top.
Where this leaves us
themex did not come from wanting a fancier theme. It came from being tired of starting every project by cleaning up someone else's idea of flexibility. Once we decided what the foundation was actually for, the rest got simpler. Keep what serves it, drop what does not, and build the rest per store.
And this is just the start. themex is something we will keep working on. As we build more stores, we will keep spotting problems worth solving and places worth improving, and we will fold those back into the base over time. It is meant to grow with what we learn, not sit still.
That is the whole idea. A base that respects the developer working in it, and a store that behaves the way you would want it to for the person shopping.
