Shopify Hydrogen und Next.js: Ein praktikablerer Weg für Headless Commerce

Shopifys neue Hydrogen-Richtung wurde am 17. Juni 2026 öffentlich sichtbar, als Shopify die Developer Preview des neuen Hydrogen veröffentlicht hat. Diese Preview stellte Hydrogen als ein stärker framework-agnostisches und runtime-agnostisches Toolkit vor, das in Zusammenarbeit mit Vercel neu gedacht wurde und mit dem Frontend-Stack funktionieren soll, den ein Team bereits nutzt. Das spezifischere Next.js- und Vercel-Update folgte am 30. Juni 2026, als Shopify ankündigte, dass sich die Hydrogen Developer Preview über einen neuen Deploy Button mit wenigen Klicks auf Vercel deployen lässt. Dieser Button erstellt ein Repository auf Basis des Next.js Starter Templates, richtet ein Vercel-Projekt ein und baut die Storefront, ohne dass dafür ein lokales Setup nötig ist. (hydrogen.shopify.dev)

Diese zeitliche Einordnung ist wichtig, weil die News leicht missverstanden werden kann. Hydrogen wird nicht wortwörtlich Teil von Next.js. Besser beschrieben ist es so: Shopify macht Hydrogen innerhalb eines Next.js-basierten Setups nutzbar und öffnet das neue Hydrogen Toolkit gleichzeitig schrittweise für weitere Frameworks. Für Teams, die bereits mit Next.js arbeiten, wird die Headless-Shopify-Diskussion dadurch deutlich praktischer, weil sie mehr von ihrer bestehenden Frontend-Architektur behalten und trotzdem Shopify-spezifische Commerce-Tools nutzen können.

Lange lief die Headless-Diskussion bei Shopify auf einen recht praktischen Tradeoff hinaus. Wenn ein Team die Shopify-nativste Headless-Erfahrung wollte, war Hydrogen der naheliegende Kandidat. Es bot einen Commerce-fokussierten Startpunkt und eine klare Shopify-Meinung dazu, wie eine Custom Storefront gebaut werden sollte. Wenn ein Unternehmen aber bereits ein ausgereiftes Next.js-Setup, bestehende Entwickler, etablierte Deployment-Workflows und eigene Frontend-Konventionen hatte, konnte sich Hydrogen schnell wie ein zusätzlicher Stack anfühlen, der nur für die Storefront eingeführt werden musste.

Dieser Tradeoff war nicht immer ideal. In größeren Unternehmen wird das Frontend-Framework oft nicht isoliert für ein einzelnes Projekt entschieden. Es kann bereits für Marketing-Websites, Kundenportale, interne Tools, Dashboards, Dokumentation, Content-Plattformen oder andere digitale Produkte im Einsatz sein. Dazu kommen häufig Component Libraries, CI/CD-Pipelines, Monitoring, Testing-Patterns und Security-Prozesse, die auf diesem Setup aufbauen. In so einem Umfeld lautet die Frage selten: „Welches Framework ist theoretisch am besten?“ Die realistischere Frage ist: „Welche Architektur kann das Team tatsächlich bauen, warten und über Jahre weiterentwickeln?“

Genau deshalb ist die neue Hydrogen-Richtung interessant. Shopify trennt die commerce-spezifische Ebene stärker von der Entscheidung für ein bestimmtes Frontend-Framework. In der Hydrogen Developer Preview nennt Shopify verschiedene Framework-Pfade, darunter React Router mit Hydrogen und Oxygen sowie Next.js mit Hydrogen und Vercel. Die Idee ist nicht, dass ab jetzt jedes Team Next.js nutzen muss. Die Idee ist, dass Hydrogen an mehr Stellen sinnvoll eingesetzt werden kann. (shopify.dev)

Für Teams, die bereits mit Next.js arbeiten, entfernt das eine Menge unnötige Reibung.

