René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[Feature]: Optional compiled-template path for `view`","articleBody":"**Pre-flight checklist**\n- [x] I searched existing issues and did not find a duplicate request.\n- [x] I explained the problem or use case, not just the desired API.\n\n**Problem or use case**\n`view` evaluates directive expressions at runtime. That is exactly right for the zero-build CDN story, but it leaves performance on the table for build-using apps and keeps an expression parser/evaluator on the hot path — which is also where the documented `bq-for`/object-expression edge cases live (#136). Svelte compiles templates to optimized JS, and Vue offers a compile step; bQuery has no opt-in equivalent, so larger views pay runtime-evaluation cost they could avoid.\n\n**Proposed solution**\nOffer an **optional**, build-tool-agnostic compile step that pre-parses `bq-*` expressions and emits optimized update functions, while the runtime evaluator remains the default for zero-build usage. This must be strictly opt-in to preserve the \"zero mandatory build step\" goal and must not introduce a bundled build tool of bQuery's own (a non-goal) — it should be a small transform usable from any bundler plus a CLI invocation. Compiled and runtime paths must be behaviorally identical so authoring is unchanged.\n\n**Possible API or UX shape**\n```ts\n// Optional, e.g. as a Vite/esbuild/rollup-agnostic transform:\nimport { compileViews } from \"@bquery/bquery/view/compiler\";\n\n// build step: precompiles bq-* expressions in templates to update fns\n// runtime is unchanged for zero-build users — same directives, same behavior\n```\n\n**Alternatives considered**\nStaying runtime-only forever — acceptable but cedes a measurable performance axis to Svelte/Vue for apps that already build. Making compilation mandatory — violates the zero-build goal and the no-bundled-build-tool non-goal; opt-in is the only design consistent with bQuery's identity.\n\n**Relevant area**\n`view`\n\n**Additional context**\nLower priority than #136/#137 for *stability*, but it both improves performance parity and reduces the runtime parser surface where the known edge cases live. Area could also be classified as \"build or tooling\"; filed under `view` since the behavior it optimizes is the view layer.\n","author":{"url":"https://github.com/JosunLP","@type":"Person","name":"JosunLP"},"datePublished":"2026-06-26T21:25:27.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/138/bQuery/issues/138"}