¿Por qué XSLT rara vez se usa en la web? [cerrado]

XSLT es un estándar maduro y ampliamente aceptado.

Se puede usar en navegadores (incluso en IE antiguo) y en el lado del servidor (nginx tiene un módulo XSLT, que se puede usar desde lenguajes de programación, por supuesto). Sus implementaciones están compiladas y, por lo tanto, deberían ser mucho más rápidas que Python o JS. La implementación de JS Saxon JS se puede utilizar, al menos, como alternativa. Las plantillas Jinja, Angular, Ruby's Slim, ASP y PHP ni siquiera están cerca.

Una plantilla XSL se puede validar fácilmente en un IDE. ¿Cuántos IDEs pueden ayudar con Jinja o Angular?

Parece que es una idea perfecta descomponer la interfaz de usuario y los datos con XSLT.

Es cierto que las implementaciones pueden dar resultados diferentes en algunos casos de esquina, pero es un problema solo con la plantilla del lado del cliente. Y es lo mismo con HTML, CSS y todo lo demás que se hace en el lado del cliente.

Entonces, ¿por qué no XSLT?

XSLT realmente no tiene un papel útil en la web interactiva moderna. El propósito de XSLT es transformarse de un lenguaje XML a otro, pero en realidad nunca es necesario hacerlo en primer lugar. Qué tan poderosa, rápida y bien soportada es una tecnología es irrelevante si no tiene el problema que la tecnología está diseñada para resolver.

Hay varias razones por las cuales el caso de uso de XSLT ha desaparecido:

• HTML ha ganado. Se suponía que XSLT era útil para transformar contenido de "texto enriquecido" en algún formato de marcado semántico en HTML. Pero HTML es en sí mismo un formato perfectamente fino, entonces, ¿por qué no usarlo para el contenido en primer lugar y omitir la transformación?
• CSS se ha vuelto mucho más poderoso. Una de las promesas de XSLT era que podía mantener el marcado de origen limpio y semántico y luego transformarlo en "HTML presentacional" que funcionaba en el navegador cruzado y donde podía reorganizar elementos, etc. Pero en realidad no necesita HTML de presentación en estos días, puede usar HTML semántico y CSS puede realizar el estilo y el diseño necesarios.
• XML no se ha convertido en el formato ubicuo para los datos. Al recuperar datos SQL de una base de datos, es mucho más simple fusionarlos directamente en una plantilla, en lugar de transformarlos primero en XML y luego transformarlos a través de XSLT. Y JSON ha reemplazado a XML para los datos estructurados en el lado del cliente.
• XSLT está diseñado para transformar un documento completo a la vez. Pero en las páginas web interactivas modernas, pequeños fragmentos de datos se descargan poco a poco todo el tiempo y se fusionan en la página.
• Los datos simplemente no son tan complejos. Para la mayoría de los casos de uso, los formatos de plantilla más simples con marcadores de posición y repetidores resuelven bien la tarea. XSLT es mucho más poderoso, pero rara vez necesitas esa potencia extra, y tiene un alto costo en complejidad y fealdad.

XSLT surgió de la publicación en la que se podía tener un proceso unidireccional desde un formato fuente estructurado a múltiples formatos de publicación como impresión, PDF y páginas web estáticas. La mayoría de los sitios web no se ajustan a este caso de uso.

Depende de lo que quieras decir con "en la Web".

XSLT es muy utilizado. Por lo que podemos juzgar a partir de métricas como el número de preguntas de StackOverflow, está en los 30 lenguajes de programación principales, lo que probablemente lo convierte en el lenguaje de programación específico de modelo de datos después de SQL.

Pero XSLT no se usa ampliamente en el lado del cliente, es decir, en el navegador. Por lo general, se usa en el lado del servidor para entregar contenido a pedido en respuesta a solicitudes HTTP, o se usa en modo por lotes como parte de un flujo de trabajo de publicación. También se usa, por supuesto, en muchas aplicaciones que tienen muy poco que ver con la web, por ejemplo, en publicaciones impresas.

