¿Por qué Hydrogen necesitaba un rewrite?
¡Hola Devs! Hydrogen hizo fácil shippear storefronts headless de Shopify, pero no eran portables. Quedabas atado a un runtime específico y cada equipo escribía el mismo glue code desde cero. Eso no escala, ¿va?
En Vercel Ship 26, en Nueva York, Vercel y Shopify anunciaron que están reconstruyendo Hydrogen desde cero. La nueva versión es open source y runtime-agnostic — corre en cualquier lugar donde corra JavaScript. Puedes usar Svelte, Nuxt, Next.js o traer tu framework custom. ¡Vamos a ver!
La arquitectura se dividió en tres capas: core, client y server. Cada una resuelve un tipo específico de repetición que los devs de e-commerce llevan duplicando por años.
Según el anuncio original de Vercel, es una apuesta de largo plazo a la neutralidad de framework, no a un template de un solo vendor.
Capa Core: deja de reescribir glue code de la API de Shopify
La capa core es ese JavaScript que todos escribíamos para la API de Shopify y nunca compartíamos. Fíjate en formatMoney — la web abierta ya resolvió esto con Intl.NumberFormat:
const price = new Intl.NumberFormat("es-MX", {
style: "currency",
currency: "MXN",
}).format(19.99);
// "$19.99"
Pero la API de Shopify no te entrega un number. Responde con un tipo custom, MoneyV2, y el monto es un decimal serializado como string. Ahí entra el core de Hydrogen:
import { formatMoney, type MoneyV2 } from "@shopify/hydrogen";
export function formatPrice(money: MoneyV2, locale = "es-MX") {
return formatMoney(money, { locale }).toString();
// $19.99
}
El resultado es el mismo, pero ya no escribes ni mantienes el glue code. Cuando la API cambia, el upgrade es trivial. Centraliza el core y arreglas cada bug una sola vez, distribuyes la mejora a todos y regresas a construir lo que importa.

Capa Client: estado del carrito en un solo import
Renderizar lo que devuelve el core implica las mismas decisiones repetidas. El estado del carrito es el ejemplo obvio. Quien haya construido un e-commerce escribió algo así:
import { createContext, useContext, useState, useCallback } from "react";
const CartContext = createContext(null);
export function CartProvider({ children }) {
const [cart, setCart] = useState(null);
const addLine = useCallback(async (variantId, quantity) => {
// código custom que todos escribimos
}, []);
const updateLine = useCallback(async (variantId, quantity) => {
// código custom que todos escribimos
}, []);
const removeLine = useCallback(async (variantId, quantity) => {
// código custom que todos escribimos
}, []);
// applyDiscount, note, currency, error state, cross-tab sync, refetch on focus, etc.
return (
<CartContext.Provider value={{ cart, addLine, updateLine, removeLine }}>
{children}
</CartContext.Provider>
);
}
export const useCart = () => useContext(CartContext);
Código diferente cada vez, todos persiguiendo lo mismo. Con la nueva capa client de Hydrogen, esto se vuelve un solo import:
import { createCartComponents } from "@shopify/hydrogen/react";
const { useCartForm } = createCartComponents();
function AddToCartButton({ variantId }) {
const { formProps, register } = useCartForm();
return (
<form {...formProps}>
<input type="hidden" {...register("variantId", variantId)} />
<button type="submit">Agregar al carrito</button>
</form>
);
}
Centralizando esto obtienes las mejores prácticas gratis. Ya está disponible para React hoy en el branch de preview de Hydrogen, con más frameworks en camino.
Capa Server: full-stack sin lock-in
Los devs necesitan acceso full-stack para construir storefronts que escalen sin sacrificar performance. El contenido estático debe servirse al instante desde un CDN mientras los datos dinámicos (como inventario) llegan en streaming.
La comunidad open source resolvió esto con frameworks como Next.js, Nuxt y SvelteKit — capacidades full-stack sin lock-in a un runtime propietario. Hydrogen ahora se conecta a estos frameworks en lugar de reemplazarlos:
import { PRODUCT_QUERY } from "@/lib/gql";
import { storefrontConfig } from "@/lib/config";
import { cacheTag } from "next/cache";
import { createStorefrontClient } from "@shopify/hydrogen";
// Función cacheable para datos de producto con revalidación on-demand
export async function getProductData({ handle }) {
"use cache";
cacheTag(handle);
const client = createStorefrontClient({
type: "private_shared_rate_limit",
config: storefrontConfig,
});
const { data } = await client.graphql(PRODUCT_QUERY, {
variables: { handle },
});
return data;
}
Shopify ya soporta estos frameworks a través de su canal Headless, pero hasta ahora cada equipo escribía sus propios bindings al mismo contrato de API. En esta capa, la solución es guía, no más código. Tanto humanos como agentes de IA necesitan saber cómo usar lo que los frameworks ya hacen.
Esa guía viene como documentación, templates y skills — incluyendo skills estructuradas para agentes cubriendo i18n, markets y menus.

