Consider Preact for Theme Development

Shopify themes should stay lightweight, but lightweight does not necessarily mean framework-free. A small, well-chosen framework can reduce complexity rather than add to it, particularly once a storefront contains more than a handful of interactive features.

Theme JavaScript often starts innocently enough. You add a product form, variant selector, cart drawer, quick-add button or predictive search. Each interaction is straightforward in isolation, but the complexity appears when they begin depending on one another. A variant change may need to update price and availability, adding a product should refresh the cart count, and the cart drawer needs access to the latest cart state. Before long, you are managing shared state, derived values, lifecycle behaviour and multiple UI updates across the page.

At that point, avoiding a framework can mean slowly building one yourself.

Give theme JavaScript a proper foundation

Preact provides a small component model with state, hooks, composition and predictable rendering. Instead of deciding how every feature should initialise, update, communicate and clean itself up, you have one consistent approach across the theme.

That consistency becomes increasingly useful as a storefront grows. A product form that begins with a small amount of logic may later need to support subscriptions, bundles, inventory rules, selling plans or personalised content. If those behaviours already sit within a predictable component architecture, extending them is considerably easier than adding more custom events, DOM selectors and manual update logic.

This is one of the main reasons I like Preact for theme development. The value is not simply that it lets you write components. It gives the interactive side of the theme somewhere sensible to grow.

Preact and Web Components work well together

Using Preact does not mean abandoning Web Components. In fact, the two can complement each other particularly well in a Shopify theme.

Web Components provide a clean boundary that works naturally with Liquid, while Preact can handle the implementation behind that boundary. Liquid can render a custom element and pass the information it needs through attributes or child markup:

<product-form
  product-id="{{ product.id }}"
  section-id="{{ section.id }}"
>
  ...
</product-form>

From Liquid's perspective, this is simply part of the page markup. Once the JavaScript loads, the element can be upgraded into an interactive component whose state and rendering are handled by Preact.

This creates a useful separation of responsibilities: Liquid renders the storefront, Web Components define the integration boundary, and Preact manages the behaviour inside it.

That is often cleaner than treating every custom element as an independent piece of JavaScript with its own conventions for state, rendering and communication.

Keep Liquid in charge of the storefront

Introducing Preact should not mean turning a Shopify theme into a single-page application. Liquid is still the right place for the initial page structure, product data, section settings and merchant-configurable content.

Preact can sit on top of that server-rendered foundation and enhance the parts of the page that genuinely need richer interaction. A product page does not need to become client-rendered simply because its variant picker or product form benefits from state.

Thinking in terms of interactive islands works particularly well here. Shopify and Liquid remain responsible for the document as a whole, while individual components can become more application-like where the experience requires it.

This also keeps the boundary between content and behaviour clear. Liquid can continue to provide the data and markup that Shopify controls, while Preact deals with the changing state of the interface once the page is running.

Web Components do not remove application complexity

Custom elements are useful browser primitives, but they do not automatically solve the architectural problems that appear as an interface becomes more interactive.

As a component grows, you still need to decide where its state lives, how it reacts to changes, how the DOM is updated, how side effects are cleaned up and how shared behaviour is reused. Once multiple custom elements need to communicate, you also need conventions for passing information between them.

Without a common approach, those conventions can become inconsistent surprisingly quickly. One component may use attributes, another custom events, another direct DOM queries and another its own internal state. Each solution may be perfectly reasonable on its own, but together they can make the theme harder to understand and maintain.

Preact gives those components a shared implementation model. You can keep the browser-native boundary of something like <cart-drawer> while using state, hooks and predictable rendering internally instead of manually synchronising DOM nodes.

The point is not that Web Components are bad. They are excellent boundaries. They simply do not need to be the entire architecture.

Bundle size is not the only kind of complexity

One of the most common arguments against introducing a framework into a Shopify theme is JavaScript weight, and that is a valid concern. Storefront performance matters, and adding dependencies without a clear reason is rarely a good idea.

However, bundle size is only one form of cost. Maintenance complexity is another.

A dependency-free theme can still contain thousands of lines of custom event handling, DOM selectors, state synchronisation and lifecycle logic. Avoiding a small framework is not automatically a win if the alternative is gradually creating your own undocumented framework from smaller pieces.

The question therefore should not simply be, “Can I build this without Preact?” In most cases, the answer is yes.

A more useful question is: “Will Preact make the next twenty interactions easier to build, understand and maintain?”

If you know the storefront is going to contain substantial interactive behaviour, the answer may well be yes.

Use the right tool at each layer

There is no need to choose between Shopify's theme architecture and a modern component framework. They solve different problems and can work together cleanly.

Use Liquid for server-rendered content, merchant configuration and the initial document structure. Use Web Components as stable integration points within that markup. Use Preact when those components need state, composition and predictable rendering.

The result still behaves like a Shopify theme. Merchants continue working with sections, blocks and Liquid-rendered content, while the JavaScript side of the storefront gets a consistent architecture rather than growing into a collection of unrelated scripts.

Liquid renders the storefront. Web Components define the boundary. Preact handles the complexity inside it.

Sometimes the lightweight option is not avoiding a framework. It is choosing a small one before you accidentally build your own.