document.currentScript: el truco para renderizar HTML sin plantillas

Una línea de JavaScript basta para que un elemento `<script>` se sustituya a sí mismo por su resultado mientras la página se carga. Es la idea que describe Lean Rada en Inline rendering with document.currentScript, y que Simon Willison recogió en su weblog el 17 de octubre como un truco ingenioso.

La propiedad document.currentScript devuelve el elemento `<script>` que se está ejecutando en ese momento. Si se combina con `replaceWith`, el script desaparece del DOM y en su lugar queda lo que haya calculado:

html
The year is <script>document.currentScript.replaceWith(new Date().getFullYear())</script>

Una microplantilla en una línea

Lo interesante llega cuando se define un atajo:

js
$=(...n)=>document.currentScript.replaceWith(...n)

A partir de ahí, cada `<script>$(...)</script>` funciona como una interpolación. Rada lo usa para el año del copyright, para fechas relativas (`$(new Date().getFullYear()-2017, ' years ago')`), para elegir un saludo aleatorio con `Date.now() % 5` o para envolver cada carácter de un texto en etiquetas y animarlo con CSS.

El artículo original va más allá del caso de una línea. Muestra un contador que localiza sus botones con `document.currentScript.parentElement.children`, sin necesidad de IDs ni clases, y un ejemplo que hace `fetch` de un JSON y sustituye el script por una lista de enlaces. En ese último caso hay que guardar antes la referencia (`const script = document.currentScript`), porque dentro de una promesa o de un callback la propiedad ya no apunta al script: devuelve `null`.

Los límites que conviene conocer

El propio autor es honesto con las restricciones, y hay otras que merece la pena añadir:

1. Rendimiento. Si el atajo `$` se carga desde un fichero externo síncrono, bloquea el parser y el renderizado. Rada lo advierte: puede penalizar las métricas de carga.
2. Datos. No hay plantillas dirigidas por datos de verdad, salvo que esos datos se inyecten antes como globales o se pidan desde el cliente, con la petición HTTP extra que eso implica.
3. Seguridad. Si se usa `innerHTML` u `outerHTML` con contenido obtenido por red, hay que sanearlo. Además, una Content Security Policy estricta bloquea los scripts inline salvo que lleven nonce o hash.
4. Módulos. `document.currentScript` devuelve `null` en scripts `type="module"`, así que el truco solo funciona con scripts clásicos.
5. SEO y navegación sin JavaScript. Lo que se genera así no está en el HTML servido. Con un año de copyright da igual; con un titular o un precio, no.

Rada sitúa la técnica como término medio: más ordenada que el viejo `document.write()`, hoy desaconsejado, y mucho más ligera que importar una librería de plantillas para tres valores dinámicos. Para aplicaciones con datos y estado, reconoce que siguen haciendo falta librerías y frameworks.

Para quién tiene sentido

Encaja en páginas mayoritariamente estáticas con pequeñas "islas de interactividad": documentación, blogs escritos a mano o landings sin build step. También en algo que vemos a diario: las herramientas HTML de un solo fichero que se generan con Claude o con otros LLM. Willison lleva tiempo publicando utilidades de este tipo, y un patrón que no depende de selectores ni de estado global es fácil de pedir en un prompt y fácil de revisar después. Menos piezas móviles significan menos sitios donde el modelo puede equivocarse, y menos código que auditar antes de publicar.

En proyectos con Nuxt, Next u otro framework con SSR aporta poco: el servidor ya resuelve esas interpolaciones y el resultado llega en el HTML, visible para buscadores y lectores sin JavaScript.

Nos parece un buen ejemplo de algo que la web permite desde hace años y casi nadie aprovecha. No sustituye a ninguna herramienta seria, pero para un HTML autocontenido es de esas soluciones que conviene tener a mano.