Shopify Liquid is evolving — and themes are becoming readable again

Shopify’s Product Director for Online Store, Ben Sehl, just published Liquid: Back to the future — a long look at why theme structure is moving back into readable code, and what that unlocks for developers, merchants, and coding agents.

If you build themes, theme app extensions, or storefront-facing apps, this is not a nostalgia piece. It is a platform direction change with concrete primitives already landing in a developer preview.

The trade-off that got us here

Ben’s framing starts somewhere familiar: early Shopify themes (Timber-era) were short Liquid files you could read top to bottom. Then sections, Dawn, Horizon, and blocks made merchants into merchandisers — and templates into JSON serialisations that themes warned you not to edit by hand.

That was a rational trade for the “click the knobs” era of the theme editor. Merchants got composition. Developers paid for it in cross-file archaeology: JSON, Liquid, schemas, settings, sections, and blocks before you could reconstruct a page.

AI changes the equation. Merchants already make millions of Sidekick theme edits. Developers increasingly write Liquid with agents. A great developer experience and a great agent experience start looking like the same checklist: legible code, explicit contracts, fast feedback.

What is actually changing

Ben’s post (and the new base theme architecture) clusters around a few ideas that matter in production:

1. Page structure as Liquid again

Templates in the new architecture are Liquid files, not JSON outputs. The collection template is roughly Timber-length; the sample theme is dramatically smaller than Horizon because it is a foundation for commerce primitives and performance — not a batteries-included Horizon clone.

Existing themes keep working. Liquid remains a forever API. This is an opt-in architecture for building with agents and simpler mental models, not a forced rewrite.

2. Composable {% block %} tags in Liquid

Blocks can live inside Liquid templates with named parameters and nested content — closer to props/children in a component system, still readable as Liquid. HTML handles ordinary markup; blocks define the merchant-editable boundaries. That means agents (and humans) do not need a settings knob for every layout variation they can express in HTML.

3. Contracts agents can trust: {% doc %} and Theme Check

The expanded {% doc %} tag turns snippets and blocks into typed contracts — documented parameters, Theme Check validation, examples. Twenty new Theme Check rules cover contracts, structure, complexity, nesting, and file size. Guidance also lands via Liquid skills and an .agents directory (AGENTS.md, DESIGN.md) so coding agents inherit how your theme wants code written.

4. Partials for fine-grained reactivity

Instead of stretching the Section Rendering API for every cart/UI refresh, partials wrap a region you can re-fetch and swap as HTML. Same idea as declarative partial updates elsewhere on the web: server-rendered, no virtual DOM tax for “update these cart bits.”

5. Standard Events and Actions

Shared vocabulary for cart and storefront interactions — easier for themes and apps to interoperate, and clearer for browser agents (including WebMCP-oriented paths) to act without inventing one-off APIs per theme.

6. A strict parser so Liquid can grow

The stricter Liquid parsing work (live since January 2026) was not paperwork. Ambiguous syntax blocked boolean expressions, better operators, and literal arrays/objects. Strict parsing is the foundation that lets Liquid evolve without silently changing storefront behaviour. If you maintain a theme app extension, that migration guide still matters.

7. Tailwind coming to Liquid themes

A shared styling language agents already know, oriented around design tokens, without forcing merchants through a bespoke build pipeline. Worth watching as the common CSS surface for agent-authored UI.

Why app developers should care

At Reiwa Dev we ship storefront surfaces through theme app extensions (for example the waitlist button in Waitlist Flow). When Online Store doubles down on readable Liquid, typed blocks, standard events, and agent-friendly contracts, extension authors get the same upside as theme authors:

• Stricter Liquid and Theme Check fail earlier — before App Store review or a merchant’s live theme.
• Standard Actions/Events reduce one-off cart and interaction glue between apps and themes.
• Agent-readable structure means merchants using Sidekick (and developers using Cursor/Claude) are more likely to compose with your extension instead of fighting opaque JSON templates.

You do not need to rewrite everything tomorrow. You do need to treat Liquid quality, schema honesty, and storefront contracts as product surface — not afterthoughts.

What to do this week

1. Read Ben’s post — Liquid: Back to the future — end to end.
2. Open the developer preview docs and skim the new template/block/partial model.
3. Confirm your theme and theme app extension Liquid against the strict parser migration guide if you have not already.
4. Add agent guidance where you own a theme (.agents / AGENTS.md / design tokens) so Sidekick and coding agents do not invent APIs you never shipped.

Liquid is not being replaced. It is being made legible again — for the same people who always wanted that, and for the agents now writing half the first draft.

That is a good kind of “back to the future.”