Laravel Splade Core Laravel Package

Technical Evaluation

Architecture fit

• Splade's model is a hybrid: Blade renders the initial markup server-side, and Vue 3 hydrates individual components using the Composition API. There is no SPA, no API layer, and no Node-side renderer required beyond the asset build — it sits directly inside an existing Laravel monolith.
• This fits teams that want reactive UI islands without committing to Inertia (full-page Vue) or Livewire (server-driven state). It is a poor fit for anything already standardized on a JS SPA or on Livewire.
• Important nuance: laravel-splade-core is the core runtime/Blade component layer extracted from the parent protonemedia/laravel-splade package. It is generally a transitive dependency, not something an application installs and configures directly. The 0 listed dependents reflects metadata fragmentation, not real-world usage. The TPM-level decision is really "do we adopt Splade?", with this package as an unavoidable sub-decision.

Integration feasibility

• Mechanical integration is cheap: Composer require, publish config/assets, add the Vite plugin, rebuild. A spike can validate a single component in under a day on a compatible stack.
• The real constraint is version alignment. Archived in early 2024 with a final release on 2024-01-31 means the supported envelope is effectively Laravel 10-era, PHP 8.1/8.2, Vue 3.3/3.4, and Vite 4/5. Any current-generation Laravel or Vite major is unvalidated.

Technical risk

• High, and concentrated in abandonment. No upstream security response, no CVE triage, no compatibility patches. Every future Laravel major becomes an internal fork-and-patch project.
• Splade hooks into Blade's compiler and component-rendering internals; those are private-ish surfaces that shift across Laravel majors. This is the most likely breakage vector and it fails at build/compile time, not at runtime — which is at least loud.
• Bus factor of one. Archival implies the maintainer has de-prioritized the project; community channels and documentation are frozen.
• Lock-in is feature-shaped, not just dependency-shaped: Splade ships its own modal, table, form, and event-bus abstractions. The more of those you use, the more expensive the eventual exit.
• Score 0.42 with opportunity 0.36 is consistent with the above — low novelty headroom plus an unmaintained codebase.

Key questions

1. Which Laravel/PHP/Vue/Vite versions are non-negotiable for us in the next 18 months, and does the last release survive them?
2. Who is the named internal owner of a fork, and is that a real allocation or a nominal one?
3. How much Splade-specific surface (modals, tables, form helpers, event bus) would we consume versus plain Vue components inside Blade?
4. Is this a greenfield bet or a rescue of existing Splade code? The risk calculus is very different.
5. What is the exit target — Livewire 3, Inertia, or progressive Vue islands — and what would trigger it?
6. Do we have a policy for unmaintained dependencies with no security feed, or does this require an exception?

Integration Approach

Stack fit

• Assume Laravel 10, PHP 8.1+, Vue 3, Vite. Confirm the Blade compiler hook still registers cleanly on your exact Laravel minor before anything else — that single check de-risks most of the initiative.
• If you are on Laravel 11/12, treat the package as unsupported until proven otherwise and budget for a compatibility patch as a prerequisite, not a follow-up.

Migration path

• Do not consume from Packagist with caret ranges. Vendor it: fork to an internal namespace, tag an internal release, and point Composer at a VCS or path repository. This gives you a place to land patches and makes the dependency auditable.
• Stage the decision behind a spike: one branch, one representative feature (a form with validation and a modal), full build and deploy to a staging environment. Timebox to one to two weeks.
• Keep the Splade API surface behind thin internal wrappers or a component naming convention so a later swap does not require touching every view.

Compatibility

• Pin exact versions in composer.lock and package-lock.json/pnpm-lock.yaml; forbid automatic updates of the Splade fork.
• Build a minimal compatibility matrix (Laravel major × Vue minor × Vite major) and add the Splade smoke test to CI so upgrades fail fast rather than silently.
• Verify the asset pipeline separately: the Vite plugin is the second-most-likely breakage point after the Blade hook.

Sequencing

1. Compatibility spike on a throwaway branch — does it build and run on our target stack?
2. If yes, fork, tag, and vendor; wire CI to the fork.
3. Pilot one user-facing module with a defined rollback path.
4. Publish internal usage guidance limiting which Splade abstractions are permitted.
5. Decision gate at pilot exit: broaden, contain, or begin exit. Set an explicit review date tied to the next Laravel major.

Operational Impact

Maintenance

• You are the maintainer from day one. Realistic cost is 10–20% of one frontend-capable engineer's time in steady state, spiking to weeks around any Laravel or Vite major. That is the price of the framework's productivity gain and should be stated as such in the business case.
• Add the fork to the dependency register with an explicit "unmaintained upstream" annotation so it is not silently forgotten.

Support

• There is no vendor, no SLA, and no security advisory channel. Internal runbook and an escalation owner are mandatory.
• Documentation is frozen at the archive date; expect to rely on source reading and whatever institutional knowledge you build during the pilot. Capture that knowledge — it is the only support tier you have.

Scaling

• Runtime characteristics are unremarkable: server-rendered first paint plus per-component hydration. Server-side scaling is normal Laravel; the watch item is client bundle size and per-page hydration payload as component usage spreads, so track bundle budget in CI.
• The harder scaling constraint is people: this is a niche skill set with a shrinking community. Onboarding a new engineer costs more than the Vue knowledge alone suggests, and hiring for it is effectively impossible.

Failure modes (ranked by likelihood)

1. Laravel major upgrade breaks the Blade compiler hook — build-time failure, recoverable with a patch.
2. Vite or Vue minor upgrade breaks the runtime or plugin — build-time or hydration failure.
3. A vulnerability is disclosed in a transitive JS dependency with no upstream patch path — you own the remediation.
4. Silent behavioral drift as the ecosystem moves and the package does not; no releases means no changelog to read.
5. Over-adoption of Splade-specific abstractions, converting a dependency decision into a multi-quarter migration.

Ramp-up

• A Laravel developer already comfortable with Vue 3 should reach productive use in one to two weeks; the Composition API transfers and the Blade integration is learnable.
• Ramp-up for someone without Vue 3 experience is materially longer, and there is no current tutorial ecosystem to lean on. Plan for internal documentation to be written during the pilot, not after.