Muerte de XSLT — Google dejará de dar soporte a XSLT

 (xslt.rip)
1 puntos por GN⁺ 2025-11-11 | 2 comentarios | Compartir por WhatsApp
  • Google anunció oficialmente su plan de eliminar por completo el soporte de XSLT para 2027
  • XSLT es un lenguaje para transformar documentos XML a otras formas de XML, y todavía se usa en varios sitios web gubernamentales
  • Google ya había intentado retirar el soporte de XSLT en 2013, y este es su segundo intento
  • Mozilla y Apple también expresaron su intención de sumarse a la eliminación de XSLT, y se menciona su relación financiera con Google
  • Se considera un cambio técnico importante que podría afectar los estándares web y la accesibilidad del contenido

Anuncio de Google sobre el fin del soporte para XSLT

  • El 24 de octubre de 2025, Google publicó en el foro de desarrolladores de Chromium el documento “Intent to Deprecate and Remove: Deprecate and remove XSLT”
    • En consecuencia, se prevé que la funcionalidad de XSLT será eliminada por completo para 2027
  • Google ya había intentado eliminar XSLT en julio de 2013
    • Ese intento fue suspendido, pero con este anuncio se retoma 12 años después

Historial de descontinuación de tecnologías por parte de Google

  • Hasta ahora, se sabe que Google ha cerrado alrededor de 300 tecnologías
    • Un caso representativo es Google Reader, cuyo cierre fue anunciado el 13 de marzo de 2013
  • XSLT pronto será añadido a la lista de ‘Killed by Google’
  • El texto usa la expresión “Google odia XML y RSS” y enfatiza la relación entre RSS y XSLT

Afirmaciones relacionadas con XML y RSS

  • RSS es una tecnología usada para distribuir noticias, y el texto menciona que al eliminarla Google podría aumentar su capacidad de controlar las noticias
  • XSLT es una tecnología usada en varios sitios web gubernamentales, y se señala que la medida de Google podría afectar también tecnologías web relacionadas con la actividad legislativa
  • Se presenta una visión crítica según la cual “Google refuerza su control sobre la web al eliminar XML y RSS”

Postura de otros navegadores

  • Mozilla señaló que eliminar XSLT podría “romper contenido web existente (break existing web content)”
  • Apple expresó que le gustaría participar antes (participate sooner) que el calendario de 2027 propuesto por Google
  • El texto cita que Google pagó aproximadamente 420 millones de dólares al año a Mozilla y 20 mil millones de dólares en un año a Apple
    • Calcula que en los últimos 10 años se han pagado en total aproximadamente 244.2 mil millones de dólares a ambas empresas

Llamado a preservar XSLT

  • El autor enfatiza el mensaje de “impidamos que Google mate XSLT”
  • También incluye un llamado a la acción: “agrega XSLT a tu sitio web y blog”
  • Cierra con el lema “Keep XSLT alive!”, apelando a la participación de los usuarios y la preservación de la tecnología

Lecturas relacionadas

2 comentarios

 
t7vonn 2025-11-12

Dejemos de enviarlo.
 
