Laravel Splade Core Laravel Package

Product Decisions This Supports

• Build vs. buy (and buy vs. borrow) on the frontend architecture. This package is the engine behind Splade: it compiles Vue 3 Composition API components so they can be used directly inside Laravel Blade templates, with server-side rendering and no separate SPA. For a PM, its real value is as a reference point in an architecture decision, not as a dependency. It defines the upper bound of what "Blade-first with Vue reactivity" can deliver without committing to Inertia, Livewire, or a standalone SPA.
• Roadmap scoping for interactivity. If your roadmap contains a cluster of "make this table filterable / this form reactive / this dashboard live" tickets, Splade-core represents one coherent answer: keep routing, auth, and rendering in Laravel; add Vue only where needed. That lets you size the alternative paths (Alpine islands, Livewire components, Inertia pages) against a concrete model rather than a vibe.
• Feature-level trade-off framing. The package's premise buys you SEO-friendly server-rendered HTML, a single language for routing/controllers, no API layer to maintain, and simpler ops. It costs you client/server state duplication, a smaller talent pool than React/Next, and dependence on a thin ecosystem. That trade-off table is directly reusable in a PRD's "alternatives considered" section.
• Competitive and landscape analysis. In a stack-selection one-pager, Splade sits in a specific niche — Blade + Vue Composition API, no SPA, no full-page JS router — that is otherwise occupied by Inertia (Vue pages, not Blade) and Livewire/Volt (PHP components, not Vue). Documenting why that niche lost ground is itself a decision input.
• Risk and vendor-health calibration. 43 stars, 0 dependents, single-maintainer lineage, archived status, and a release history that went quiet after January 2024 are the signals. The 4.0.1 patch (a single internal method — putPluginOnWorkbench on the Plugin Repository) does not reset that signal: one commit against a dormant repo is an event, not a maintenance cadence. Treat this as a worked example of "how we score dependency health" and how we avoid letting a single tag flip a verdict.
• Not a production feature decision. It does not support any decision of the form "ship X on top of this." Zero dependents and an archived repo mean there is no installed-base evidence of fitness and no upstream to route bugs to. Nothing in 4.0.1 changes that: the change is plugin-repository plumbing, invisible to the end-product surface a PM would scope.

When to Consider This Package

Consider it (narrowly):

• You are running a time-boxed architecture spike comparing Blade-centric stacks and want a working artifact of the Vue-in-Blade model rather than blog posts.
• You need to read the source to understand how Composition API compilation, SSR, and Blade/Vue interop were solved — useful if you are prototyping an internal equivalent.
• You have an existing Splade-era codebase and are doing migration triage; the core package tells you which behaviors you must reimplement on Inertia or Livewire.
• You are prepared to fork and own it (MIT license permits this), you have in-house Laravel and Vue depth, and your requirement is genuinely unusual enough that no maintained alternative fits. Treat it as a codebase you acquire, not a dependency you install.

Look elsewhere (the default):

• Any new production surface — archived, effectively unmaintained, and 0 dependents is a hard stop for a dependency decision. A 4.0.1 patch release is not evidence of revival; ask for a release cadence and a security-response commitment before reconsidering.
• You want Vue pages with a client-side router and prefetching: Inertia.js + Vue is the maintained, Laravel-blessed path and absorbs most of Splade's intent.
• You want reactivity without a JS component model: Livewire 3 (and Volt for single-file components) keeps everything in PHP and is actively developed.
• You want small, local interactivity in Blade: Alpine.js is the low-ceremony answer and needs no architectural commitment.
• You want server-driven partial updates: HTMX covers a meaningful slice of the "no SPA" value proposition with far less coupling.
• You need hiring, community support, or long-term maintenance guarantees — none of which this package offers.

How to Pitch It (Stakeholders)

For executives: We evaluated a package that lets Laravel teams write Vue components directly inside Blade templates, avoiding a separate single-page application. It is a clever design, but the project is archived, has 43 stars, no downstream dependents, and a release history that stalled in January 2024. A 4.0.1 patch landed with one small internal change to its plugin repository; it does not represent renewed investment, a maintainer commitment, or a support path. Recommendation is unchanged: do not adopt it as a dependency. We are using it as a comparison point in the stack decision we already need to make, which costs roughly a day of engineering time and de-risks a much larger commitment. The license is MIT, so a fork is legally available if a future need becomes specific enough to justify owning it — but that is a contingency, not a plan.

For engineering: Treat this as read-only input to the architecture decision, and pin any inspection to the 4.0.1 tag so findings are reproducible. It is the clearest existing example of compiling Vue 3 Composition API into Blade components with SSR and no SPA router. Extract the trade-off lessons — state duplication, SSR hydration cost, build-step complexity, the limits of the "no API layer" promise — and feed them into our Inertia vs. Livewire vs. Alpine comparison. Treat 4.0.1 as a diff to review, not a signal: putPluginOnWorkbench is an internal plugin-repository extension point, not a user-facing capability, and should not be read as a roadmap. Do not add it to composer.json; there is no upstream SLA to patch security issues and no user base to surface them. If we ever need the exact capability, we scope it as an owned fork with a named maintainer and a deprecation path, not as a package install.