XSLT: un sistema de build nativo y de cero configuración para la web

• XSLT es una herramienta de build integrada para la web que puede usarse de inmediato, sin necesidad de un sistema de build complejo
• La mayoría de los sistemas de build para sitios estáticos tienen problemas de complejidad, dificultad para entenderlos y dependencia de frameworks
• Aprovechando XML y XSLT, es posible generar HTML directamente en el navegador, lo que facilita el procesamiento de datos dinámicos y la generación de marcado
• Todos los navegadores principales admiten transformaciones basadas en XSLT, por lo que puede usarse sin JavaScript adicional ni herramientas aparte
• No es una solución perfecta, pero tiene gran valor como una alternativa simple y flexible basada en estándares web

---

Introducción y planteamiento del problema

• La mayoría de los procesos de desarrollo de sitios web estáticos se componen de archivos para datos (.json, .md, .txt), un sistema de build independiente (Hugo, Next.js, Astro, etc.) y una estructura de salida en HTML
• Los sistemas de build aumentan la complejidad, y cada vez resulta más difícil entender y operar incluso un blog pequeño
• Si se intenta excluir frameworks y trabajar solo con HTML, CSS y especificaciones estándar (HTTP, URI, HTML), aparecen límites de mantenimiento, como la repetición de encabezados o pies de página
• También se probaron opciones como HTML import y web component, pero la primera no tiene soporte y la segunda no logró ser una alternativa por su dependencia del motor de JavaScript

El navegador web como sistema de build

• La idea parte de que el propio navegador web admite varias transformaciones de datos (text/html, text/markdown, application/xml, etc.)
• Al revisar a fondo las especificaciones web, se buscó una forma de resolver el problema sin herramientas externas ni frameworks innecesarios

Uso de XSLT

• Al querer mostrar un feed RSS de forma más atractiva, se descubrió la especificación de XSLT
• XSLT es una tecnología estándar oficial que expresa tanto datos XML como la estructura de salida en HTML
• Su uso es sencillo
  • Por ejemplo, organizar los datos en blog.xml
  • Luego conectar la hoja de estilos XSLT así
    • <?xml-stylesheet type="text/xsl" href="blog.xsl"?>
  • En blog.xsl se escriben la plantilla HTML y las reglas de mapeo de datos
• Se admiten plantillas, repeticiones, variables, importación de archivos externos y la mayoría de las funciones de un sistema de build

Forma de ejecución y ventajas

• Sin herramientas adicionales, basta con abrir el archivo XML en un navegador web para que el resultado de la transformación se renderice de inmediato
• El formato XML es similar a HTML, por lo que es amigable para las personas y fácil de mantener, y usarlo en lugar de JSON no resulta particularmente incómodo
• Todos los navegadores web principales admiten de forma nativa las transformaciones basadas en XSLT, de modo que el cliente puede ver directamente el resultado
• No necesitar JavaScript, herramientas de build separadas ni bundlers es una ventaja enorme
• XSLT no es la solución universal definitiva, pero sí una alternativa de build web simple y con posibilidades de expansión

Conclusión

• Redescubrir el valor de una tecnología del pasado (XSLT) y de los estándares claros
• Usar el navegador web como sistema de build es una opción útil que vale la pena agregar a la caja de herramientas del desarrollo web

[GN⁺]

Comentarios de Hacker News

• La empresa en la que trabajé usaba muchísimo XSLT en plantillas XML, y probablemente todavía lo siga haciendo. Sinceramente, no era una buena elección, y si hubieran podido seguramente habrían querido migrar a otra cosa

  1. XSLT tiene estándares modernos, pero sigue predominando la versión 1.0, que es limitada y bastante rara en comparación con los estándares nuevos
  2. Los problemas de rendimiento en plantillas XSLT son extremadamente difíciles de resolver. Como XSLT es un lenguaje funcional Turing completo, el rendimiento no se ve fácilmente. En la mayoría de los documentos va bien, pero cuando entran 100 filas de repente explota. El código que procesa tablas puede tener rendimiento O(N^2), y optimizarlo es casi imposible. Por ejemplo, cada fila podría incluir un XPath de O(N). Si mal no recuerdo, esa plantilla tardaba más de 7 minutos en procesar un documento.
     JS también tiene problemas, pero al menos no estás forzado a dejar sin corregir ese tipo de complejidad algorítmica

  • XSLT/XPath ha evolucionado bastante desde 1.0. Salieron varias funciones como key(index), entre otras, y eso aceleró mucho el procesamiento. Si usas una implementación de calidad como Saxon, los problemas de rendimiento también son mucho menores. Cuando conviertes XML a otra cosa, creo que hay pocas herramientas tan convenientes como XSLT para estructurar la lógica

  • XSLT es bastante difícil de aprender. Se siente como una especie de Prolog onírico, y cuando de verdad lo dominas da esa misma satisfacción que resolver un sudoku. Pero en la mayoría de los casos no se necesitan plantillas tan complejas, así que cuesta que sea una opción estándar. Y además XML tampoco es un formato que le guste a todo el mundo

  • No termino de entender esa parte de que XSLT 1.0 siga usándose tanto. Ya en 2013 la 1.0 casi se veía como algo obsoleto, y Saxon, que permitía usar XSLT 2, era gratis y tenía un rendimiento excelente. Nunca tuve problemas de rendimiento al transformar documentos, ni grandes ni pequeños

  • La época en que apareció XSLT era una en la que se daba por hecho procesar XML con cuerpos larguísimos. Pero con bucles anidados así, era obvio que tarde o temprano iba a reventar

  • Me da curiosidad si usan la versión comercial de Saxon. No es cara, y por soporte de estándares nuevos, rendimiento y varias funciones, IMHO realmente vale la pena. Recuerdo que cuando la usé tenía optimizaciones bastante inteligentes

