[Participant Report Vol. 2] Shopify DotDev 2026 — The Future of Liquid: Liquid for Humans Is Liquid for Agents

I'm Rossella, a front-end developer at Flagship, and this is the second installment of our Shopify DotDev 2026 report series. Vol. 1 covered the event as a whole and the highlights from Toronto. From here on, we take one theme at a time, starting with something Vol. 1 only touched on briefly: Shopify's change of direction for Liquid, its theme templating language.

Of all the sessions at this year's Shopify DotDev, the one on the future of Liquid wasn't even on the original schedule. It was added a few days before the event and ended up running twice in one day.

The talk was led by Ben Sehl, Shopify's Product Director for Online Store, who also spoke about these changes in his interview for the Liquid Weekly podcast.

In a lineup mostly built for app developers, it was one of the only talks aimed at theme developers, which is part of why I wanted to write it up in some detail.

Here's what Ben shared, what it means practically, and what's actually usable today versus what's still being shaped.

The big picture: from Liquid, to JSON, and back to Liquid

Liquid is what got Ben hooked on Shopify themes in the first place: simple enough to understand at a glance. For years, Mark Dunkley's Liquid Cheatsheet was genuinely all a theme developer needed to be productive.

Then came Sections Everywhere, and with it, JSON templates.

That trade-off made sense at the time: Shopify needed a serialization format to power the theme editor and make the settings sidebar work, and JSON was the right way to get there.

Ben's framing for it stuck with me: "design is a trade-off".

Horizon's fully JSON-driven structure was the right call for that era, but it came at a real readability cost. A page that used to be one Liquid file top-to-bottom became logic split across a tree of sections, blocks, and nested settings objects, much of it auto-generated by the Shopify admin theme editor and flagged with a warning that any manual changes risk being overwritten.

The concrete cost of that trade-off is easy to see: when Ben rebuilt a collection page under the new architecture, it matched the line count of Timber, Shopify's original theme framework from the platform's early days (before sections existed at all), and cut 93% of the lines Horizon's JSON-plus-Liquid version needed for the same page. The JSON layer wasn't adding capability; it was pure overhead.

So Shopify is reversing course: page structure is moving back out of JSON and into readable Liquid. Horizon was the right call back when JSON was the only practical way to power the theme editor and settings sidebar. That constraint just doesn't hold the same way anymore, which is why the structure is moving again.

That's the readability argument. But there's a second, bigger force behind the reversal: a shift in how software itself gets built.

From imperative to agentic

Imperative software makes you manually set every parameter, like turning a dial to a precise level, to get the result you want. An agentic approach flips that: you describe the outcome ("make it louder"), and the agent figures out how to get there.

Ben's core point is that a great developer experience is a great agent experience. The two aren't in tension: the same qualities that make Liquid pleasant for a person to read (small vocabulary, predictable structure, plain-English-adjacent syntax) are exactly what make it easy for a model to read and generate correctly.

Everything below (new operators, structure moving into Liquid instead of JSON, a stricter parser, typed documentation, Tailwind support) traces back to that one idea.

Zoom out, and it's really the thesis of the whole talk: Shopify isn't optimizing Liquid for AI at the expense of developers, or vice versa. It's betting that those two goals point in the same direction, and that a language good agents can use well is, not coincidentally, a language good developers enjoy using too. It's worth keeping that thesis in mind as the frame for everything below.

What's changing: three things Shopify is focusing on

Ben grouped the work into three buckets: writing clean code, guidance, and feedback. Here's what falls under each, with the technical detail this time.

1. Writing clean code

Liquid was missing things most languages take for granted: booleans, arrays and hashes as first-class variables, infix operators with real precedence. Filling those gaps makes the language easier to evolve without accumulating the kind of workarounds that made it hard to reason about in the first place.

{{ 1 + 1 }} => 2
{{ false && false || true }} => true

{% assign array = ["Hello", "world", "isn't", "this", "wonderful?!"] %}

2. Guidance

Shopify now drops theme files that don't follow its conventions on upload, so a theme looks and behaves consistently no matter whose store it's in: anyone (or any agent) jumping into the code should recognize the shape of it immediately. That consistency is backed by a few concrete pieces.

AGENTS.md and DESIGN.md. AGENTS.md is a base-theme guide that documents a theme's specific conventions and the mistakes agents are most likely to make (no auto-generated JSON templates, block-first composition, utility-class-only styling, no global-scope DOM access, and so on). It exists so any agent, or any new developer, touching the theme starts from the same page. DESIGN.md is a spec for describing a theme's visual identity to agents, combining machine-readable design tokens (colors, type scale, spacing, radius) as YAML front matter with plain-language rationale for why those values exist and how to apply them.

Liquid templates, not JSON, and the new {% block %} tag. Moving structure back into Liquid means an agent (or a developer) can read a whole page's composition in one file instead of reconstructing it across a JSON tree. The new {% block %} tag makes that composition explicit: blocks can accept named parameters and nested content, with a real closing tag, similar in spirit to React props and children.

{% block 'text', tag: 'h1', class: 'mb-2' %}
  {{ collection.title | escape }}
{% endblock %}

The {% doc %} tag pairs with this to give type-safe contracts: typed @param definitions plus live @example blocks, so a snippet or block documents not just its parameters, but exactly what a correct call looks like, for the next agent or developer who needs to use it.

Tailwind CSS support, coming to Liquid themes. Adam Wathan (Tailwind's creator, who's also spent a lot of time on the ui.sh team thinking about how agents produce better output) sat in on the first session. Shopify's reasoning: a shared, constrained styling vocabulary is easier for both humans and agents to reason about than bespoke component CSS.