Comparación capa por capa
| Capa | Antes del rewrite de Hydrogen | Después del rewrite | Quién gana más |
|---|---|---|---|
| Core | Cada equipo hacía a mano MoneyV2, cart IDs, fragments GraphQL | Core compartido @shopify/hydrogen con helpers tipados | Equipos con múltiples storefronts |
| Client | CartContext custom por proyecto, drift entre apps | createCartComponents() en un solo import (React hoy) | Equipos React/Next.js que quieren velocidad |
| Server | Bindings de runtime propietario, lock-in de framework | Nativo de frameworks (Next.js, Nuxt, SvelteKit) + client tipado | Orgs multi-framework, agencias |
| Guía | Posts de blog dispersos y snippets copiados | Docs, templates y skills para agentes (i18n, markets) | Devs solo y asistidos por IA |
Limitaciones y puntos de atención
- Solo branch de preview (React). La capa client todavía no es estable en todos los frameworks. Soporte para Nuxt y Svelte está en el roadmap, no se ha lanzado.
- Convergencia con vercel.shop pendiente. El template
vercel.shopde Vercel se va a absorber en Hydrogen cuando estabilice — o sea, los patrones actuales devercel.shopson transitorios. - Interacciones con Cache Components. En Next.js 16 con
cacheComponents: true, cambiarnext/linkpor elLinkde next-intl rompe el prerender. La guía lo advierte explícitamente: cambias algunos redirects de middleware por un prerender limpio. - Las skills de agente son opinadas. La skill de i18n asume
localePrefix: "always"y sin integración con Shopify Markets. Si necesitas precios/inventario region-aware, tienes que usar otra skill. - No es bala de plata para migración. Apps Hydrogen existentes van a necesitar un plan de migración — la división en tres capas cambia imports y layout de archivos de forma significativa.
Qué estudiar después
- Fundamentos del Next.js App Router — root params,
cacheComponents, samples deinstant. La capa server de Hydrogen depende mucho de esto. - Patrones de routing de next-intl — URLs con prefijo de locale, catálogos de mensajes por locale, y cómo evitar forzar render dinámico en árboles cacheados.
- GraphQL con clients tipados — el patrón
createStorefrontClientde Hydrogen es un gran template para cualquier capa de API tipada. - Skills de agente como formato de entrega — el patrón de la skill
enable-i18n(frontmatter + paso a paso + verificación) es un modelo reutilizable para entregar guía interna a agentes de código.
Si te gusta entender cómo las grandes plataformas manejan datos a escala, checa este breakdown sobre cómo Netflix gestiona millones de activos de datos con data projects. Y si sigues el lado de tooling para agentes de IA de Vercel, mira Grok Build 0.1 en Vercel AI Gateway.

Resumiendo
Vercel y Shopify están apostando a que el e-commerce headless no debería requerir reescribir el mismo glue code en cada proyecto. La división en tres capas — core, client, server — es una respuesta arquitectónica limpia a una década de copy-paste.
La prueba real no es el anuncio; es si la promesa framework-agnostic se sostiene cuando salga el soporte para Nuxt y Svelte. Por ahora, los equipos React en el branch de preview de Hydrogen se llevan la mayor victoria inmediata: estado del carrito como un solo import, y un client de Shopify tipado que sobrevive a cambios de API.
Pruébalo, haz fork y ayuda a moldear lo que viene — el repo está abierto en GitHub.