Hybridly: a fork of Inertia that puts the Laravel and Vue developer experience first

The README is a question and answer document, and it says why

The most distinctive thing about the Hybridly README is that it is structured as a Q and A page, and the answers are unusually direct about the project's motivations and its limits.

The goal is stated first. Hybridly aims to provide the best developer experience possible when using Laravel, Vue and Vite.

The second question is the one that matters most for an adoption decision, and it is asked explicitly: when should I use Hybridly instead of Inertia? The answer is that Inertia is popular and sponsored by Laravel, that it is the safe option, and that Hybridly exists because Inertia historically had a different philosophy. The guidance is to choose Inertia for better community support, and Hybridly if you value developer experience more at the expense of a smaller community.

That is a project telling you how to choose against it, which is unusual and worth taking at face value.

The third question explains the fork itself. The author tried contributing before writing Hybridly, but the maintenance of Inertia was highly lacking, with pull requests and issues not being addressed, and its minimalist philosophy was not compatible with their developer experience needs.

The fourth question sets the framework scope. The core of Hybridly is framework-agnostic, just like Inertia's, but there is no plan for an official adapter other than Laravel and Vue, because that is what the author is using and willing to maintain. Feel free to create your own adapter though.

The fifth is about longevity, and it is the most candid answer in the document. The author is primarily building Hybridly for themselves, is actively using and improving it, and describes it as an opinionated project that may not suit your tastes. It will live as long as the author is a developer and did not find a better way to build web applications. And if the author ever happens to give up on Hybridly, they will make sure to pass the project on to the community so it can live on.

The primary language is PHP, the licence is MIT, the homepage is hybridly.dev, and the last push was on 2026-09-27. The default branch is 0.x and the release tags are all pre-releases, with v0.10.0-beta.37 the most recent.

A monorepo of five packages, built with bun and a catalog