Auch die Vercel-Seite der Ankündigung ist relevant. Vercel sagt, dass das Unternehmen gemeinsam mit Shopify daran arbeitet, Hydrogen von Grund auf neu zu bauen, mit dem Ziel, es offener und portabler zu machen. Vercel beschreibt die neue Version außerdem als Open Source und runtime-agnostisch, mit Unterstützung für Frameworks wie Svelte, Nuxt, Next.js oder auch ein eigenes Custom Framework. (vercel.com)

Dieses Detail ist wichtig, weil schlechte Framework-Integrationen schnell auffallen. Entwickler merken, wenn ein Tool für eine Umgebung entwickelt und anschließend nur umständlich an eine andere angepasst wurde. Wenn Hydrogen gut in Next.js funktionieren soll, darf es nicht einfach ein Wrapper um einen anderen Stack sein. Es muss zu der Art passen, wie Next.js-Teams tatsächlich Anwendungen bauen.

In der Praxis bedeutet das: Die Grenze zwischen den Verantwortlichkeiten muss klar sein. Next.js sollte das übernehmen, worin Next.js stark ist: Routing, Rendering, Caching-Strategien, Deployment-Workflows und die übergreifende Struktur der Webanwendung. Hydrogen sollte die Shopify-spezifische Commerce-Schicht abdecken: Storefront API Access, Cart-Verhalten, Produkt- und Collection-Logik, Money Formatting, Markets, Analytics, Consent und andere Commerce-Primitives. Wenn diese Aufteilung gut funktioniert, bekommen Teams im besten Fall beides: Sie können die Frontend-Architektur behalten, die sie bereits kennen, und müssen gleichzeitig grundlegendes Shopify-Verhalten nicht komplett selbst nachbauen.

Bei kleineren Shopify-Projekten ist die Architekturentscheidung oft relativ einfach. Ein gutes Shopify Theme, sauber umgesetzt, ist meistens die richtige Antwort. Es bleibt nah am nativen Shopify-Ökosystem, ist für nicht-technische Teams einfacher zu bedienen und verursacht meist weniger Wartungsaufwand. Nicht jeder Merchant braucht Headless, und nicht jede Marke profitiert von zusätzlicher technischer Komplexität.

Shopify Plus und Enterprise-Commerce-Projekte sind anders. Die Storefront ist dort oft nur eine sichtbare Ebene eines deutlich größeren Systems. Ein ernstzunehmendes Shopify Plus Projekt kann ein CMS, PIM, ERP, CRM, OMS, eine Search-Lösung, Analytics, Consent Management, Loyalty-Logik, Customer Accounts, B2B Pricing, kundenspezifische Kataloge, Approval Workflows und marktspezifische Anforderungen umfassen. Ab diesem Punkt ist die Storefront nicht mehr nur ein Ort, an dem Produkte dargestellt werden. Sie wird Teil einer größeren Commerce-Plattform.

Genau hier wird die Kombination aus Hydrogen und Next.js relevanter. Viele Enterprise-Teams wollen keinen schönen Demo-Stack, der isoliert gut funktioniert. Sie brauchen eine Architektur, die zu bestehenden Systemen, internen Engineering-Standards und dem langfristigen Ownership-Modell passt. Für solche Teams kann es deutlich wertvoller sein, Shopify Commerce Tooling innerhalb von Next.js zu nutzen, statt in einen bestimmten, von Shopify bevorzugten Frontend-Stack gedrückt zu werden.

Eine individuelle Shopify Storefront kann am Anfang recht einfach wirken. Man fragt Produkte über die Storefront API ab, rendert eine Produktseite, baut einen Warenkorb, leitet Nutzer zum Checkout weiter und verbindet das notwendige Tracking. Für einen Prototypen fühlt sich das oft sehr machbar an.

