Leaving PHP, Part 4: the package ecosystem is fine, the gravity is elsewhere

Part 1 looked at who you can hire. Part 2 looked at the runtime they would inherit. Part 3 looked at the type system they would write in. Part 4 looks one layer up, at the packages on top. The standard objection to leaving PHP at this layer goes: "Composer is fine, Packagist works, Laravel and Symfony have mature ecosystems, what is the actual problem?" None of those things are the problem. The problem is the gravity around them.

The first row is true. The second and third rows are also true. The series of posts is about what to do when both are true at the same time.

Composer works. Packagist works. Laravel and Symfony are fine.

It is worth saying this out loud, because the rest of the post is going to be uncomfortable. Composer is one of the better dependency managers in any language. composer require resolves, locks, and autoloads with less ceremony than npm or pip in many shapes of project. Packagist hosts more than four hundred thousand packages. Laravel and Symfony are well-maintained, have large contributor bases, and ship genuinely useful releases on schedule. If your application happens to live entirely inside that universe, it is a comfortable place to live.

That is not the same thing as saying the ecosystem is competitive on the dimension that matters in 2026. The dimension that matters is access. How quickly can you reach for the new thing, and what shape does the new thing arrive in.

Where the gravity is now

Pick any category in which significant new work has shipped over the last two years. AI tooling. Real-time data. Edge compute. Frontend frameworks. Vector databases. Observability. Developer tooling. WebAuthn and passkeys. In every one of those categories, the first-class language clients ship in some combination of Python, TypeScript / Node, and increasingly Go. PHP shows up later, sometimes much later, often as a community port that is good enough for ninety percent of cases and silent on the remaining ten.

The pattern is so consistent that it is now the default. When OpenAI releases an SDK, it is Python and Node on day one. When Anthropic ships an update to its SDK, it is Python and TypeScript that get it first, with parity for the others trailing. When a vector database launches, the documented clients are TypeScript and Python. When a new edge platform announces general availability, the runtime tiers are JavaScript, then WebAssembly, then maybe Python. When a frontend framework ships a new server primitive, the only first-class server is Node.

A snapshot of day-zero SDK support

A non-exhaustive snapshot, drawn from each vendor's public docs as of the time of writing. "Day zero" here means "listed as an officially supported client in the launch announcement", not "exists somewhere on GitHub".

Stripe is the cleanest counterexample, and it is worth noting. Payments are one category where PHP has institutional weight, because half the world's checkout pages run on it. That weight bought first-class treatment. Outside categories with that kind of installed base, the table looks more like the first five rows than the last one.

The tax you pay every time

You can build great products without being on the bleeding edge. The point is not that PHP shops cannot ship. The point is the recurring cost. Every time someone on your team reaches for the new thing and finds a half-finished PHP wrapper around an HTTP API, a port that is two minor versions behind, or no client at all, you pay a tax. The tax has three components.

1. Reading the upstream docs in another language

The vendor's examples are in Python and TypeScript. Your team has to translate them into the equivalent calls in the community PHP client, which may have different argument names, different async semantics, or no support for the specific endpoint you want. The cognitive load of working in two languages at once is not free, and it compounds across an integration.

2. Trusting an unaffiliated maintainer

The community port is usually maintained by one or two people who do it on weekends. When a breaking upstream change ships, the wait between "vendor updated their API" and "PHP client supports the new API" is whatever those maintainers' free time allows. For low-traffic endpoints this is fine. For anything in your critical path it is a genuine risk that no procurement process catches.

3. Being one minor version behind, permanently

Even when the PHP client is well-maintained, it tracks rather than leads. The new model, the new index type, the new streaming protocol, the new tracing format: they all reach Python and TypeScript first and PHP some weeks or months later. You discover this the first time a feature you want to demo on Friday is not in the client until the following Wednesday.

A scorecard for the ecosystem question

None of this means PHP shops are doomed. It means that the cost of every new piece of work you reach for is slightly higher than it would be in a stack the rest of the industry is investing in, and the cost compounds. If your roadmap is mostly "more of what we already do", the gravity does not pull on you very hard. If your roadmap involves any of the categories above, it pulls every week.

Up next in the series

The talent argument was about who can write the code. The runtime argument was about what the code runs on. The type argument was about how confident anyone can be in the code they did not write. The ecosystem argument is about what the code can reach. Part 5 moves to the seam between the code your backend writes and the code your frontend consumes, and the productivity gap that opens when the two cannot share a type system.

If you want to start the migration before Part 10 lands, book a demo and we will walk you through what Pext does to your codebase.