- What is tomatophp/splade and what problem does it solve?
- It is a TomatoPHP-packaged distribution of the Splade pattern that gives Laravel Blade applications a single-page-app feel without writing JavaScript routing. Blade templates are paired with Vue 3 and Tailwind, so you can build reactive forms, tables, modals and slideovers using plain Blade components. Architecturally it sits between classic Blade with full page reloads and an Inertia or API-driven frontend. The package is described as Splade Core for FilamentPHP with a lot of custom components.
- Which Laravel, PHP and Node versions does tomatophp/splade support?
- The only public release is v0.0.1 and there is no published changelog, semver contract or CI version matrix, so exact constraints are not documented. Check the composer.json and package.json of the 0.0.1 tag directly, then confirm against your exact Laravel, PHP and Node versions with a hands-on spike. Lock those versions in CI alongside the package before you rely on it.
- How do I install and configure tomatophp/splade in a Laravel application?
- The expected shape is a composer require, publishing the package config, registering the Splade middleware and adding the npm-side dependency plus a Vite build step. Do not attach the middleware to the global web group on the first pass; scope it to a dedicated route group instead. The larger cost is the mental model: understanding which responses are augmented for SPA navigation and how splade() links, modals and Blade partials compose with Vue components.
- Can I enable Splade on only some routes instead of the whole Laravel app?
- Yes, and that is the recommended approach. Register the middleware on a scoped route group rather than the global web group, and convert one low-traffic internal screen first. Because unconverted views remain valid plain Blade views, the rollback path stays cheap and you can migrate screens on demand instead of doing a big-bang rewrite.
- Does tomatophp/splade support SSR, and is it good for SEO-sensitive sites?
- There is no SSR story evidenced in the package, and navigation is client-side after the initial Blade render. That makes it a poor fit for public marketing sites or any surface where crawlers and social previews matter. Keep SEO-sensitive pages on conventional server-rendered Blade or a different stack, and use Splade for authenticated, internal or app-style screens.
- Is v0.0.1 of tomatophp/splade safe to run in production?
- Treat it as pre-stable: 0.0.x permits breaking changes in any patch release, and there is no roadmap, release notes or published support commitment. It is a community re-publication of an upstream package, so divergence from upstream fixes and security patches is the highest-severity risk. The middleware also sits in the hot path of every request it is attached to, so a misconfiguration can affect unrelated routes. Pin the exact version 0.0.1 rather than a caret range, and upgrade only with a manual diff review.
- How should I evaluate tomatophp/splade before adopting it?
- Start with an isolation spike of one to two days in a scratch Laravel app that matches your production version exactly. Build one page containing a splade link, a modal and an async component, and record what breaks. Then run a single-view pilot for one sprint on a scoped route group, and gate further rollout on the spike findings, the observed maintenance burden and answers to the licensing and upstream-sync questions.
- Does tomatophp/splade have automated tests and CI checks on pull requests?
- This is not documented in the release artifacts, and the only artifact published for v0.0.1 is a link to the commit history. Inspect the repository for a test suite, a CI workflow and whether it runs on pull requests before you depend on it. If coverage is absent, budget for your own smoke tests around the middleware, navigation and asset build in your application's test suite.
- What are the alternatives to tomatophp/splade for SPA-like Laravel apps?
- The main alternatives are Inertia.js with Vue or React, Livewire for server-driven interactivity, Alpine or htmx for lightweight islands, and plain Blade with full page reloads. Splade's niche is teams already on Blade plus Vite plus Vue who want partial reloads and modals without adding an API surface or a second deployment target. If your team is standardized on Inertia or a JavaScript framework router, the fit is poor and you should reject it early.
- Who maintains tomatophp/splade and how are upstream fixes handled?
- It is a single-maintainer TomatoPHP publication of an upstream Splade package, with no published support commitment or sync cadence. Before committing, confirm whether it is a hard fork, what the documented process and latency are for pulling upstream bug and security fixes, and what the license and attribution obligations are. Also name an internal owner and estimate the exit cost if the package is abandoned or diverges too far from upstream.