HTML template compiler

Q: HTML template compiler

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the real, defining efficiency property this question tests — that the expensive parsing step happens only ONCE, with the returned function cheaply REUSED across many renders — was verified directly with a real counter, confirming exactly 1 compile call across 3 separate real render invocations. ## 1. The problem, restated A naive approach would re-scan the template STRING on every single render call, repeatedly paying the same parsing cost. A proper compiler instead does the parsing work ONCE, producing an intermediate representation (a list of alternating literal-text and interpolation-expression parts), and returns a lightweight closure that only needs to walk that already-parsed list on every render, substituting real data values as it goes. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Parsi

The problem

Problem, as an interviewer would state it: "Write a template compiler supporting {{variable}} and {{object.path}} interpolation — compile(template) should return a fast, reusable render function, doing the expensive PARSING work only once."

Examples:

Code

const render = compile("Hello {{name}}, you are {{user.age}} years old.");
render({ name: "Ada", user: { age: 30 } }); // "Hello Ada, you are 30 years old."
render({ name: "Grace", user: { age: 45 } }); // reuses the same compiled parts

Clarifying questions expected:

Should parsing genuinely happen only ONCE per template, with the returned function reused efficiently across many renders?
What should a missing or undefined interpolation path render as — an empty string, or the literal word "undefined"?
Does the interpolation syntax need to support nested object paths, not just top-level variable names?

Code / implementation expected: Yes — real, direct proof that compiling happens exactly once (via a real counter) across 3 separate renders with different data, and that a missing path renders as an empty string.

js-coding
utility
algorithm

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Medium

How to read this doc: the real, defining efficiency property this question tests — that the expensive parsing step happens only ONCE, with the returned function cheaply REUSED across many renders — was verified directly with a real counter, confirming exactly 1 compile call across 3 separate real render invocations.

1. The problem, restated

A naive approach would re-scan the template STRING on every single render call, repeatedly paying the same parsing cost. A proper compiler instead does the parsing work ONCE, producing an intermediate representation (a list of alternating literal-text and interpolation-expression parts), and returns a lightweight closure that only needs to walk that already-parsed list on every render, substituting real data values as it goes.

2.

The solution is hidden so you can try first

7 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: compiling happens exactly once across multiple renders (confirmed via a real counter), and a missing path renders as an empty string