The repository layout is a monorepo, and the workspace list in package.json tells you how the project is decomposed.

	"workspaces": {
		"packages": [
			"packages/hybridly",
			"packages/core",
			"packages/utils",
			"packages/vite",
			"packages/vue"
		],

So there is a top level hybridly package, which is presumably the Laravel and PHP side, alongside core, utils, vite and vue, which are the JavaScript side. The vite package is the Vite plugin, the vue package is the Vue bindings, and core and utils are the pieces they share.

The build tooling is where the project is opinionated. The packageManager field pins bun at 1.3.10, the scripts are all bun run invocations, and the workspace uses a catalog, a pnpm style dependency catalog that lets many packages declare a shared version for a dependency in one place. The dependency versions in the catalog include typescript and vue as catalog entries rather than pinned versions, which is how the project keeps a monorepo of five packages on one version of the framework.

The scripts are a compact summary of the workflow. Dev runs the kitchen-sink example application, which is a directory in the repository root, with the force flag. Build filters across all packages. Test runs vitest, and test:all runs the JavaScript tests and then the PHP ones with composer test, which is the right shape for a project with a PHP side and a TypeScript side. Typecheck runs the TypeScript compiler in no-emit mode, and ci chains typecheck, build and test together.

The docs are VitePress, with a dev, build and serve script, and the vitepress-plugin-llms dependency suggests the documentation is also published in a form a language model can read, which fits a project whose output is developer tooling.

The PHP side is configured through composer.json and composer.lock, with phpunit.xml for the PHP tests, and the repository also holds a build directory, a dprint.json, a mago.toml and a monorepo-builder.php.

The release script shows the versioning approach, using bumpp across package.json and the individual package manifests, with a hook that bumps the PHP packages too, so the JavaScript and PHP versions move together on a single commit.

What server driven, client rendered actually buys you

The repository description calls Hybridly a solution to develop server-driven, client-rendered applications, and the topic list names the stack: laravel, vue, vite, spa and hybrid.

The shape of the problem is the familiar one. A Laravel application renders HTML on the server, which is comfortable, and a Vue application renders in the browser, which is comfortable for interactivity, and having both in one application traditionally means choosing, or bolting on a JSON API and a separate front end project. The server-driven, client-rendered approach sits in between: the server owns the route and the data, the browser owns the rendering, and the two exchange a page payload rather than a fragment of HTML to splice in.

The advantage over a hand-rolled API is that the server does not hand the browser a bare data structure and leave it to decide what to show. The page arrives as a view with its data already attached, so the front end renders what the server decided to render, and the URL stays a server route rather than a client-side route that has to be coordinated with the back end.

The developer experience claim is that this arrangement, done well, requires very little application code to get the round trip working, and that the ergonomics of the surrounding tooling matter as much as the mechanism.

That is the space Hybridly occupies, and it is worth being clear that it is the same space Inertia occupies. The two are alternatives rather than layers, and the README says so plainly. A team choosing between them is choosing a philosophy and a community, and the project makes the case for one over the other on the grounds of tooling and of how actively each is maintained.

The acknowledgements in the README name Jonathan Reinink, the Inertia team and its contributors, which is where the underlying idea comes from, and the author is Enzo Innocenzi.

A beta line, a small community, and a stated handover plan

Two facts about the project's status should shape any adoption decision, and both are visible in the repository rather than buried.

The first is the version scheme. The package.json version is 0.10.0-beta.37, the release tags are v0.10.0-beta.37, v0.10.0-beta.36 and v0.10.0-beta.35, and the default branch is 0.x. This is a project on a 0.x line with a pre-release suffix on every tag. The releases come roughly every two weeks, from the late August tag to the mid September one to the late September one, which is a fast iteration pace, and a fast iteration pace with beta numbering is the profile of a project that is still finding its shape rather than one that has settled.

The second is the maintenance answer quoted above. It is not a promise from an organisation with a support commitment, it is a statement from one person about their own habit, and the README is honest that the project may not suit your tastes.

There is a middle position worth naming, because it is what a lot of teams actually do. A team can adopt Inertia and gain the community, the sponsorship and the wider ecosystem, and then layer their own conventions on top, because the protocol between server and client is simple enough to add a house style around. What the fork offers is that those conventions are already built in and coherent, at the price of the ecosystem and of the maintenance commitment that comes with a sponsored project.

The build tooling in the repository is the strongest evidence for the first position. A monorepo of five packages with a shared dependency catalog, a bun pinned toolchain, a single release script that bumps the JavaScript and PHP manifests together, and a CI that chains typecheck, build and test, is a deliberate investment in the developer experience that the project says is the point. It is also an investment only one person is making, which is the trade.

The handover sentence in the README is the mitigation, and it is a real one. A project that will pass itself to the community rather than be abandoned is different in kind from one that will simply be abandoned, and for a team weighing a beta line that is the deciding consideration.

The kitchen sink example, and what the docs offer

The repository carries a kitchen-sink directory at its root, and the dev script runs that example application, which tells you something about how the project expects itself to be used. A framework built around developer experience ships a working application that demonstrates the conventions, and the example is what a new user reads first.

The documentation is built with VitePress and lives in the docs directory, with the script set running the dev server for it. The vitepress-plugin-llms dependency is the notable part, because it means the documentation is also published in a form intended to be read by a language model rather than only rendered as a website. For a project whose deliverable is a developer experience, publishing documentation that a tool can read is a deliberate choice about how the project will be used in the years ahead.

The PHP side of the monorepo has its own tooling. composer.json and composer.lock sit alongside the bun lockfile, and phpunit.xml configures the PHP test suite, which the test:all script runs after the vitest run. There is a monorepo-builder.php file, which is the kind of tool that keeps the PHP package versions in step with the JavaScript ones, and a mago.toml, which points at a PHP static analysis and formatting tool. dprint.json covers formatting for the JavaScript side.

The CI script chains typecheck, build and test, and the typecheck script runs the TypeScript compiler in no-emit mode, so the type check is not a separate step from the build but a distinct pass that can fail first.

Editorial conclusion

Hybridly fits a Laravel and Vue team that has looked at Inertia and found the developer experience wanting, and that is willing to accept a smaller community and an opinionated design in exchange for the ergonomics. It does not fit a team that wants the safest choice, because the README itself points at Inertia for better community support, and it does not fit a project outside Laravel and Vue unless somebody writes an adapter. Before committing, read the question and answer section at the top of the README, since the author's own reasoning about why the fork exists is the most useful thing the project has to say about itself.

Frequently asked questions

Official sources

1. hybridly/hybridly on GitHub
2. License: MIT
3. Project website
4. README
5. Releases