Evidence at a glance
The Cost of a Placeholder
Lean Rada describes an inline rendering technique built around `document.currentScript`: place a classic `<script>` where the content should appear, then have the script replace itself when it runs. The examples address small dynamic fragments in otherwise static pages, such as a year or a relative date. Simon Willison linked to the technique on October 17, 2026.
A common alternative is to put a placeholder with an `id` in the HTML, then have separate JavaScript find it and fill it in. When the content is minimal, this spreads the display location, lookup logic, and generated value across different places. Rada’s approach moves the script to the output point, removing the extra location marker and lookup step.
This does not introduce a new rendering capability. It makes the relationship between code and markup more direct. For a technical lead, the useful idea is a local simplification: a small piece of page logic can become more self-contained without adding a templating layer. Whether that tradeoff helps depends on whether the page’s needs are genuinely small and localized.
Code First, Temporary Anchor Second
The mechanism depends on a specific moment of execution. While a classic script is running, `document.currentScript` returns the active `<script>` element. Calling `replaceWith()` then replaces that element with text or nodes. For example, `document.currentScript.replaceWith(new Date().getFullYear())` puts the calculated year where the script used to be. The script briefly acts as a DOM anchor, and the generated content remains after it runs.
Rada also shows a shortcut: `$=(...n)=>document.currentScript.replaceWith(...n)`. The page can then use `The year is <script>$(new Date().getFullYear())</script>` as a more compact expression. It may resemble miniature template syntax, but the actual operation is much narrower: run the current script and put the supplied value or nodes in its place. It does not provide the structural management or data binding of a templating system.
The same locating idea can support localized interaction. Rada’s example uses `document.currentScript.parentElement` to find a counter and button in the same parent element, then attaches an event handler to the button. This shows how a script can organize a small nearby fragment instead of querying the page globally each time. But once behavior reaches beyond that local area, the relationship between script and page structure may no longer be as clear.
Limits of Time and Script Type
“In place” does not mean the script can always find itself again. If content depends on an asynchronous operation such as `fetch()`, code should not assume that `document.currentScript` will still point to the original script when the callback runs. Save a reference to the script element before starting the asynchronous operation, then use that reference to replace it when the result arrives. The anchor can be used later, but the code must preserve it explicitly.
Script type also affects availability. The HTML standard and MDN material cited here say that `document.currentScript` returns `null` in module scripts. It also does not automatically point back to the original script while an event handler or callback is running. So the fact that code is written at a particular location does not mean this technique works in every JavaScript execution context. The API has been widely available in major browsers since July 2015, according to the supplied material, but broad support does not remove these usage conditions.
Rada once wrote that the technique could not be used for data-driven templates, then corrected that claim: if the script reference is saved, content can also be replaced after asynchronous data arrives. This correction does not reveal a contradiction in the mechanism. It makes the boundary more precise. The limitation is not that the technique can handle only constants. It is that asynchronous code cannot rely on the transient `currentScript` property and must manage the script element’s lifetime explicitly.
Shorter Code Is Not Proof of Faster Pages
For a blog or documentation page dominated by static HTML, this technique can place scattered content such as years and relative dates where it belongs. It can also keep a small interaction close to the text and buttons it operates on. Its engineering value is mainly a reduction in back-and-forth lookup between markup and script, making it easier to see which part of the page a piece of code serves. If a project already has established templating conventions, that local convenience may not outweigh the maintenance cost of adding another style.
The available material offers no performance benchmark against template engines, server-side rendering, or frameworks. It also does not quantify changes in parsing or rendering delays. So “one fewer placeholder” does not establish that a page will be faster, and shorter code is not evidence of architectural superiority. The cited material notes that external scripts can block parsing and rendering, but provides no timing comparison for this inline technique on a specific page.
The security boundary does not disappear just because a script replaces itself in place. If external data is inserted with `innerHTML` or `outerHTML`, the HTML still needs to be sanitized first. A practical decision can be made by the scale of the need: consider this approach when content is small, fixed in position, and handled by a classic inline script. If the page requires complex structures, multiple data sources, or modular organization, do not promote the trick into a replacement for a templating system. Strict CSP deployment questions are also outside