Por qué Shopify está moviendo la estructura de temas de vuelta a código legible, y qué desbloquea eso para desarrolladores, comerciantes y agentes.
Hace exactamente 12 años, empecé a construir mi primera tienda en Shopify.
No era realmente un desarrollador. Era un diseñador con conocimientos técnicos que sabía HTML, CSS y lo suficiente de jQuery como para ser peligroso. Lo que sabía era que quería un escaparate que se sintiera completamente personalizado para la marca que estaba construyendo, pero no quería gestionar todo un stack de comercio solo para llegar hasta ahí.
Entonces descubrí Shopify.
Descargué Timber, abrí su plantilla de colección y todo encajó:
1{% for product in collection.products %}2 {% include 'product-grid-item' %}3{% endfor %}
Toda la plantilla eran 100 líneas de código. Podía entender cómo funcionaba simplemente leyendo el código. Apenas necesitaba la documentación más allá de la hoja de referencia de Mark Dunkley.
Para los desarrolladores de temas, esa fue una era dorada de legibilidad. Para los comerciantes, los ajustes globales del tema claramente no eran suficientes.
La compensación que hicimos
Los ajustes del tema solo nos llevaron hasta cierto punto. En 2016, Shopify introdujo las Secciones y tres cosas cambiaron a la vez.
- Los comerciantes se convirtieron en merchandisers. Personas que no sabían programar podían dar forma a las páginas y contar una historia de producto mucho más rica.
- Los desarrolladores se convirtieron en diseñadores de componentes. Las secciones tenían que ser modulares, flexibles y funcionar en cualquier orden.
- Y los temas se convirtieron en productos. Los desarrolladores tenían que pensar en la interfaz que estaban creando y tomar decisiones deliberadas entre facilidad de uso y flexibilidad.
Esas fuerzas se aceleraron con Dawn en 2016, y luego de nuevo con Horizon el año pasado, y la introducción de los "bloques" como la unidad componible central en los temas.
Para representar secciones y bloques en cada plantilla, Shopify necesitaba un formato de serialización. Las plantillas pasaron a JSON.
Esa compensación les dio a los comerciantes mucho más control, pero tuvo un costo en la experiencia del desarrollador: ya no podías entender una página leyendo un solo archivo. Tenías que cruzar referencias de JSON, Liquid, esquemas, ajustes, secciones y bloques para reconstruir cómo funcionaba la página.
En el momento en que las plantillas se convirtieron en JSON, dejaron de ser una buena superficie para desarrolladores. Se convirtieron en una salida guardada automáticamente, algo que literalmente advertíamos a los desarrolladores que no editaran a mano.
Esa fue una compensación racional para la era del "software imperativo", donde los comerciantes daban forma a una tienda a través de botones, perillas y ajustes para especificar exactamente qué debía cambiar.
La IA cambia la ecuación.
Una gran experiencia de desarrollador es una gran experiencia de agente
Cuando le dimos a Sidekick la capacidad de editar temas, el Editor de Tienda Online entró en su era de "software declarativo". Ejemplo simple: en lugar de abrir un selector de color y elegir \[#0000FF](https://x.com/search?q=%230000FF&src=hashtag_click)\, un comerciante podía simplemente decir: "Haz esto azul".
Los comerciantes ya han realizado 25 millones de ediciones de temas con Sidekick este año, y 1 de cada 5 comerciantes está usando IA para editar su tema.
Al mismo tiempo, los desarrolladores están usando cada vez más agentes para escribir código. Eso significa que Shopify ahora tiene dos tareas conectadas:
- Dar mejor orientación a los agentes.
- Darles mejores comentarios (feedback).
Para la orientación, estamos lanzando habilidades mejoradas de Liquid. Los temas también pueden llevar instrucciones para agentes a través de un directorio \.agents\, e incluir archivos como \AGENTS.md\ y \DESIGN.md\, para ayudar a los agentes de código a entender cómo quieres que se escriba el código y cómo mantener tus diseños alineados con la marca.
Para los comentarios, hemos expandido la etiqueta \{% doc %}\ a contratos tipados para snippets y bloques. Los parámetros pueden ser documentados, tipados, validados por Theme Check, y acompañados de ejemplos de uso.
1{% doc %}2 @param {string} [variant]3 @param {string} [tag]45 @example6 {% block 'text', tag: 'h1' %}7 Featured Collection8 {% endblock %}9{% enddoc %}
Cuando escribes código a mano, esto te da comentarios en tiempo real, intellisense y errores; y también les da a los agentes una forma de descubrir parámetros válidos, aprender cómo se ve un buen resultado y recibir comentarios útiles cuando alucinan una API que no existe.
También hemos añadido 20 nuevas reglas de Theme Check que cubren contratos, estructura, validación, complejidad, anidamiento y límites de tamaño de archivo.
Lo increíble para desarrolladores como yo, en la era de los agentes, es que recompensa lo mismo que siempre hemos querido: código legible, contratos explícitos y retroalimentación rápida.
Así que nos hicimos una pregunta más grande: ¿cómo sería la arquitectura de temas ideal si tratara esas cualidades como principios fundamentales?
Hemos estado construyendo un nuevo tema base de Shopify, que reúne todas nuestras ideas.
(Debería mencionar… esta es una nueva arquitectura optimizada para agentes de código, pero no es una reescritura forzada. Los temas existentes seguirán funcionando para siempre; Liquid ha sido y siempre será una API para siempre).
La estructura de la página vuelve a ser código legible
Lo primero que notarás del nuevo tema es cuando abras su directorio \templates\; las plantillas vuelven a ser archivos Liquid.
Su plantilla de colección tiene aproximadamente la misma longitud que la de Timber, y el tema en general tiene un 93% menos de líneas de código que Horizon. No pretende ser un tema con todo incluido como Horizon, sino que está ahí para facilitar mucho la construcción con todos los primitivos de comercio en Shopify y sentar una base para obtener el mejor rendimiento posible, pero te deja construir todas las cosas que hacen única a cada tienda de cada comerciante.
¿Por qué mover la estructura de la página de vuelta a Liquid?
El problema más profundo con la configuración serializada no es que JSON sea inherentemente malo. Es que la configuración tiene un vocabulario limitado. Un desarrollador de temas tiene que anticipar las composiciones que un comerciante podría querer.
Imagina una sección que contiene un botón. Un comerciante le pide a un agente que añada un segundo botón junto a él.
En una arquitectura basada en ajustes, el tema ya debe exponer un bloque de grupo capaz de contener ambos botones, o el desarrollador debe haber anticipado un ajuste para un segundo botón.
En HTML, añades otro botón y envuelves el par en un \div\.
Todos los modelos principales ya entienden HTML. Es expresivo, local y eficiente en tokens. Y Shopify ha tenido el lenguaje necesario para combinar esa expresividad con el comercio durante más de 20 años: Liquid.
Bloques y HTML, juntos
La nueva arquitectura introduce una etiqueta \{% block %}\ componible que se puede usar directamente dentro de plantillas Liquid.
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>
Los bloques aceptan parámetros con nombre. Pueden contener contenido anidado. Sus parámetros se pueden tipar mediante \{% doc %}\. Definen los límites con los que los comerciantes pueden interactuar, mientras que el HTML ordinario se encarga de todo lo demás.
Si has usado un sistema de componentes como React, el modelo te resultará familiar: los parámetros se comportan como props, y el contenido anidado se comporta como children. Pero sigue siendo Liquid, lo suficientemente simple como para leerlo de arriba abajo en un solo archivo.
Esto hace que la composición sea explícita sin requerir que cada fragmento de marcado se convierta en otra sección, bloque o ajuste.
Reactividad de grano fino con partials
Los desarrolladores de temas han llevado la API de Renderizado de Secciones mucho más allá de lo que fue diseñada originalmente, porque era la mejor herramienta disponible para la reactividad del lado del servidor.
Queríamos algo más preciso.
Inspirados en el trabajo emergente sobre actualizaciones parciales declarativas, estamos trayendo un primitivo simple llamado partials a Liquid.
Envuelve una región que se puede volver a renderizar:
1{% partial 'cart-count' %}2 <span>3 {{ 'cart.count' | t: count: cart.item_count }}4 </span>5{% endpartial %}
Luego obtén el HTML actualizado y aplícalo donde sea necesario:
1const html = await partials.fetch('cart-items', 'cart-count');2partials.apply(html);
Eso es todo. Actualizaciones renderizadas del lado del servidor de grano fino sin renderizar una sección completa ni introducir un DOM virtual.
Añadir al carrito puede actualizar las regiones relevantes del carrito en pocas líneas. Este único primitivo nos permitirá eliminar miles de líneas de código de reactividad de Horizon.
Eventos y Acciones Estándar
También estamos haciendo que las interacciones comunes de la tienda sean más simples e interoperables.
Las Acciones Estándar proporcionan un contrato compartido para operaciones como actualizar un carrito. Los Eventos Estándar permiten que los temas y las aplicaciones reaccionen a través del mismo vocabulario estable.
1const { cart } = await Shopify.actions.updateCart({2 lines: [{3 merchandiseId: variant.id,4 quantity: 1,5 }],6});
Esto es más fácil de escribir para los desarrolladores, más fácil de integrar para las aplicaciones y más fácil de entender para los agentes. Las Acciones Estándar funcionan en todas las tiendas Shopify hoy, y el soporte de WebMCP les da a los agentes de navegador una ruta semántica para navegar y añadir productos mientras el escaparate responde a esas interacciones.
El objetivo no es añadir un "modo IA" al escaparate. Es hacer que las capacidades del escaparate sean claras y componibles para cada participante: temas, aplicaciones, desarrolladores y agentes.
Haciendo que Liquid sea más seguro de evolucionar
También había algunas capacidades obvias del lenguaje que queríamos añadir a Liquid: expresiones booleanas, operadores infijos con precedencia, y arrays y objetos literales.
El bloqueo no era la falta de deseo. El analizador histórico de Liquid aceptaba sintaxis ambigua que no era formalmente válida. Introducir nueva sintaxis podría, por lo tanto, cambiar el comportamiento de los temas existentes.
El equipo emprendió una migración importante para mover los temas de manera segura a un analizador estricto. Ese trabajo nos da margen para evolucionar Liquid sin romper los escaparates que ya dependen de él.
Desbloquea expresiones más simples y familiares:
1{{ 1 + 1 }}2{{ false && false || true }}3{% assign products = ["shirt", "hat", "shoes"] %}
También hace que los errores sean más predecibles, tanto para desarrolladores como para agentes.
Una cosa más: Tailwind
Próximamente, traeremos soporte de Tailwind a los temas Liquid.
Los agentes son excelentes con él. Los desarrolladores ya lo entienden. Y nos da un lenguaje de estilo compartido construido en torno a tokens de diseño, sin obligar a los comerciantes a heredar un sistema de compilación complicado.
Ese vocabulario compartido importa. Cuanto mejor entiendan los agentes la estructura, los contratos y la intención de estilo, más podrán los desarrolladores centrarse en las partes de un escaparate que realmente diferencian una marca.
De vuelta al futuro
Hace doce años, Shopify tuvo sentido para mí porque podía abrir un tema, leer el código y entender la tienda.
Con el tiempo, hicimos los temas mucho más flexibles para los comerciantes, pero el código se volvió más difícil de ver.
Los agentes nos dan la oportunidad de reunir esas dos cosas: la flexibilidad que los comerciantes necesitan y la legibilidad que los desarrolladores merecen.
Esa es la dirección detrás de esta nueva arquitectura:
- Plantillas Liquid como estructura de página legible.
- Bloques componibles y tipados junto con HTML ordinario.
- Habilidades de agente y guía a nivel de repositorio.
- Retroalimentación más rica mediante \
{% doc %}\y Theme Check. - Reactividad de grano fino mediante partials.
- Contratos de escaparate compartidos a través de Eventos y Acciones Estándar.
- Un analizador estricto que permite que Liquid evolucione de forma segura.
- Tailwind como lenguaje de estilo común.
La vista previa para desarrolladores y la documentación ya están disponibles:
https://shopify.dev/docs/storefronts/themes/getting-started/developer-preview
Pruébalo y envíame tus comentarios. ¡Estoy deseando ver lo que construyes!