• En los navegadores de los 90 y 2000 todo funcionaba distinto, así que se empezó a introducir JS para unificar el comportamiento
  En realidad lo que queríamos eran estilos CSS atractivos, pero en ese entonces no se podían usar bien
  Con el tiempo un navegador pasó a dominar y los demás se fueron pareciendo bastante más (la ley del Highlander, aunque Firefox también ha dado buena pelea)
  Los frameworks ya se volvieron algo normal, así que se asentaron como la manera de igualar la UI en todos los navegadores. Y el paradigma mismo se movió hacia renderizar datos JSON
  Ahora vivimos en una época donde incluso generar páginas web tradicionales desde el servidor es rápido y usa poca memoria
  Pienso esto porque hace poco, durante una migración desde un sistema legacy, volví a experimentar un sitio que funcionaba con el modelo de peticiones HTTP por página completa, el estándar de los 2000. Cada acción requería recargar, pero aun así era muchísimo más rápido que un sistema hecho con React
  La razón es

  1. Internet se volvió muchísimo más rápido
  2. Los teléfonos tienen bastante memoria, pero los frameworks JS la desperdician
  3. El backend, antes y ahora, sigue siendo CRUD, CRUD, CRUD (+ paginación, + transacciones)

  • AJAX y la actualización del DOM no aparecieron simplemente para ir más rápido. Surgieron para salir del paradigma de la web como "sitio web/documento web". La recarga completa de página sí tiene sentido dentro de un paradigma centrado en documentos. En ejemplos simples como HN, esa estructura encaja perfectamente. Muchos sitios funcionan de sobra así, sin frameworks JS.
    Pero decir que "todos podrían volver a recargar la página completa" está lejos de la realidad. En aplicaciones web con interacciones complejas, recargar toda la página da una UX muy mala.
    En resumen,
    para 'sitios web', 'documentos web' y 'formularios simples', muchas veces basta con recargar la página completa, pero
    para 'aplicaciones web' que requieren pantallas de datos complejas y manipulación intensa, no es así

  • La línea de tiempo que recuerdo es un poco distinta. JS no se usó tanto para unificar el comportamiento del navegador, sino desde el principio para elementos interactivos (DHTML, AJAX, etc.). El layout de verdad se resolvía casi siempre con hacks y detección de agente según el navegador. Incluso cuando CSS se volvió más potente, la consistencia no se arregló tan fácilmente. CSS garden, marcado semántico y el abuso de tablas eran muy propios de esa época, y tomó muchísimo tiempo llegar siquiera al primer ACID test superado. Soy escéptico sobre cuánto influyeron los frameworks en la consistencia de UI: desde jQuery en adelante, CSS mismo fue más bien el principal factor de consistencia visual.
    Aunque claro, puede ser solo mi recuerdo personal

  • Coincido en que, con el stack moderno, las páginas web tradicionales renderizadas en servidor son rápidas y livianas
    En mi stack .NET/Kestrel/SQLite, una respuesta SSR difícilmente pasa de 4 ms. La mayoría anda en el rango de los 100 microsegundos. Mi enfoque es usar varias consultas y joins complejos por página para dar forma a los datos según la vista
    Incluso en un caso extremo como generar una tabla de 100,000 filas, si haces bien el procesamiento de datos antes de armar el string HTML, el rendimiento mejora muchísimo. LINQ también rinde excelente, pero si creas colecciones por fila, con muchos datos termina siendo muy ineficiente
    En mi experiencia, para optimizar rendimiento lo mejor era mantener el motor de plantillas HTML lo más cerca posible de la base de datos. Al final el DOM es solo un flujo de bytes. No hace falta montar un AST/parser complejo; con StringBuilder y consultas SQL bien armadas alcanza de sobra.
    La objeción a este enfoque simple siempre terminaba siendo la típica discusión de seguridad de "no confío en que los desarrolladores escapen HTML correctamente"

  • Esa idea de que "con tecnología moderna se puede volver sin problema a páginas clásicas generadas en el servidor" cambia por completo si la latencia de red es alta
    Enlace de referencia