Hay varias razones por las que XSLT no se usa ampliamente en el navegador. La razón principal es que el buen soporte XSLT conforme fue muy lento por parte de los vendedores del navegador; nadie quería usarlo hasta que estuviera disponible en todos los navegadores, y para cuando estuvo disponible en todos los navegadores, las cosas que la gente quería hacer en el navegador habían avanzado (¿recuerda "Web 2.0"?) y las implementaciones de XSLT en el navegador no te ayudó a crear aplicaciones interactivas o buscar datos usando AJAX.

Saxonica (descargo de responsabilidad, este es mi producto) ha intentado cerrar estas brechas con Saxon-JS, pero el producto llega tarde a la fiesta, y el desarrollo web del lado del cliente está muy impulsado por la moda, por lo que no es suficiente solo tener un Producto que cumple todos los requisitos técnicos. Parte de la moda es que la mayoría de los sitios orientados a datos (a diferencia de los orientados a documentos) se han movido hacia JSON en lugar de XML, en gran parte porque JSON es mucho más fácil de manipular desde Javascript.

El otro problema es que XSLT es un lenguaje de amor u odio. Su paradigma declarativo, basado en reglas y orientado funcionalmente atrae a muchos debido a su naturaleza de alto nivel, pero puede ser desagradable para aquellos cuya única experiencia en programación es escribir código imperativo que le dice a la computadora exactamente qué hacer y en qué orden.

Me muevo de un lado a otro entre responder esta pregunta y cerrarla como principalmente basada en la opinión. Entonces, aquí está mi cambio:

En resumen, porque XML hace un lenguaje de programación horrible. Creo que algo con la semántica de XSLT pero una sintaxis mucho mejor sería algo completamente diferente. Hay algunos lenguajes de transformación XML basados ​​en Lisp realmente geniales, por ejemplo.

XSLT no puede decidir si quiere ser un lenguaje de reescritura de árboles, un lenguaje funcional o un lenguaje de procedimiento. Tiene características de todos ellos, pero no es realmente bueno en ninguno de ellos. Para cualquiera de los tres aspectos, existen mejores idiomas.

Porque XML en sí mismo parece basura obsoleta de compatibilidad con versiones anteriores para el 99.9% de los casos.

El único caso de uso para el que XML no tiene reemplazos inmediatamente superiores es cosas como docx u odf, y es posible que SGML hubiera sido mejor *. Es decir, tenemos una estructura de documentos increíblemente rica con todo tipo de cosas anidadas una dentro de la otra con grandes transformaciones aplicadas para que pueda parecer correcta en la pantalla y la impresora.

Casi todo el tiempo, XML se usa para pasar datos estructurados, y parece que XSLT está diseñado para transformar datos de documentos estructurados en datos de documentos. Ese caso de uso está desapareciendo. JSON es directamente superior a XML para datos estructurados. ** Tanto Markdown como YAML son superiores en datos ligeramente formateados. La introducción inicial de XML fue el analizador incorporado en Java y Javacript. JSON rompió esa barrera al aprovechar un analizador incorporado para los casos en los que se confía en la fuente JSON (que era la mayoría de ellos cuando era joven).

Y el mundo ha cambiado. La ventaja de la biblioteca incorporada es una ventaja trivial ahora. XHTML fue rechazado por completo y su reemplazo no fue heredado de él sino de su predecesor.

XML ahora se usa para hablar directamente con el tipo que quiere recibirlo, y se genera en una tela completa en el formato deseado, o por el contrario, se lee y analiza el modelo de objeto directamente desde el formulario enviado. Ya no es más un formato de almacenamiento o un formato de intercambio universal, ya no es necesario transformarlo de esquema a esquema.

* Enseñaron en la universidad que SGML nunca se implementó. Ellos mintieron.

** He escuchado las quejas sobre formatos de números incorrectos en JSON. Por otro lado, XML no tiene formato de número, por lo que simplemente rellenar todos los tipos de datos en cadena aún gana contra XML.