Schwierig wird es später. Preise müssen über Markets hinweg korrekt funktionieren. Produktverfügbarkeit muss zuverlässig sein. Der Warenkorb muss über Sessions und Edge Cases hinweg stabil laufen. Die Übergabe an den Checkout muss sauber sein. Analytics müssen Consent respektieren. Caching muss die Performance verbessern, ohne falsche oder veraltete Commerce-Daten auszuliefern. Lokalisierung und Währungsverhalten müssen zum Geschäftsmodell passen. SEO muss den Wechsel überstehen. Redirects müssen sauber abgebildet werden. Interne Teams müssen verstehen, wie sie das System nach dem Launch warten können.

Nichts davon ist besonders aufregend. Aber genau an diesen Stellen werden Headless-Projekte teuer.

Deshalb sind offizielle Commerce-Primitives wichtig. Wenn Shopify eine bessere Standardschicht für die Teile bereitstellt, die ohnehin jede Headless Storefront braucht, können Teams weniger Zeit damit verbringen, generische Commerce-Logik neu zu bauen, und mehr Zeit in die Dinge investieren, die das Unternehmen wirklich unterscheiden. Das kann ein komplexer B2B Buying Flow sein, eine individuelle Product Discovery Experience, eine tiefe CMS-Integration, eine Multi-Market-Architektur oder ein sehr spezifischer ERP-Workflow.

Ankündigungen wie diese werden schnell überinterpretiert. Dass Hydrogen flexibler wird, bedeutet nicht, dass jeder Shopify Merchant seine Storefront als Headless-Projekt neu bauen sollte. Ein starkes Shopify Theme ist weiterhin für viele Unternehmen die bessere Wahl, auch für viele Unternehmen mit ernstzunehmendem Umsatz. Themes sind einfacher zu betreiben, näher am Shopify-App-Ökosystem und in der Regel schneller zu launchen. Sie machen außerdem das Leben von Ecommerce-Teams leichter, die Inhalte, Apps, Promotions und Merchandising ändern müssen, ohne für jede kleine Anpassung von Entwicklern abhängig zu sein.

Headless ergibt Sinn, wenn es einen echten Grund dafür gibt. Das kann eine sehr individuelle Frontend Experience sein, komplexe Content- und Commerce-Anforderungen, internationale Architektur, starke Anforderungen an Performance-Kontrolle, B2B Workflows oder ein Frontend, das über mehrere Systeme hinweg funktionieren muss. Es kann auch sinnvoll sein, wenn ein Unternehmen bereits ein starkes internes Next.js-Setup hat und Shopify zwar die Commerce-Schicht liefern soll, aber nicht die gesamte Anwendungsarchitektur vorgeben soll.

Für bestehende Hydrogen-Projekte ist das kein Grund zur Panik. Shopify sagt, dass der aktuelle Hydrogen-Stack weiterhin unterstützt wird und heute laufende Storefronts so weiter funktionieren wie bisher. Shopify sagt außerdem, dass Migrationshinweise folgen werden, sobald die neuen APIs stabiler sind. (hydrogen.shopify.dev)

Eine funktionierende Storefront mit einem klaren Wartungsmodell sollte nicht neu gebaut werden, nur weil ein neues Starter Template existiert. Wenn ein Team aber ohnehin gerade ein Replatforming, ein neues Shopify Plus Projekt oder einen Headless Architecture Review plant, sollte diese neue Richtung Teil der Diskussion sein.

Die hilfreichen Fragen lauten nicht isoliert: „Sollten wir Hydrogen nutzen?“ oder „Sollten wir Next.js nutzen?“ Die besseren Fragen sind praktischer. Was kennt das interne Team bereits? Welche Systeme müssen an die Storefront angebunden werden? Wie viel individuelle Frontend-Kontrolle braucht das Business wirklich? Wie wichtig ist Shopify-App-Kompatibilität? Wer ist für Performance verantwortlich? Wer verantwortet Tracking und Consent? Wer wartet die Storefront nach dem Launch?

Die letzte Frage ist meistens die wichtigste.