What can a template compiler know about a compiled template that a build step cannot reliably learn from a render function?

A compiled template is a **fixed structure with holes**. A render function is a **program whose output happens to be a structure**. Almost every difference in what tooling can offer follows from that one asymmetry. ## What the compiler can see Given a template, a compiler can walk it before the application ever runs and establish: - the complete element and attribute shape of the output, including which elements are children of which; - which text nodes and attributes contain interpolation, and which contain nothing but literal content; - which whole subtrees are **static** — no interpolation, no conditional, no loop anywhere inside them; - for each dynamic part, the expression behind it, and therefore the values it reads; - the boundaries of each conditional and each repeated chunk; - names referenced by bindings, which it can check against the component's declared inputs and state. None of this is available for a render function. A build step can read the function body, but the body is not the output: a branch decides the shape at call time, a helper can be imported from elsewhere, a component type can come out of a variable. What the runtime eventually receives is a finished description with no record of the alternatives. ## What it does with that knowledge | knowledge | what the framework can do with it | |---|---| | a subtree contains no dynamic parts | create it once and reuse it on every render instead of rebuilding it | | this attribute is the only dynamic part of an element | emit an update path that touches that attribute and nothing else | | this expression reads these values | connect the binding to its inputs without comparing the whole result | | this binding names something that does not exist | fail the build with a message pointing at the line | | this chunk repeats over a collection | emit list-handling code, and require an identity for each item | **Hoisting** is the easiest one to state concretely. If a chunk of markup can never differ between renders, its description — or in some runtimes the host nodes themselves — can be built one time and referenced afterwards. A render function that returns the same literal structure rebuilds those objects on every call, because a function call has no memory of the previous one unless the author adds memoisation by hand. ## Where the comparison is often overstated Three honest caveats, and interviewers listen for them: 1. **It is not a guarantee of speed.** Compiled output is not automatically faster than a well-written function; it removes a class of repeated work, and the win depends on how much of the output is static. A template with an interpolation in every node has almost nothing to hoist. 2. **The compiler's reach ends at the dynamic expression.** It can tell that a binding reads a value; it cannot tell what the value will be, so anything that depends on runtime data is still runtime work. 3. **Function-based frameworks can recover some of it.** Compilers exist that analyse render functions and insert memoisation or lift constant sub-descriptions automatically. They must be conservative — the analysis has to be correct for every possible execution — so they recover part of the advantage, not all of it, and they can bail out on code they cannot prove safe. There is a fourth boundary worth naming: an explicit raw-markup opt-in is opaque to the compiler as well. A string parsed into nodes at runtime has no analysable structure, so nothing inside it can be hoisted or tracked. ## The mirror-image cost Everything the compiler gains comes from the template being **closed**: its syntax is the only vocabulary available. Output whose structure is computed has to break out of that vocabulary, which is why template systems keep a render-function escape hatch, and why a codebase usually ends up with both. A team that understands the tradeoff reaches for the function deliberately, in the few components whose shape is genuinely data-driven, and leaves the rest where the compiler can help. ## How to answer this in an interview Lead with the asymmetry in one sentence — a template is a structure the compiler can read, a function is a program whose result it cannot predict. Then give two concrete consequences, hoisting the static parts and per-binding dependency tracking, and one diagnostic consequence, catching a bad binding at build time. Close with the caveat that this buys analyzability, not magic: the dynamic parts are still dynamic, and a template with nothing static to hoist gains little.