document.currentScript: the trick for rendering HTML without templates

A single line of JavaScript is enough for a `<script>` element to replace itself with its own output while the page loads. That is the idea Lean Rada describes in Inline rendering with document.currentScript, which Simon Willison picked up on his weblog on October 17 as a neat trick.

The document.currentScript property returns the `<script>` element currently being executed. Combined with `replaceWith`, the script disappears from the DOM and whatever it computed takes its place:

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

A micro template in one line

Things get interesting once you define a shortcut:

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

From then on, every `<script>$(...)</script>` works like an interpolation. Rada uses it for the copyright year, for relative dates (`$(new Date().getFullYear()-2017, ' years ago')`), to pick a random greeting with `Date.now() % 5`, or to wrap each character of a text in tags and animate it with CSS.

The original article goes beyond the one line case. It shows a counter that finds its buttons through `document.currentScript.parentElement.children`, with no need for IDs or classes, and an example that does a `fetch` of a JSON file and replaces the script with a list of links. In that last case you have to store the reference first (`const script = document.currentScript`), because inside a promise or a callback the property no longer points to the script: it returns `null`.

Limits worth knowing

The author is upfront about the restrictions, and there are a few more worth adding:

1. Performance. If the `$` shortcut is loaded from a synchronous external file, it blocks the parser and rendering. Rada warns about this: it can hurt loading metrics.
2. Data. There is no real data driven templating unless that data is injected beforehand as globals or requested from the client, with the extra HTTP request that implies.
3. Security. If you use `innerHTML` or `outerHTML` with content fetched over the network, it has to be sanitized. On top of that, a strict Content Security Policy blocks inline scripts unless they carry a nonce or hash.
4. Modules. `document.currentScript` returns `null` in `type="module"` scripts, so the trick only works with classic scripts.
5. SEO and browsing without JavaScript. Whatever is generated this way is not in the served HTML. For a copyright year it does not matter; for a headline or a price, it does.

Rada positions the technique as a middle ground: tidier than the old `document.write()`, now discouraged, and much lighter than importing a templating library for three dynamic values. For applications with data and state, he acknowledges that libraries and frameworks are still needed.

Who it makes sense for

It fits mostly static pages with small "islands of interactivity": documentation, hand written blogs or landing pages with no build step. It also fits something we see every day: single file HTML tools generated with Claude or other LLMs. Willison has been publishing utilities like these for a while, and a pattern that does not depend on selectors or global state is easy to ask for in a prompt and easy to review afterwards. Fewer moving parts mean fewer places where the model can get things wrong, and less code to audit before publishing.

In projects using Nuxt, Next or another framework with SSR it adds little: the server already resolves those interpolations and the result arrives in the HTML, visible to search engines and to readers without JavaScript.

We think it is a good example of something the web has allowed for years and almost nobody takes advantage of. It does not replace any serious tool, but for a self contained HTML file it is one of those solutions worth keeping at hand.