GN⁺ 2025-11-11
Comentarios en Hacker News

  • Esperaba que el sitio fuera realmente un documento XML y, por suerte, de verdad lo era.
    Si lo verificas con el comando curl https://xslt.rip/, dentro de la etiqueta <html> aparece la frase “If you're reading this, XSLT was killed by Google.”

    • Es una forma ingeniosa de distinguir si el navegador soporta XSLT.
      El contenido real está en index.xsl, y su creador es un diseñador frontend que también mantiene el genial sitio personal dbushell.com.
      Ambos sitios conservan una sensibilidad muy personal.
    • Para mí, XSLT se siente como una tecnología que hizo explotar la complejidad de la web y al final dejó solo dos navegadores.
      El diseño del sitio da risa de una forma extraña porque recuerda a la web de los 90.
    • Si entras desde un navegador de texto (como Lynx), solo ves esa frase, y se siente parecido a cuando <noscript> muestra “este sitio requiere JavaScript”.
      Ahora me da curiosidad si todavía queda algún navegador que no sea de Google y que implemente XSLT.

  • Estoy fuertemente en contra de quitar el soporte de XSLT en los navegadores.
    En mi sitio personal uso tanto XSLTProcessor de JavaScript como <?xml-stylesheet …?>, y también dejé mi opinión en el hilo de GitHub.
    Pero este sitio parece usar un tono algo exagerado. Creo que las razones de seguridad y mantenimiento de Google son sinceras, aunque me parece que va en la dirección equivocada.
    Una página así, en vez de convencer a quienes toman decisiones, corre el riesgo de solo hacerlos enojar.

    • Quienes usan una función así seguramente serán un grupo élite muy pequeño.
    • Si haces la transformación XSLT del lado del servidor, puedes usar herramientas modernas y funcionará en todos los navegadores.
    • La exageración del sitio parece ser humor intencional.
    • No vas a convencer a quienes toman decisiones con una sola página web. El propósito de esta página es simplemente visibilizar el tema.
    • Dado que libxslt casi no recibe mantenimiento y tiene muchas vulnerabilidades de seguridad, me parece razonable retirarlo.
      Si de verdad quisieran salvar XSLT, lo mejor habría sido crear una nueva implementación en Rust.

  • Tal vez esté en minoría, pero me da pena la realidad de que XSLT se haya quedado estancado.
    Hace 25 años, crear montones de bibliotecas incompletas para reemplazar el ecosistema XML+XPath+XSLT fue un desperdicio de talento.
    Reconozco los excesos de SOAP o XML Schema, pero el enfoque inicial de JSON con eval() tampoco era buena ingeniería.
    Al final, podríamos haber construido un mejor sistema basado en XML, y da lástima haber tirado sus ventajas por perseguir la novedad.

    • Sigue sin haber casi buenos parsers de XML, pero sí hay muchos parsers de JSON.
      En Ruby, Python, Java y otros, parsear XML siempre fue un dolor, mientras que JSON era mucho más simple y estable.
    • La especificación de JSON termina en dos páginas, pero la de XML es un libro entero. Ahí ya se siente la diferencia de peso.
    • Una vez usé XSLT y de verdad lo odié profundamente.
      Era tan complejo que parecía requerir especialistas dedicados, y eso ya se sentía como un desperdicio.
    • Aun así, tenía usos muy buenos, como poder renderizar archivos RSS directamente en el navegador.
      Da pena que desaparezcan las ideas de la web semántica de los años 2010.

  • Casi no uso XSLT, pero me molesta que Google actúe como si fuera “la web misma”.
    Lo mismo con sus intentos de eliminar uBlock Origin, y tampoco me gustan los navegadores con IA que muestran la realidad de forma distorsionada.
    No quiero un mundo donde gobiernos o empresas hagan de intermediarios y controlen la información.
    También creo que la calidad de Google Search ya empeoró intencionalmente desde hace unos 5 años.

    • Pienso igual. No me importa XSLT, pero me deja una gran sensación de cansancio pensar que, si Google dijera que va a eliminar HTML, ¿quién podría detenerlo?
    • Me preocupa que ahora, en la práctica, solo haya tres motores de navegador.
    • Google debería separar Search, Android, Chrome y AdSense.
      Con su monopolio publicitario, la eliminación de adblockers y las restricciones para instalar apps, se adueñó del ecosistema web.
      Aun así, el diseño de este sitio es realmente hermoso y tiene una vibra retro muy viva.
    • Entonces, ¿cuál sería el modelo alternativo?
      Incluso dentro de Google hubo muchas decisiones del tipo “no queremos encargarnos de esto, pero ¿quién más podría hacerlo?”.
      Igual que OpenGL perdió frente a DirectX tras fracasar con el modelo de consorcio, hay una lección en que la apertura de un estándar por sí sola no basta para proteger el mercado.
      Los estándares de navegador cargan un riesgo parecido. Al final, lo importante es quién puede alzar la voz.

  • Como los navegadores ya son demasiado complejos, en parte estoy de acuerdo con retirar XSLT.
    Personalmente nunca usé XSLT y tampoco siento que tenga una relación tan fuerte con RSS.

  • Si mañana Google curara el cáncer, seguro alguien diría que “Google mató el cáncer”.
    No veo a fabricantes pequeños de navegadores queriendo mantener código viejo de XSLT por mucho tiempo, y tampoco parece que navegadores nuevos planeen sumarlo.
    Me parece una decisión bien ordenada.

    • Pero los navegadores pequeños, por naturaleza, implementan solo las funciones que necesitan.
      Entonces me da curiosidad qué empresas, en concreto, están a favor de esta decisión.
    • También preguntaría a qué lugares se refiere exactamente eso de “navegadores pequeños”.

  • Este sitio es una especie de prueba de Rorschach.
    Contiene al mismo tiempo la crítica de “Google mató XSLT” y la sátira de “es ridículo empujar XSLT en 2025”.
    La frase “¡Enséñale XSLT a tus amigos y familiares! ¡Agrégalo a tu sitio web antes de que sea demasiado tarde!” lo muestra muy bien.

    • Claramente busca satirizar la exageración.
    • Pero yo sí uso XSLT de verdad por mi feed Atom.
      En un sitio estático, XSLT es la única forma de renderizar RSS de manera agradable a la vista.
      Cambios así le quitan aún más autonomía a la web personal y empujan todo hacia el mundo de las grandes webapps.

  • Se siente como el final de una era.
    Antes estudié tutoriales de XSLT y me parecía fascinante hacer que documentos XML “cobraran vida”.
    Incluso ahora lo sigo usando para dar estilo a mi feed RSS.
    Los avisos relacionados están en la publicación del foro de Chromium y en la documentación para desarrolladores de Chrome.
    Entiendo que la carga de mantenimiento es alta, pero se siente como si desapareciera otra de esas pequeñas alegrías de la web.

  • Google ya tiene un monopolio en casi todos los frentes.
    Como en el caso de Android (enlace relacionado), ahora también decide qué está permitido y qué no.
    Por eso estaría bien crear un sitio de campaña tipo keepandroidopen.org como keepXSLTAlive.tld.
    O también pulir un poco la interfaz de xslt.rip para darle un aire más de resistencia.

    • Pero aunque la crítica a Google sea válida, eso no significa que haya que seguir manteniendo XSLT.
      La tecnología debe evaluarse por su propio valor.

  • Esta página web está buenísima.
    Me dieron ganas de hacer de pronto una página HTML noventera usando etiquetas <iframe>, <blink>, <marquee> y <table>.

    • Es broma, pero ahora blink y marquee habría que renderizarlos con Canvas.
      No, mejor aún, Canvas ya es viejo, así que habría que hacerlo con WebGPU.
    • Hace falta sí o sí un banner de “sitio en construcción”.
    • Hace poco tuve que extraer datos de una página hecha solo con tablas, y fue un infierno de tablas anidadas.