TypeScript Is Eating JavaScript, One Codebase at a Time
Static typing is winning over plain JS as remote teams lean on TypeScript to catch bugs the code review chat can no longer catch.
I keep having some version of the same conversation with other developers lately: “we finally moved the backend to TypeScript” or “yeah, we’re rewriting the old JS modules bit by bit.” A year ago these were still edge-case decisions. Now it feels like the default.
Nothing about TypeScript itself changed dramatically to cause this. What changed is how teams work. A big chunk of the industry has been remote since last spring, and a lot of the informal safety net that used to catch bugs — someone glancing over your shoulder, a hallway conversation about “wait, what shape is that object supposed to be” — just isn’t there anymore. Code review over a pull request thread is a poor substitute for that kind of ambient context-sharing, especially on a team that’s distributed across time zones and half-asleep on a 9am call.
Static types fill that gap surprisingly well. When a function signature says exactly what it expects and returns, you don’t need to ask the person who wrote it three weeks ago. The compiler becomes a stand-in for the coworker who isn’t in the room. That’s a genuinely different value proposition than the one TypeScript was pitched on originally, which was mostly about scaling large codebases and avoiding a certain class of runtime errors. Now it’s also about scaling communication.
Where the pressure is coming from
Open-source maintainers seem to be feeling this acutely. Projects that held out on plain JavaScript for years are quietly landing TypeScript migrations or shipping first-party type definitions instead of leaning on community-maintained ones. Contributors submitting PRs without a project maintainer live on a call to explain intent benefit enormously from the editor just telling them “no, that argument is wrong” before they even open a pull request.
On the enterprise side, the calculus is similar but the stakes are higher: onboarding new engineers remotely is harder, so anything that reduces the amount of tribal knowledge someone needs before they can safely touch a file is worth paying for. Migration cost used to be the objection — converting a big JS codebase is not free, and neither is putting the whole team through the learning curve. But that argument is getting weaker as more engineers arrive at their first job already having used TypeScript in school or a bootcamp.
I don’t think plain JavaScript is going away — plenty of scripts, prototypes, and small projects don’t need the ceremony, and vanilla JS is still what actually runs in the browser and in Node under the hood. But as a default choice for anything that’s going to be touched by more than one person over more than a few weeks, the incentive structure has tipped hard toward TypeScript. It’s less about type theory purism and more about a practical bet: if your team can’t rely on being in the same room, let the type checker do some of the reviewing for you.
Worth watching where this settles. If the trend holds, “why isn’t this in TypeScript” might become the kind of question you have to justify saying no to, rather than the other way around.