For a long-lived shared component library, how would you reason about choosing a template-based or render-function-based authoring model?

This is a judgment question with no single right answer, and the interviewer is listening for the axes you weigh rather than the model you land on. ## Start from the output, not the syntax Inventory the library's components by the shape of what they render: - **Mostly-static markup with bindings** — buttons, cards, badges, layout primitives. A large fraction of their output can never change, which is precisely what a compiler exploits. - **Declarative with conditionals and lists** — tables, menus, navigation. Still expressible in a template's syntax, with an identity per item. - **Computed structure** — a control chosen from a configuration value, a recursive tree or outline renderer, a form generated from a schema, a component that wraps or transforms content it was handed. These read naturally as functions and awkwardly as templates. The ratio decides the default. A library whose long tail is the third category and who forces templates on it will produce a layer of indirection — configuration maps, dynamic-component indirection, deeply nested conditionals — that costs more than it saved. ## The axes that outlive the choice | axis | favours a compiled template | favours a render function | |---|---|---| | what tooling can prove | structure is analysable, constants hoistable | nothing is knowable until it runs | | diagnostics | a bad binding can fail the build | shape mistakes surface at runtime | | expressiveness | bounded by the syntax | bounded only by the language | | debugging | you step through generated code | the code you wrote is the code that runs | | build cost and complexity | a compiler in every consumer's pipeline | a lighter build step, or none | | reviewability | markup reads as structure | logic and structure interleave | | non-author contributors | designers can often follow it | usually not | | multiple hosts | the compiler must target each one | the description is host-agnostic | Two axes are chronically undervalued. **Debuggability**: when something goes wrong in compiled output, the stack points at code nobody wrote, and the quality of the mapping back to source is the difference between a ten-minute and a two-hour investigation. **Consumer build cost**: a library that requires a compiler imposes it on every application that uses it, including ones whose pipeline you do not control. ## Design the escape hatch on purpose Most mature libraries end up mixed, and that is fine if the mixture is intentional: 1. **Name the default** and the reason, in the contributing guide, so the choice is not re-argued per pull request. 2. **Define the exception** narrowly — for example, components whose child structure is derived from data rather than written literally. 3. **Make the boundary checkable.** A list of approved exceptions, or a lint rule, beats reviewer memory. 4. **Review the exception list periodically.** If it is growing steadily, the default was wrong for this library and the honest move is to change it rather than keep granting waivers. ## What I would not base it on Microbenchmark numbers alone; the claim that one model is simply faster is not true in general, and the difference will not dominate a real library's performance profile next to payload size, data fetching and layout cost. Nor personal familiarity alone — though team skills legitimately enter through the cost of training and hiring, which is a real number, not a taste. ## Reversibility Ask how expensive this decision is to unwind, because that calibrates how much analysis it deserves. The authoring model is **internal** if the library's public surface is its component contract — names, inputs, events, slots. A consumer who composes your components does not care how their insides were written, which means the model can be migrated component by component behind a stable API. What is not reversible is anything the choice leaks into the contract: a required compiler in the consumer's build, a syntax consumers must write when they extend a component, or a type-checking story they now depend on. Keep the leaks few and the decision stays a two-way door; let them multiply and you have made a one-way one by accident. ## What a strong answer sounds like It starts with an inventory rather than an opinion, names analyzability against expressiveness as the core tension, brings in at least two operational axes such as debuggability and consumer build cost, and ends with the mixed-model plan plus a policed boundary. It also says what would make it revisit the decision — the exception list growing, or a second host appearing.