Jaxon Core Laravel Package

Product Decisions This Supports

• Build vs. buy for the "last mile" of interactivity. Jaxon generates JavaScript proxies from annotated PHP classes so server-side methods can be invoked directly from the browser. That removes an entire hand-written REST/JSON + fetch layer, which is often 20–40% of the effort in modestly interactive features.
• Roadmap sequencing: modernize incrementally instead of replatforming. For a server-rendered PHP product, this is a credible "strangler" path — upgrade individual screens (tables with filters, multi-step forms, inline edit, pagination) to AJAX behavior without committing to an SPA rewrite or a frontend build pipeline.
• Use-case fit. Strongest for internal tools, admin/back-office consoles, form-heavy CRUD, wizard flows, and any surface where the team's strength is PHP and the UI complexity is "partial page updates," not "application state management."
• Team-shape decisions. Enables a PHP-only team to ship reactive UI without hiring frontend specialists or adopting Node tooling. That's a real hiring and velocity lever, and it should be evaluated as such, not just as a technical dependency.
• Architecture boundary decision. Jaxon sits as a request/response RPC layer with a plugin system and DI container. Choosing it means deciding that your browser↔server contract is PHP method signatures, not a versioned public API. That's fine for first-party UI; it is a poor fit for anything you intend to expose to third parties or mobile clients.
• Scope control. Because it is a core library rather than a framework, it doesn't dictate routing, templating, or persistence — so it composes with an existing Laravel/Symfony app rather than forcing a migration. That keeps the decision reversible, which is exactly the property you want in a low-confidence adoption.

When to Consider This Package

Consider it when most of the following hold:

• The application is server-rendered PHP and will stay that way for the planning horizon.
• You need partial-page updates and server-triggered calls, not client-side routing, offline behavior, or complex shared state.
• The team is PHP-first, with limited or no JS tooling capacity, and hiring frontend engineers is not on the table.
• You want to avoid standing up a JSON API for endpoints that only your own templates will ever call.
• You are on a supported PHP version and can accept the library's own upgrade cadence.
• You're willing to isolate the integration behind a thin internal abstraction so it stays replaceable.

Look elsewhere when:

• Adoption risk matters. 74 stars is a thin ecosystem — few Stack Overflow answers, few third-party plugins, limited hiring signal, and a plausible single-maintainer bus factor. For a multi-year, business-critical surface, weigh that heavily against the velocity gain.
• You need a public/versioned API, mobile clients, or third-party integrations — design a real HTTP API instead.
• You need real-time (WebSockets/SSE), high-frequency updates, or offline-first behavior.
• You already have, or plan to have, a JS framework and build pipeline (Vue/React/Livewire-style stacks). Mixing paradigms usually costs more than it saves; in a Laravel shop, evaluate first-party options before reaching for a niche library.
• You need strong typing and discoverability across the client/server boundary, or generated-client tooling.
• Compliance or procurement requires a vendor with support contracts or a demonstrated contributor base.

How to Pitch It (Stakeholders)

To executives: This is a small, permissively licensed (BSD-3-Clause) PHP library that lets our existing backend team add interactive UI — live tables, inline editing, multi-step forms — without a rewrite, a new frontend stack, or new frontend hires. The strategic value is optionality: it modernizes screens incrementally and is removable, because it sits beside our framework rather than replacing it. The cost is a niche dependency with a small community; we mitigate that by scoping it to internal and back-office surfaces and keeping the integration behind our own interface.

To engineering: Jaxon is a PHP-native RPC layer — annotated PHP classes are exposed to the browser as generated JS proxies, with request handling, a plugin system, and a DI container in the core package. It's actively released (most recent release dated 2026-10-23) and BSD-3-Clause, so no licensing friction. Treat it as a transport convenience, not an architecture: no public API contract, no typed client, and a small ecosystem means we own the debugging. Keep handlers thin, keep business logic in framework-agnostic services, and wrap the registration/response surface so a swap to plain JSON endpoints is a contained change.

Recommendation: Pilot on one back-office workflow with a clear success metric (delivery time vs. an equivalent JSON + fetch implementation). If it doesn't clearly beat the conventional approach in that pilot, don't expand it — the adoption risk isn't worth a marginal win.