Agent Skills. Ben also published an open-source companion repo of Claude Agent Skills for Liquid theme development (benjaminsehl/liquid-skills), installable with claude skill install --plugin shopify-theme-skills benjaminsehl/liquid-skills. It's worth trying directly if you use Claude Code for theme work.

3. Feedback

A stricter Liquid parser closes off the old "lax parser" ambiguities that used to let invalid syntax silently produce unpredictable output. A big motivation here, beyond cleanliness, was that agents were hallucinating Liquid syntax that never existed. A language with fewer edge cases to guess at is a language models get right more often.

Linters need to catch errors before they ship, too. Theme Check has picked up roughly 20 new rules covering contracts, file structure, validation, and Liquid complexity/nesting, and the {% doc %} tag now gives you type-safe contracts for snippets and blocks: parameters have to match, and you can bake examples directly into the documentation.

The two biggest capability additions

Clean code, guidance, and feedback cover the language-quality work. Two more changes stand apart from that framing because they're new capabilities rather than polish. And one of them, partials, is arguably the single most useful piece of news in the whole preview.

Reactivity with partials

Before partials, updating something as simple as the cart count meant fetching the entire header through the section rendering API, then running a DOM-diffing library like morphdom to figure out which single element actually changed, plus extra JS to handle the edge cases it missed.

Shopify wanted to stay dependency-free rather than add another library, so the team looked at other paradigms first, Rails Hotwire among them, before landing on "Declarative Partial Updates," a blog post from the Chrome team describing a way to use valid HTML comments as boundaries the browser can re-render on its own, with no virtual DOM and no extra JavaScript needed.

You wrap just the region that needs to update, fetch fresh HTML for that region, and swap it in:

{% partial 'cart-count' %}
  <span>{{ 'cart.count' | t: count: cart.item_count }}</span>
{% endpartial %}

const html = await partials.fetch('cart-items', 'cart-count');
document.startViewTransition(() => partials.apply(html));

The partial still renders server-side too: it runs through Liquid, and some validation genuinely needs to happen on the server. Ben said he was able to build a page with infinite scroll, using an IntersectionObserver that doesn't break the back button, in seven lines of code.

Partials also let Shopify drop libraries like morphdom entirely from the new base theme, a meaningful chunk of the JavaScript payload reduction. Shopify worked directly with the Chrome team on the proposal, and all major browsers have now aligned on the approach, with a polyfill available in the meantime.

This is currently in Developer Preview (Liquid July '26). The API is still being shaped based on feedback before it's finalized.

Standard Events and Actions with WebMCP support

Standard Events and Actions round out the picture: shared, typed contracts for common storefront operations (updating a cart, for instance).

const { cart } = await Shopify.actions.updateCart({
  lines: [{
    merchandiseId: variant.id,
    quantity: 1,
  }],
});

Standardizing this surface is also what enables WebMCP support: agents and tools get a documented way to trigger storefront actions and read storefront events, instead of needing a bespoke integration per theme.

This one's already released (see the changelog).

What's usable today

Here's the honest state of play, beyond the six pieces above. Two supporting pieces are still catching up separately: the theme editor itself, and profiling/debugging tools.

* Not to be confused with agents.md.liquid, an existing, unrelated Shopify feature that helps shopping agents discover a store's commerce info, rather than a coding-agent convention file for the theme itself.

This is officially the "Liquid July '26" Developer Preview, dated July 21, 2026. To try it yourself, you'll need a development store with that preview enabled. Shopify also published a skeleton theme release candidate (v2.0.0) as a starting point, and Theme Check v3.28.0+ carries the new validation rules for the {% block %} and {% partial %} tags specifically (syntax errors, complexity, file size, schema structure, argument consistency).

One reassurance that came up repeatedly: there's no "Liquid 3.0." Shopify is deliberately not attaching a version number to any of this, specifically to avoid creating unnecessary fear of a breaking change.

What this means for you

If you're a developer

Everything here is backward-compatible. You can adopt the new architecture at your own pace, or not at all, and existing themes are fully supported. Some of it is available in Developer Preview on preview stores now, so you can start getting hands-on before it's a client conversation. If you're using Claude Code for theme work, benjaminsehl/liquid-skills is a concrete, free way to start today. Expect the theme editor and profiling/debugging tooling to lag the underlying architecture. Both are explicitly planned for "later this year," not now.

If you're a merchant

Nothing breaks. Your current theme keeps working exactly as it does today, and none of this requires any action from you. Horizon isn't being replaced. It'll be updated with performance improvements and features like partials, but Shopify has no plans to build another flagship theme. The strategy is a solid base theme plus tools, with partners and agencies building specialized, premium experiences on top.

The practical upside, once this lands broadly: faster storefronts (smaller JS payloads, fewer dependencies) and themes that are easier for developers, and for AI copilots like Sidekick, to work on correctly.

Bringing it back to where I started: this isn't really a story about new syntax. It's Shopify betting that the best way to prepare for an agentic future is the same thing that's always made a codebase good to work in by hand: simple, readable, well-documented code. Good developer experience and good agent experience were never actually two different problems.

Sources

• Ben Sehl, "Back to the Future with Liquid": talk notes and companion article
• Ben Sehl, Liquid Weekly podcast interview
• Liquid Cheatsheet, Mark Dunkley
• Agent Skills repo: benjaminsehl/liquid-skills
• ui.sh
• Shopify changelog: Liquid block and partial tags developer preview