Product Decisions This Supports
- Templating strategy for non-Laravel PHP services. webman (Workerman-based, coroutine/async, high-concurrency) is a strong fit for long-running services, but it ships with no opinionated view layer. This package is a thin adapter that wires
illuminate/view (Blade) into webman's container and config, so it directly answers: what do we render HTML with when we're not in Laravel?
- Build vs. buy vs. reuse. Three realistic options: invent an in-house template layer (no), adopt a framework-agnostic engine like Twig/Latte/Plates (viable), or reuse Blade because the org already knows it. This package makes the third option cheap to evaluate — the decision is a skills-and-consistency call, not a technology bet.
- Incremental migration off a Laravel monolith. If a roadmap item is "move hot paths or new services to webman while keeping Laravel for the rest," reusing Blade syntax/components means views, layouts, and
@include/component libraries don't have to be rewritten in lockstep. That de-risks a strangler-fig migration.
- Consistency across polyglot PHP estates. Teams fluent in Blade can carry components, slots, directives, and escaping conventions into webman services — admin panels, internal tools, server-rendered marketing/auth pages, and error pages — without a second templating dialect to maintain.
- Email and notification rendering. Blade is a common choice for transactional email templates; this lets a webman worker render the same templates as the Laravel app instead of duplicating them.
- Roadmap scoping: should this service render HTML at all? In a high-throughput async service, SSR is often the wrong default. Adopting this package is a deliberate decision to support an HTML surface (or a small one) — worth making explicitly rather than by accident.
- Skill/onboarding cost modelling. Blade familiarity is widespread in PHP hiring pools; Twig is comparable, but if the team is Laravel-native, this lowers onboarding cost for new services.
When to Consider This Package
Adopt / pilot when:
- You are already committed to webman for one or more services and need an HTML surface (admin UI, internal tools, auth/error pages, email templates).
- The team is Laravel/Blade-fluent and wants component and layout reuse across Laravel and webman codebases.
- You want Blade's specific affordances (components + slots,
@directive extensibility, auto-escaping, view composers) without dragging in the full framework.
- You can absorb the dependency as a thin, forkable adapter — the meaningful upstream risk is
illuminate/view itself, not this wrapper.
Look elsewhere / do not adopt when:
- Adoption signals are a gate. 5 stars, 0 dependents, and a modest opportunity score mean this is effectively unproven in the wild. Treat it as a spike candidate, not a platform standard. Budget a timeboxed proof-of-concept and a documented exit path before it lands in a production service.
- You need the worker-lifecycle guarantees validated. Blade was designed for php-fpm's request-per-process model. Confirm compiled-view caching, cache invalidation, config/path resolution across workers, and memory growth behave correctly under webman's long-running processes. If the adapter doesn't handle this cleanly, you're maintaining a fork.
- You need a mature, framework-agnostic ecosystem. Twig has broader extension/plugin support, sandboxing, and i18n tooling; Latte has strong security defaults; Plates is native-PHP and dependency-free. If any of those matter more than Blade familiarity, pick them.
- You actually want the whole framework. If you need Eloquent, queues, auth, and Blade together, use Laravel — this package is explicitly for the outside-Laravel case.
- HTML rendering is not a core need. For API-only services, adding a view layer is pure surface area; don't adopt it "just in case."
- You need a supported vendor. There's no commercial support or SLA here; if procurement requires it, this fails the bar.
Evaluation checklist for the spike: version pinning against illuminate/view, behavior under multiple workers, compiled-template cache location and invalidation, opcache interaction, memory stability over sustained load, and whether a swap to Twig would be contained to one renderer interface.
How to Pitch It (Stakeholders)
For executives: We're evaluating a low-cost option to render HTML from our webman services using Blade — the templating engine our team already knows from Laravel. The upside is reuse: existing templates, components, and skills carry over instead of being rebuilt, which shortens delivery and reduces migration risk if we move parts of our Laravel app to webman. The downside is maturity: this is a small, lightly adopted adapter (single-digit stars, no known dependents), so we'd validate it in a timeboxed pilot behind a thin abstraction rather than standardize on it. Fallback is Twig, a mature framework-agnostic engine, and the swap would be contained to a single rendering interface — so the downside is bounded to a few engineering days, not an architectural rewrite.
For engineering: It's essentially illuminate/view wired into webman's container and config — no new templating semantics, no framework dependency, small blast radius. Two things to prove out before we commit: (1) compiled-view caching and invalidation behave correctly across long-running, multi-worker processes, and (2) memory stays flat under sustained load. Wrap it behind a Renderer interface so a move to Twig or Latte is a contained change. Pin the illuminate/view version explicitly and be prepared to vendor the adapter if upstream goes quiet.