Blaze Laravel Package

Product Decisions This Supports

• Performance roadmap prioritization: Blaze gives a concrete, measurable lever for frontend rendering cost — 91–97% reduction in component rendering overhead, with headline benchmarks (25,000 anonymous components: ~500ms → ~13ms). This is directly useful when deciding whether to invest engineering time in template refactoring, caching layers, or infrastructure scaling versus a low-effort package-level optimization.
• Build vs. buy: MIT-licensed, Composer-installable, and a drop-in replacement for anonymous Blade components. The default function compiler requires no template changes. This strongly favors "buy/adopt" over building an internal Blade compiler or spending sprint capacity on manual component optimization.
• Feature and design-system decisions: Encourages standardization on anonymous Blade components and design-system primitives (buttons, icons, cards, badges) where Blaze's gains compound. It also creates a decision point on class-based components: converting them to anonymous components unlocks Blaze coverage.
• Adoption sequencing and risk management: The tiered strategy model maps cleanly to a phased rollout: default compilation first (safe, broad), memoization second (repeated slotless components like icons/avatars), folding last (static, aggressively pre-rendered components only). This supports gating advanced optimization behind profiling evidence rather than enabling everything at once.
• Stack alignment with Livewire/Flux: Flux UI users get automatic optimization with no configuration. For teams already on Livewire + Flux, this is a near-zero-cost performance win and a reason to consolidate on that stack.
• Measurement-driven iteration: The debug/trace workflow (BLAZE_DEBUG=true, browse slow pages, analyze trace data, apply targeted memo/fold) creates a repeatable performance-tuning loop that can be owned by engineering without PM intervention.
• Technical debt and refactor prioritization: Known limitations (class-based components, View::share() auto-injection, view composers/creators, view() rendering, $component) surface concrete refactor candidates — e.g., pass data via props instead of shared views — which can be sequenced into roadmap work.

When to Consider This Package

Consider adoption when:

• The application is Laravel-based and component-heavy, with a large resources/views/components directory or a design system built on anonymous Blade components.
• Profiling or user-perceived latency points to Blade rendering overhead — high component counts in loops, icon sets, tables, dashboards, or repeated UI primitives.
• The team uses Livewire and/or Flux UI; Flux components are optimized automatically on install.
• Components are predominantly anonymous and rendered via component tags (<x-...>), which is Blaze's supported path.
• The team can adopt a directory-by-directory rollout: enable compilation for safe directories, clear compiled views, verify output parity, then expand.
• There is appetite for trace-based optimization: enable debug, visit slow pages, and let engineering apply targeted memoization or folding where warranted.
• Repeated slotless components (icons, avatars, status badges) exist — a strong fit for memoization with low risk.
• There are genuinely static components (styling-only buttons, layout wrappers, static icons) that could be folded for maximum gain.
• The organization accepts v1.x maturity risk and limited external validation to date (modest star count, few listed dependents) in exchange for MIT licensing, active releases, and alignment with the Livewire ecosystem.

Look elsewhere or defer when:

• Components are primarily class-based (app/View/Components) — unsupported without conversion to anonymous components.
• The app depends heavily on view composers/creators, lifecycle events, or auto-injected View::share() variables inside components.
• Components are rendered through view('components.…') or View::make(...) rather than component tags.
• Components rely on cross-boundary @aware between Blaze and non-Blaze parents/children.
• Rendering is not a measured bottleneck — database, network, or asset delivery dominate. Blaze will not fix expensive work inside templates.
• The team cannot absorb the operational discipline folding requires. Folding bakes in static HTML at compile time and silently breaks components that read global state (auth, session, request, validation errors, now(), @csrf). Misuse produces subtle, hard-to-diagnose bugs.
• Strict vendor support, SLAs, or long-term maintenance guarantees are required; this is a young, ecosystem-linked package rather than an enterprise-supported product.
• The application must render the same component differently per request based on state that cannot be passed in as props or slots.

How to Pitch It (Stakeholders)

For executives — the one-liner: Blaze is a free, MIT-licensed Laravel package that makes Blade component rendering dramatically faster with no template rewrites. Benchmarks show 91–97% less rendering overhead, and the safest mode is a drop-in replacement enabled per directory.

Business case:

• Cost: Zero license cost, one Composer dependency, no infrastructure change.
• Speed to value: Install, enable compilation for one component directory, clear compiled views, verify. Flux UI users need no configuration at all.
• Impact: Largest where the UI is component-dense — design systems, dashboards, icon-heavy interfaces. Rendering time can drop from hundreds of milliseconds to single-digit milliseconds in component-loop scenarios.
• Strategic fit: Maintained in the Livewire ecosystem; complements Livewire and Flux rather than competing with them.

For engineering — the honest caveats:

• Default function compilation is broadly safe and requires no code changes. Start there.
• Memoization (caching repeated slotless renders) and especially folding (pre-rendering to static HTML at compile time) are opt-in and require care. Folding must not be applied to components that read global state; Blaze detects some cases but not all.
• Known gaps: class-based components, $component, view composers/creators, auto-injected shared variables, view()-rendered components, and cross-boundary @aware. These are exclusion/refactor decisions, not blockers for a phased rollout.
• Recommended rollout: enable compilation directory-by-directory, exclude incompatible components with compile: false, turn on debug tracing, then apply targeted memo/fold only to measured hotspots. This keeps risk low and gains attributable.

Ask: Approve a time-boxed pilot — install Blaze, enable compilation on one high-traffic component directory, measure before/after rendering time and error rates, and report back before expanding coverage or enabling advanced strategies.