• A inicios de los 2000, XML empresarial se infló tanto que la tecnología terminó pareciendo anticuada, y al final todos cayeron enamorados de la "limpieza" de JSON. En realidad, tecnologías como XSLT y XPath ya eran bastante maduras y resolvían muchos problemas que todavía hoy seguimos discutiendo
  Yo mismo abusé muchísimo de include en XSLT, usando cosas como <xsl:include href="mycorp://invoice/1234"> mediante wrappers de streams en PHP
  Sinceramente, hoy eso puede sentirse algo anticuado, pero sigo desconfiando de dejar que el navegador procese XSLT localmente. Antes era un verdadero campo minado de compatibilidad

  • Todavía extraño varios elementos "básicos" de XML que siguen faltando en JSON. Por ejemplo, tener una especificación realmente estandarizada o definición de esquemas: ahí XML estaba mucho más adelantado, y a JSON le tomó casi 10 años alcanzarlo
    La última vez que trabajé XML en serio fue con una tecnología de transporte llamada EXI. Convertía documentos XML en flujos binarios comprimidos; claro, eso de estructura ↔ ASCII ↔ compresión/transmisión ↔ reconversión era bastante engorroso. Hoy protobuf y gRPC son lo dominante, pero a veces imagino que, si XML hubiera seguido reinando, tal vez viviríamos en un mundo donde todo sería interoperable sobre estándares. Aunque siendo realistas, la enorme barrera que se creó entre protobuf/gRPC y las APIs JSON quizá terminó siendo algo bueno

  • Me parece que XML es un formato decente. Sí, es voluminoso y verboso, pero comparado con YAML es mucho mejor en precisión y expresividad
    Cuesta agarrarle la mano a XPath, pero si experimentas lo suficiente, al final puedes hacer lo que quieres
    XSLT me parece una idea completamente demente. Debería desaparecer

  • El juego Rimworld guarda toda su configuración en XML y permite modding con XPath. Esa combinación es realmente potente. Para personalización de datos local es difícil encontrar algo mejor. Pero parece que la mayoría de los juegos evita algo así porque XML quedó marcado como "anticuado"
    Documentación oficial del modding con XPath en Rimworld

  • Eso de que el XML empresarial de principios de los 2000 se volvió gigantesco es totalmente cierto. XML originalmente era una versión simplificada de SGML para poder usarse en la web, pensada para transportar marcado y extender vocabularios. Al final solo sobrevivieron SVG y MathML. Arrastrados por el boom web, W3C y Microsoft sacaron a raudales SOAP, WS-* y demás especificaciones. Fue una época bastante delirante, en la que incluso lenguajes como XSLT, con huesos de Scheme, se forzaron a encajar dentro de XML. Hasta JavaScript pertenece un poco a esa era, empezando por el nombre comparado con Java

  • Es una pena que XPath obligue a escribir consultas insoportablemente verbosas por culpa de los namespaces

• Todavía hoy estilizo mi feed con XSLT.
  Ejemplo de feed RSS
  Ejemplo de XSLT

  • Ver cosas así me hace pensar que quizá los blogs debieron haber sido simplemente feeds RSS

  • Siempre se me olvida que XML originalmente podía hacer este tipo de cosas. De algún modo se siente poco intuitivo

  • Está realmente muy bien hecho. Ojalá más gente adoptara ejemplos así de creativos

• En mi primer trabajo (a los 19) me tocó personalizar Google Search Appliance. Eran esos servidores Dell amarillos carísimos, con CentOS, para montar búsqueda de texto completo al estilo Google sobre documentos CIFS usando ese Python tan de Google.
  Por allá de 2011 XHTML todavía estaba bastante vigente, y en Google Search Appliance los datos XML del backend se transformaban a XHTML con XSLT. Reventando las plantillas de ejemplo armé una UI monstruosa adaptada a la intranet de la empresa, remendando y pegando recursos de Coldfusion, StackOverflow, W3Schools y lo que hubiera a mano
  Esa experiencia la borré rápido del currículum. Después varios subcontratistas del DoD seguían llamándome para proyectos de modernización de sistemas documentales como supuesto "experto en XML", y ya me tenía harto
  La próxima vez que suspiren mientras recorren arrays desde JSON hacia interfaces TypeScript usando JSX, acuérdense de mí. Al menos eso sigue siendo mejor que hacer lo mismo con XSLT

