A Minimalist Trick for Inline Rendering Using document.currentScript

In front-end development, the boundary between server-side rendering and client-side rendering often leaves developers torn. Lean Rada shared a clever trick based on document.currentScript that uses just a few lines of code to achieve "in-place replacement" of dynamic content within a page—and can even be extended into a minimalist templating language.

The Core Trick: Let the Script Replace Itself

document.currentScript is a browser-provided property that points to the <script> element currently being executed. Rada leverages this by placing an inline script in the HTML; when the script executes, it directly replaces itself with the computed result:

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

When the page loads, this script is replaced with the current year. The whole process requires no framework and no build step—the browser executes the replacement as soon as it parses the script, and the end user only sees the result.

The value of this approach lies in pulling "rendering" back from the framework layer to the DOM layer. Traditional approaches either assemble HTML on the server or use a front-end framework to take over an entire mount point; the currentScript approach only affects the small area where the script sits, with minimal intrusion.

replaceWith() is a method on the DOM standard's ChildNode interface. It accepts one or more Node objects or strings as arguments and replaces the node on which it is called with them. Unlike common operations such as assigning to innerHTML or calling appendChild, replaceWith operates on the node's position within its parent: after replacement, the original node is removed from the document and the new content occupies the same position. It supports passing multiple nodes or strings at once, and the browser inserts them in order. Note that if a string is passed, the browser parses it as a text node, so a number like new Date().getFullYear() is automatically converted to a string for display. The method is well supported in modern browsers but is not compatible with IE. It is precisely because it directly operates on the node's position that "the script outputs its result at its own location" becomes possible without needing to wrap the script in a container element beforehand.

From Trick to Mini Templating Language

Writing document.currentScript.replaceWith(...) every time is too verbose. Rada defined a short helper function:

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

With this $ function, the earlier example can be simplified to:

The year is <script>$(new Date().getFullYear())</script>

This is almost the prototype of an inline templating language: HTML handles the static structure, and inside the <script> tag a dynamic expression is wrapped in $(), evaluated and replaced in place when the page loads. Compared with pulling in a template engine, this approach has no additional dependencies and a negligible amount of code.

Use Cases and Boundaries to Watch Out For

This inline rendering approach suits simple, infrequently updated content—for example, copyright years, small dynamic fragments in static sites, or prototype validation. Its advantages are zero build and zero dependencies; once you understand the principle, you can use it on the fly.

But it also has clear boundaries. Inline scripts are subject to CSP (Content Security Policy) restrictions and cannot execute on pages that disallow unsafe-inline; replacement happens at the script's location, so it cannot handle complex component state or event binding; and for SEO and accessibility, whether dynamically replaced content is correctly indexed and read aloud needs to be verified in practice.

Rada's share is more of an inspiration: the browser's native APIs still hold many concise solutions obscured by frameworks, and occasionally returning to the DOM itself often reveals lighter-weight answers.

CSP (Content Security Policy) is a security mechanism that browsers declare via HTTP response headers (or <meta> tags) to restrict which resources a page can load and execute. The script-src directive controls script sources; if the policy does not include 'unsafe-inline', all inline <script> tags (including the script this trick relies on) will be rejected by the browser, and a CSP violation error will appear in the console. In addition, 'unsafe-eval' controls dynamic evaluation such as eval(), while 'nonce-...' or 'sha256-...' hashes can whitelist specific inline scripts. This means that on sites with strict CSP enabled, this trick requires generating a nonce or hash for each inline script, which significantly increases server-side configuration complexity when there is a lot of dynamic content. For prototypes or low-security static pages this is usually not an issue, but in production environments you should confirm the CSP policy first.

One-line Summary

Use document.currentScript to replace the script in place, achieving zero-dependency inline dynamic rendering.

Paragraph Summary

The article introduces a front-end trick shared by Lean Rada based on document.currentScript: place an inline script in HTML, and when it executes, use replaceWith to replace itself with the computed result, thereby rendering dynamic content in place as the page loads. The author further defines a short $ helper function that simplifies this into something resembling an inline templating language, with zero dependencies and zero build. The article notes that this trick suits simple scenarios such as copyright years, small dynamic fragments in static sites, and prototype validation, but also cautions that it is limited by CSP restrictions on inline scripts, cannot handle complex component state or event binding, and that the SEO and accessibility of dynamic content need to be verified in practice. Overall, it is a lightweight idea that pulls rendering back to the DOM layer.