Update tech_docs/jinja2_framework.md
This commit is contained in:
@@ -1,3 +1,55 @@
|
|||||||
|
What we are really looking at is two different answers to the same meta-question:
|
||||||
|
|
||||||
|
> “How much of the host language’s power do we allow to leak into a string that is *mostly* meant to be static markup?”
|
||||||
|
|
||||||
|
Everything else—syntax, loops, auto-escaping—are just surface symptoms of that deeper design choice.
|
||||||
|
|
||||||
|
──────────────────────────────────────
|
||||||
|
1. Language Leakage Spectrum
|
||||||
|
──────────────────────────────────────
|
||||||
|
• Jinja2 → **Liberal Leakage**
|
||||||
|
The template *is* a Python DSL. You can call arbitrary Python functions, mutate state, import modules, and even monkey-patch while rendering.
|
||||||
|
Runtime cost: you now need a Python VM and you inherit all of its security surface area.
|
||||||
|
|
||||||
|
• Go templates → **Conservative Leakage**
|
||||||
|
You may register Go functions, but the template engine itself has no loops that can run forever, no variables you can re-assign, and no way to open a file or start a goroutine *inside the template*.
|
||||||
|
Runtime cost: you need only the compiled Go binary; the template is data, not code.
|
||||||
|
|
||||||
|
──────────────────────────────────────
|
||||||
|
2. Meta-Implications
|
||||||
|
──────────────────────────────────────
|
||||||
|
A. **Supply-chain Footprint**
|
||||||
|
Jinja2 pulls in Python → whole interpreter, stdlib, possible venv.
|
||||||
|
Go templates pull in nothing beyond the compiled binary.
|
||||||
|
|
||||||
|
B. **Static Analysis Horizon**
|
||||||
|
Jinja2 can only be analysed by running Python; linters must see *both* the template and the Python context.
|
||||||
|
Go templates are parsed once into an AST that the Go toolchain can reason about at compile time (unused templates, type-safe FuncMap, etc.).
|
||||||
|
|
||||||
|
C. **Security Model Shift**
|
||||||
|
Jinja2’s sandbox plug-in is opt-in and porous (all it takes is one `__subclasses__` path).
|
||||||
|
Go templates are sandboxed *by omission*: if you don’t register a dangerous func, it simply doesn’t exist.
|
||||||
|
|
||||||
|
D. **Deployment Shape**
|
||||||
|
Jinja2 encourages “render server-side” or “render in an Ansible task”.
|
||||||
|
Go templates encourage “compile templates into the binary and ship one file”.
|
||||||
|
|
||||||
|
E. **Philosophical Trade-off**
|
||||||
|
• Jinja2: *“Let template authors express almost anything; trust them.”*
|
||||||
|
• Go templates: *“Let template authors express almost nothing; trust the Go code instead.”*
|
||||||
|
|
||||||
|
──────────────────────────────────────
|
||||||
|
3. Quick Litmus Test
|
||||||
|
──────────────────────────────────────
|
||||||
|
Imagine you have to hand your templates to a junior front-end contractor tomorrow.
|
||||||
|
|
||||||
|
• With Jinja2 you will hand them a loaded gun and a safety manual.
|
||||||
|
• With Go templates you will hand them a paintbrush and a locked-down palette.
|
||||||
|
|
||||||
|
That single difference is the *meta* comparison.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
Here is a “menu” of hands-on project ideas that will give you real-world mileage with Jinja2, progressing from the simplest single-file scripts to more advanced, framework-driven work. Pick one or two from each tier and build them end-to-end; the list is deliberately varied so you can taste every common use-case.
|
Here is a “menu” of hands-on project ideas that will give you real-world mileage with Jinja2, progressing from the simplest single-file scripts to more advanced, framework-driven work. Pick one or two from each tier and build them end-to-end; the list is deliberately varied so you can taste every common use-case.
|
||||||
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
|||||||
Reference in New Issue
Block a user