• Yo sí soy alguien que busca la simplicidad. Me gustan los documentos fáciles, como un readme de cavernícola. A veces hasta siento que aporreo el teclado como cavernícola. No hago sitios web y no sé mucho de XSLT. A veces hackeo con XML y me dan ganas de mostrarle algo a los usuarios. Hay demasiados formatos de archivo y me explota la cabeza. Aun así me gusta que las cosas se vean bien. Puede que yo también termine usando esto
  Gracias por leer la especificación y por crear la herramienta

• Mucha gente dice que XML es verboso y complicado, pero cuando realmente trabajas con él, es un formato excelente
  Puedes validar con DTD y generar salidas legibles para humanos con XSLT
  Para mí, XML es como el C++ de los formatos de texto: maduro, con "baterías incluidas", poderoso y conectable con cualquier lenguaje
  Como pasa con los lenguajes maduros y antiguos, me da pena que se haya vuelto moda tratar XML como si fuera solo material para raritos. Si no encaja para un uso, no lo usas, pero tampoco hay razón para odiarlo tanto

  • Me pregunto por qué usas DTD y no XSD

• Me sorprende eso de que "XSLT funciona directamente en el navegador". La última vez que usé XSLT fue hace 20 años, y en ese momento estaba tan enterrado bajo Java empresarial monstruoso que toda su estética propia quedaba tapada.
  Pero si XSLT realmente funciona por defecto en el navegador, ¿significa que la gran promesa de las plantillas estáticas reales, sin framework host, estuvo siempre a la vuelta de la esquina?

  • Los navegadores solo soportan XSLT 1.0. Y hasta se habla de que eso podría desaparecer en el futuro. Si al menos los navegadores soportaran hasta 3.0, sería increíblemente útil para generar páginas web estáticas

  • También hubo experiencias donde no era obligatorio levantar esa torre de "gran Java empresarial". Nosotros lo usamos solo con tomcat y algunas librerías de apache, y funcionaba bastante bien. En el CMS el HTML se generaba desde XML, la personalización venía en forma de etiquetas XML, y gracias a un proxy de caché del lado del servidor la transformación era rápida y soportaba mucho tráfico. La clave era enviar el stream de salida de XSLT directamente al cliente en cuanto se generaba, sin bufferizar todo en memoria.
    Hoy con wasm puedes correr casi cualquier cosa en el navegador, pero el JS de los primeros años era terrible, y bastante era si los diseñadores te entregaban un PSD de Photoshop usable. En la época de Google Maps y Gmail se peleaba durísimo para construir UIs cargadas de JavaScript y encima había que soportar tanto Netscape como Internet Explorer: un verdadero infierno

  • El boom de XHTML en realidad también empezó por esa misma "gran promesa de las plantillas estáticas". Pero curiosamente, quienes de verdad sabían del tema hablaban casi en clave y nadie lo decía tan abiertamente

  • Trabajé en un sitio con XSLT en el navegador en 2008, y el soporte ya existía incluso en los primeros 2000

  • Chrome viene con libxslt y Firefox con un motor 1.0 llamado Transformiix. Chrome solo soporta exsl:node-set, mientras que Firefox soporta varias extensiones EXSLT, aunque no todas
    También publiqué una pequeña herramienta que muestra información simple del procesador XSLT y la lista de extensiones disponibles.
    GitHub - xslt-detect-ext
    Puedes arrastrar el archivo out/detect.xslt al navegador para revisar la información (Chrome, Firefox). Safari no funcionaba en la antigua versión para Windows

• Cuando estaba en la secundaria en los 90 y me llamaban "web designer", usaba un pipeline con dialectos DSSSL para generar sitios automáticamente desde feeds de noticias. A día de hoy sigo disfrutando las transformaciones XSLT. Incluso hago conversiones de texto reales y trabajo de plantillas con herramientas como bananas XI reader
  Pero a muy poca gente le gustaba de verdad este tipo de tooling, y cuando alguien más tomaba mi puesto, las tecnologías que había introducido tendían a desaparecer rápido
  bananas XI reader

• Para mostrar qué tan fuerte fue la fiebre por XML y XSLT a principios de los 2000, en la empresa donde trabajé llegaron a fabricar un ASIC capaz de parsear XML y procesar XSLT directamente en el chip a velocidad de tiempo real. En ese momento de verdad creían que el internet del futuro funcionaría enteramente sobre XML/XSLT.
  De hecho, Intel terminó comprando la empresa y esa tecnología acabó incorporándose en aceleradores SSE

  • A veces imagino lo absurdamente rápidos que serían los sitios web hoy si se hubiera vuelto estándar algo como interpretar XML y ejecutar XSLT directamente en ASIC

  • IBM todavía vende hardware con funciones parecidas integradas (DataPower Gateway)