Product Decisions This Supports
- Theming and authoring for non-developers. The engine's core value is letting designers, marketers, or customers write templates without touching PHP. This directly supports decisions about whether to ship a "customizable templates" feature (CMS themes, landing pages, email/notification layouts) versus hard-coding views.
- Build vs. buy on the rendering layer. This package is itself a "buy" candidate — but a nascent one. The decision it informs is broader: adopt a sandboxed DSL (this or Twig's sandbox), build an internal templating layer, or constrain authors to a fixed component library with no template language at all.
- Safe user-generated content. The sandbox-by-design guarantee (no PHP, no filesystem, no arbitrary calls) is the key product property for any feature where users supply templates — multi-tenant SaaS, white-label portals, marketplace storefronts. That is a security/product decision, not just an engineering one.
- Extensibility roadmap. The "widget seam" pattern means the host application decides which components authors can use. This supports roadmap calls about a component/widget library, filter sets, and constants — i.e., what you expose to authors and what you deliberately withhold.
- Framework posture. Framework-optional (with a Symfony bundle available) supports decisions about coupling this capability to your existing stack, or reusing it in a standalone service.
- Use-case fit signal. The score (0.1) and zero dependents mean this supports evaluation and prototyping decisions today, not production-commitment decisions. Treat it as a candidate for a spike, a fork, or a reference design — not a strategic dependency.
When to Consider This Package
Adopt/trial when:
- You genuinely need a designer-facing, sandboxed template language and the alternative is exposing Blade/Twig/PHP to untrusted authors.
- You are on, or can commit to, PHP ≥ 8.5 — this is a hard gate and currently the single biggest adoption risk.
- You accept early-stage vendor risk (0 stars, 0 dependents, single-maintainer profile) and have the appetite to fork and maintain if upstream stalls.
- You want a clean lexer/parser/AST/runtime you can extend via the widget, filter, constant, and loader seams rather than a monolithic engine.
- MIT licensing and low dependency surface (PSR cache plus two Symfony contracts) match your compliance and dependency policies.
- You are comfortable owning escaping, performance, and i18n behavior in your integration layer — these are not yet proven at scale here.
Look elsewhere when:
- You require a battle-tested engine with community support, CVEs handled upstream, and hiring familiarity — Twig (with its sandbox extension) or Blade is the safer default.
- You are pinned to PHP 8.3/8.4 or need broad runtime compatibility; the 8.5 minimum excludes most current production stacks.
- Templating is not a differentiator for your product — paying integration and maintenance cost for a novel engine is hard to justify.
- You need SLA-backed support, a mature extension ecosystem, or documented performance benchmarks at high render volumes.
- Your authors are developers anyway — the sandbox and non-PHP ergonomics buy you nothing.
How to Pitch It (Stakeholders)
For executives: We are evaluating an open-source (MIT) templating engine that lets non-developers — designers, marketers, and potentially customers — customize page and content layouts without giving them access to PHP or the filesystem. The strategic upside is a safe, self-service theming capability that can reduce engineering bottlenecks and unlock white-label or multi-tenant offerings. The strategic risk is maturity: the project is effectively unproven (no adoption, no dependents) and requires PHP 8.5, which constrains where we can deploy it today. Recommendation: fund a short, time-boxed proof-of-concept against a real theming use case, with Twig-sandbox as the fallback — do not commit it to a production dependency yet.
For engineering: The package provides a complete lexer, parser, AST, and runtime for a small designer-oriented DSL, with clean extension seams for widgets, filters, constants, and loaders. It is framework-agnostic, depends only on PSR cache and two Symfony contracts, and is MIT-licensed — so integration cost is low and the code is readable enough to fork. Key constraints to validate in the spike: PHP 8.5 availability in our environments, output escaping and i18n behavior, render performance under load, and whether the widget seam maps cleanly onto our existing component library. Assume we may need to own maintenance; size that accordingly before adoption.