Warum Shopify die Theme-Struktur zurück in lesbaren Code verlegt – und was das für Entwickler, Händler und Agenten freischaltet.
Vor genau 12 Jahren begann ich, meinen ersten Shopify-Shop zu bauen.
Ich war nicht wirklich ein Entwickler. Ich war ein technisch versierter Designer, der HTML, CSS und gerade genug jQuery beherrschte, um gefährlich zu sein. Was ich wusste, war, dass ich einen Storefront wollte, der sich völlig individuell für die Marke anfühlte, die ich aufbaute – aber ich wollte nicht einen ganzen Commerce-Stack verwalten, nur um dorthin zu gelangen.
Dann fand ich Shopify.
Ich lud Timber herunter, öffnete die Collection-Vorlage, und alles ergab Sinn:
1{% for product in collection.products %}2 {% include 'product-grid-item' %}3{% endfor %}
Die gesamte Vorlage hatte 100 Zeilen Code. Ich konnte verstehen, wie sie funktionierte, indem ich einfach den Code las. Ich brauchte kaum die Dokumentation, abgesehen von Mark Dunkleys Spickzettel.
Für Theme-Entwickler war das eine goldene Ära der Lesbarkeit. Für Händler waren die globalen Theme-Einstellungen eindeutig nicht genug.
Der Kompromiss, den wir eingegangen sind
Theme-Einstellungen brachten uns nur bis zu einem bestimmten Punkt. 2016 führte Shopify Sections ein, und drei Dinge änderten sich gleichzeitig.
- Händler wurden zu Merchandisern. Menschen, die nicht coden konnten, konnten Seiten gestalten und eine viel reichhaltigere Produktgeschichte erzählen.
- Entwickler wurden zu Komponenten-Designern. Sections mussten modular, flexibel und in beliebiger Reihenfolge funktionieren.
- Und Themes wurden zu Produkten. Entwickler mussten über die Benutzeroberfläche nachdenken, die sie gestalteten, und bewusste Abwägungen zwischen Benutzerfreundlichkeit und Flexibilität treffen.
Diese Kräfte beschleunigten sich mit Dawn im Jahr 2016 und dann erneut mit Horizon im letzten Jahr, sowie der Einführung von „Blöcken“ als der zentralen komponierbaren Einheit in Themes.
Um Sections und Blöcke in jeder Vorlage darzustellen, benötigte Shopify ein Serialisierungsformat. Vorlagen wurden zu JSON.
Dieser Kompromiss gab Händlern viel mehr Kontrolle, aber er hatte einen Preis für die Entwicklererfahrung: Man konnte eine Seite nicht mehr durch das Lesen einer einzigen Datei verstehen. Man musste JSON, Liquid, Schemas, Einstellungen, Sections und Blöcke abgleichen, um zu rekonstruieren, wie die Seite funktionierte.
In dem Moment, als Vorlagen zu JSON wurden, hörten sie auf, eine großartige Entwickleroberfläche zu sein. Sie wurden zu einer automatisch gespeicherten Ausgabe – etwas, vor dem wir Entwickler buchstäblich warnten, es von Hand zu bearbeiten.
Das war ein vernünftiger Kompromiss für die Ära der „imperativen Software“; in der Händler einen Shop durch Schaltflächen, Knöpfe und Einstellungen formten, um genau festzulegen, was sich ändern sollte.
KI verändert die Gleichung.
Eine großartige Entwicklererfahrung ist eine großartige Agentenerfahrung
Als wir Sidekick die Fähigkeit gaben, Themes zu bearbeiten, betrat der Online Store Editor seine Ära der „deklarativen Software“. Ein einfaches Beispiel: Anstatt einen Farbwähler zu öffnen und [#0000FF](https://x.com/search?q=%230000FF&src=hashtag_click) auszuwählen, konnte ein Händler einfach sagen: „Mach das blau.“
Händler haben in diesem Jahr bereits 25 Millionen Sidekick-Theme-Bearbeitungen vorgenommen, und jeder fünfte Händler nutzt KI, um sein Theme zu bearbeiten.
Gleichzeitig nutzen zunehmend Entwickler Agenten, um Code zu schreiben. Das bedeutet, dass Shopify jetzt zwei verbundene Aufgaben hat:
- Agenten bessere Anleitungen geben.
- Agenten besseres Feedback geben.
Für Anleitungen veröffentlichen wir verbesserte Liquid-Fähigkeiten. Themes können auch Agenten-Anweisungen über ein .agents-Verzeichnis tragen und Dateien wie AGENTS.md und DESIGN.md enthalten, um Codierungsagenten zu helfen zu verstehen, wie du Code geschrieben haben möchtest und wie du deine Designs markenkonform hältst.
Für Feedback haben wir das {% doc %}-Tag zu typisierten Verträgen für Snippets und Blöcke erweitert. Parameter können dokumentiert, typisiert, von Theme Check validiert und mit Beispielen zur Verwendung gepaart werden.
1{% doc %}2 @param {string} [variant]3 @param {string} [tag]45 @example6 {% block 'text', tag: 'h1' %}7 Ausgewählte Kollektion8 {% endblock %}9{% enddoc %}
Wenn du Code von Hand schreibst, gibt dir das Echtzeit-Feedback, IntelliSense und Fehler; und es gibt Agenten auch eine Möglichkeit, gültige Parameter zu entdecken, zu lernen, wie eine gute Ausgabe aussieht, und umsetzbares Feedback zu erhalten, wenn sie eine API halluzinieren, die nicht existiert.
Wir haben außerdem 20 neue Theme Check-Regeln hinzugefügt, die Verträge, Struktur, Validierung, Komplexität, Verschachtelung und Dateigrößenlimits abdecken.
Das Erstaunliche für Entwickler wie mich im Zeitalter der Agenten ist, dass es dieselben Dinge belohnt, die wir schon immer wollten: lesbaren Code, explizite Verträge und schnelles Feedback.
Also stellten wir eine größere Frage: Wie würde die ideale Theme-Architektur aussehen, wenn man diese Eigenschaften als Grundprinzipien behandelt?
Wir haben ein neues Shopify-Basis-Theme entwickelt, das all unsere Ideen zusammenführt.
(Ich sollte erwähnen … das ist eine neue Architektur, um für Codierungsagenten zu optimieren, aber es ist kein erzwungenes Umschreiben. Bestehende Themes werden für immer funktionieren; Liquid war und wird immer eine API für die Ewigkeit sein.)
Seitenstruktur ist wieder lesbarer Code
Das erste, was dir am neuen Theme auffallen wird, ist, wenn du das templates-Verzeichnis öffnest; die Vorlagen sind wieder Liquid-Dateien.
Die Collection-Vorlage ist ungefähr so lang wie die von Timber, und das gesamte Theme hat 93 % weniger Codezeilen als Horizon. Es ist nicht als ein rundum-sorglos-Theme wie Horizon gedacht, sondern es macht es wirklich einfach, mit allen Commerce-Primitiven in Shopify zu bauen und eine Grundlage dafür zu schaffen, wie man die bestmögliche Leistung erzielt, überlässt es dir aber, all die Dinge zu bauen, die jeden Händlershop einzigartig machen.
Warum die Seitenstruktur zurück in Liquid verlegen?
Das tiefere Problem mit serialisierter Konfiguration ist nicht, dass JSON grundsätzlich schlecht ist. Es ist, dass Konfiguration einen eingeschränkten Wortschatz hat. Ein Theme-Entwickler muss die Zusammensetzungen vorhersehen, die ein Händler wünschen könnte.
Stell dir eine Section mit einer Schaltfläche vor. Ein Händler bittet einen Agenten, eine zweite Schaltfläche daneben zu setzen.
In einer settings-getriebenen Architektur muss das Theme bereits eine Gruppen-Block verfügbar machen, der beide Schaltflächen aufnehmen kann, oder der Entwickler muss eine Einstellung für eine zweite Schaltfläche vorhergesehen haben.
In HTML fügst du eine weitere Schaltfläche hinzu und umschließt das Paar mit einem div.
Jedes führende Modell versteht bereits HTML. Es ist ausdrucksstark, lokal und tokeneffizient. Und Shopify hat seit mehr als 20 Jahren die Sprache, die benötigt wird, um diese Ausdruckskraft mit Commerce zu kombinieren: Liquid.
Blöcke und HTML, gemeinsam
Die neue Architektur führt ein komponierbares {% block %}-Tag ein, das direkt in Liquid-Vorlagen verwendet werden kann.
1<div class="mb-8">2 {% block 'text',3 tag: 'h1',4 block.settings.variant: 'type-heading-xl',5 class: 'mb-2'6 %}7 {{ collection.title | escape }}8 {% endblock %}9</div>
Blöcke akzeptieren benannte Parameter. Sie können verschachtelte Inhalte enthalten. Ihre Parameter können durch {% doc %} typisiert werden. Sie definieren die Grenzen dessen, womit Händler interagieren können, während gewöhnliches HTML alles andere handhabt.
Wenn du ein Komponentensystem wie React verwendet hast, wird dir das Modell vertraut vorkommen: Parameter verhalten sich wie Props, und verschachtelte Inhalte wie Children. Aber es bleibt Liquid – einfach genug, um von oben nach unten in einer Datei gelesen zu werden.
Das macht die Komposition explizit, ohne dass jedes Markup-Stück zu einer weiteren Section, einem weiteren Block oder einer weiteren Einstellung werden muss.
Feingranulare Reaktivität mit Partials
Theme-Entwickler haben die Section Rendering API weit über das hinaus beansprucht, wofür sie ursprünglich entwickelt wurde, weil sie das beste verfügbare Werkzeug für servergetriebene Reaktivität war.
Wir wollten etwas Präziseres.
Inspiriert von aufkommenden Arbeiten zu deklarativen partiellen Updates, bringen wir ein einfaches Primitiv namens Partials zu Liquid.
Umschließe einen Bereich, der neu gerendert werden kann:
1{% partial 'cart-count' %}2 <span>3 {{ 'cart.count' | t: count: cart.item_count }}4 </span>5{% endpartial %}
Dann rufe frisches HTML ab und wende es an, wo nötig:
1const html = await partials.fetch('cart-items', 'cart-count');2partials.apply(html);
Das war‘s. Feingranulare servergerenderte Updates, ohne eine gesamte Section zu rendern oder ein virtuelles DOM einzuführen.
Das Hinzufügen zum Warenkorb kann die relevanten Warenkorbbereiche in wenigen Zeilen aktualisieren. Dieses eine Primitiv wird es uns ermöglichen, Tausende von Zeilen Reaktivitätscode aus Horizon zu entfernen.
Standard Events und Actions
Wir machen auch häufige Storefront-Interaktionen einfacher und interoperabler.
Standard Actions bieten einen gemeinsamen Vertrag für Operationen wie das Aktualisieren eines Warenkorbs. Standard Events lassen Themes und Apps über dasselbe stabile Vokabular reagieren.
1const { cart } = await Shopify.actions.updateCart({2 lines: [{3 merchandiseId: variant.id,4 quantity: 1,5 }],6});
Das ist für Entwickler einfacher zu schreiben, für Apps einfacher zu integrieren und für Agenten einfacher zu verstehen. Standard Actions funktionieren heute in allen Shopify-Shops, und die WebMCP-Unterstützung gibt Browser-Agenten einen semantischen Pfad, um Produkte zu durchsuchen und hinzuzufügen, während der Storefront auf diese Interaktionen reagiert.
Das Ziel ist nicht, einen „KI-Modus“ an den Storefront zu schrauben. Es geht darum, die Fähigkeiten des Storefront klar und komponierbar für jeden Teilnehmer zu machen: Themes, Apps, Entwickler und Agenten.
Liquid sicherer weiterentwickeln
Es gab auch einige offensichtliche Sprachfähigkeiten, die wir Liquid hinzufügen wollten: boolesche Ausdrücke, Infix-Operatoren mit Priorität und literale Arrays und Objekte.
Der Hinderungsgrund war nicht mangelnder Wunsch. Liquids historischer Parser akzeptierte mehrdeutige Syntax, die formal nicht gültig war. Die Einführung neuer Syntax konnte daher das Verhalten bestehender Themes ändern.
Das Team unternahm eine große Migration, um Themes sicher auf einen strengen Parser umzustellen. Diese Arbeit gibt uns Raum, Liquid weiterzuentwickeln, ohne die Storefronts zu brechen, die bereits davon abhängen.
Es ermöglicht einfachere, vertrautere Ausdrücke:
1{{ 1 + 1 }}2{{ false && false || true }}3{% assign products = ["shirt", "hat", "shoes"] %}
Es macht Fehler auch vorhersehbarer – für Entwickler und für Agenten.
Noch etwas: Tailwind
In Kürze bringen wir Tailwind-Unterstützung für Liquid-Themes.
Agenten sind großartig darin. Entwickler verstehen es bereits. Und es gibt uns eine gemeinsame Styling-Sprache, die um Design-Tokens herum aufgebaut ist, ohne Händler zu zwingen, ein kompliziertes Build-System zu erben.
Dieses gemeinsame Vokabular ist wichtig. Je besser Agenten Struktur, Verträge und Styling-Absicht verstehen, desto mehr können sich Entwickler auf die Teile eines Storefront konzentrieren, die eine Marke tatsächlich differenzieren.
Zurück in die Zukunft
Vor zwölf Jahren hat Shopify für mich geklickt, weil ich ein Theme öffnen, den Code lesen und den Shop verstehen konnte.
Im Laufe der Zeit haben wir Themes für Händler enorm flexibler gemacht, aber der Code wurde schwerer durchschaubar.
Agenten geben uns die Chance, diese beiden Dinge wieder zu vereinen: die Flexibilität, die Händler brauchen, und die Lesbarkeit, die Entwickler verdienen.
Das ist die Richtung hinter dieser neuen Architektur:
- Liquid-Vorlagen als lesbare Seitenstruktur.
- Komponierbare, typisierte Blöcke neben gewöhnlichem HTML.
- Agenten-Fähigkeiten und Anleitungen auf Repository-Ebene.
- Reichhaltigeres Feedback durch
{% doc %}und Theme Check. - Feingranulare Reaktivität durch Partials.
- Gemeinsame Storefront-Verträge durch Standard Events und Actions.
- Ein strenger Parser, der es Liquid ermöglicht, sich sicher weiterzuentwickeln.
- Tailwind als gemeinsame Styling-Sprache.
Die Entwickler-Vorschau und Dokumentation sind jetzt verfügbar:
https://shopify.dev/docs/storefronts/themes/getting-started/developer-preview
Probier es aus und sende mir dein Feedback. Ich kann es kaum erwarten zu sehen, was du baust!
