Porting to JS/TS, Part 4: the AI tooling gap compounds every year you wait
Part 3 made the case that TypeScript's type system is the real payoff once a PHP codebase lands on JS. This last part closes the series with a related but separate argument: the AI coding assistants your team already relies on are simply stronger on JavaScript and TypeScript than they are on PHP, and that gap is not standing still. It is widening every year a codebase stays where it is.
Where AI coding assistants are strongest in 2026
Every AI coding assistant on the market in 2026 is only as good as the corpus it was trained on and the tooling ecosystem built around the language it is working in. Both of those are deepest for JavaScript, TypeScript, and Python. That is not a coincidence; it reflects where the bulk of public code, documentation, and Q&A volume has concentrated for the better part of a decade.
Look at the tooling layer specifically. LSP implementations for TypeScript are mature and near-universal across editors. MCP servers, agent frameworks, and coding-agent products overwhelmingly target JS/TS and Python first, often exclusively. PHP has plenty of code in the world, WordPress and Laravel and Symfony alone account for enormous volume, but proportionally less of it is typed, less of it carries modern tooling metadata like a tsconfig.json-equivalent project structure, and less of it sits behind consistent lint configuration an agent can lean on.
None of that makes PHP unsupported. Assistants can read PHP, write PHP, and refactor PHP competently in plenty of cases. But "competent" is a different tier from "as strong as its best language", and in 2026 PHP is not the best-supported language for any major assistant. JS/TS and Python are.
The concrete cost of the gap for a PHP team
The cost shows up first in refactor reliability. An AI-assisted rename or extraction on loosely-typed PHP has less to ground itself in than the same operation on a typed TypeScript file, which is the same argument Part 3 made about types generally, just applied to what an agent can verify before it commits to a change.
It shows up second in integration breadth. The JS/TS ecosystem has a wider set of editor extensions, MCP servers, and CI-integrated agents built specifically for it than the PHP ecosystem does. A team on PHP is choosing from a narrower shelf every time it wants to wire a new AI tool into its workflow.
And it compounds rather than closes. Tooling investment follows usage share, and PHP's share of new development has been shrinking, a trend the talent-pool argument earlier in the original series already touched on. Fewer new projects on PHP means less incentive for tool vendors to build PHP-first integrations, which means the gap a team feels today is smaller than the gap it will feel in three years if nothing changes.
One tool stack instead of two
Here is what actually lands once a codebase is on JS/TS. Most teams already have a frontend, and that frontend is already maintained by AI tooling, whatever editor extension, agent, or MCP server the team has standardized on. Landing the backend on JS/TS means that same tooling now covers the backend too.
That collapses two different tool stacks and two different mental models for how an agent should reason about the code into one. It is not just a developer-experience nicety. It is fewer moving parts to keep an AI coding workflow reliable across the whole codebase instead of half of it, one set of conventions, one set of integrations, one place where the tooling investment compounds instead of being split across a PHP toolchain and a JS/TS toolchain that barely talk to each other.
Where this leaves the two-series arc
This is not a "PHP is dead" argument, any more than the finale of the original Leaving PHP series was. PHP will keep running WordPress, Laravel, and Symfony applications for a long time, and that is fine. The point is narrower: tooling gravity keeps pulling toward JS/TS, and every year a codebase waits, the pull gets a little stronger and the eventual move gets a little more overdue.
Pext exists specifically so a team does not have to choose between staying on PHP and a ground-up rewrite to get there. That is the plain state of things today: the AI tooling gap is real, it is widening, and there is now a path to close it that does not run through a multi-year rewrite. If you want to see what that path looks like for your codebase, book a demo.