Understanding TypeScript's Popularity
TypeScript's growth is roughly that the number of downloads doubles every year on npm. Today it's about 20 million downloads a week. Last April it was about 10 million. That growth is consistent, and doesn't seem to be showing any slowing down.
How we got here
From 2.0 onwards, TypeScript shipped a new release every 2 months. Now it's a bit calmer, there's roughly a month of feature work with a beta, then about 2 months of beta testing and bug fixing. This keeps releases pretty stable and solid.
Major Events Timeline
IMO, these are the big events which enabled TypeScript to keep breaking possible popularity ceilings:
2014 - TypeScript re-write, TS v1.1 - Post-launch and with an understanding of what TypeScript is, the entire codebase was mostly thrown away and re-written in a functional style (instead of classes with mutation) - this architecture still stands today, and is built with long-running processes and very rare mutations in mind. Someone once mentioned that the precursor to TypeScript (Strada) was written in C++, not certain on that through.
2015 - Angular adopts TypeScript, TS v1.5. - Google were looking at building their own language for Angular, instead opting for using TypeScript. To make this possible, TypeScript broke one of its cardinal rules: Do not implement a TC39 thing early. Thus
2016 - Embracing DefinitelyTyped, TS v2.0. - DefinitelyTyped was a side-project handled by volunteers, there were a few different DefinitelyTyped-like systems at the time and the TypeScript team adopted DefinitelyTyped and baked the idea of
@types/xinto the compiler itself. In adopting and taking maintainership of DefinitelyTyped, the team put serious testing and workflow improvements which helped it scale to be one of the most active repos on GitHub. The long-form story of DT is worth a read here.
2018 - Composite Projects, TS 3.0 - There are many ways to handle massive source code repos, composite projects are how TypeScript handles it. You can have a single codebase, but with many TypeScript sub-projects inside it which use .d.ts files as the project boundaries. This saves time and memory, and most importantly allows you to scale to very big codebases.
2020 - Docs re-write - This is my work so take it with some salt, but documentation around TypeScript had been pretty weak over the years. I worked with many long-term compiler authors to re-fresh all user-facing docs, and made a playground which helps users understand TypeScript. It's the first point of call for questions on the language and great docs frees up the compiler team to focus on the compiler.
What were TypeScript's Competitors?
So, if the goal is tooling, then these are a few competitors in that space which TypeScript doesn't really compete with anymore:
ESlint and TSLint: Both are made to highlight possible errors in your code, in the same way that TypeScript does. They just don't add additional syntax in order to give hints to the checking process. Neither aim to run as a tool for IDE integration, and often both TS and TS/ESLint can say "that's the domain of the other" on features which don't make sense to that project. In modern code, TS/ESLint allow TypeScript to have less checks which aren't globally appropriate to all codebases. While there's some overlap, it's better to think about them as complementary projects.
So, why did most OSS Flow codebases end up converting to TypeScript? IMO, a large amount of the reasoning is that the teams have different focuses. Flow is built for maintaining the Facebook codebase vs TypeScript which is built as a stand-alone language. Here's two ways that shows:
How something like DefinitelyTyped vs flow-typed operate. The TypeScript team have a compiler engineer on rotation for DefinitelyTyped support building out tools and helping manage the community. For flow-typed it's almost exclusively ran by the community. DT is bigger now because of that constant work on non-Facebook code which would have been really hard to get funded by the Flow team.
TypeScript's independence within Microsoft gave it the freedom to focus on dev tooling, and the ecosystem as an whole and not solely on one very hard problem. That gave the TypeScript team the ability to work with many others and constantly release things the community wanted. Then over time, I imagine it got harder and harder for the Flow team to get time allocated for community work as their external adoption slowed. Which kinda ends up as a feedback loop. This makes Flow less of a direct "competitor" today, in comparison to ~2-3 years ago and more of an interesting perspective on how to address similar problems from different angles with different constraints.
Update Flow recently updated their public stance on how they interact with the public which matches the above.
Guestimates at the future of TypeScript?
The idea would be to carve out a set of syntax which type-systems like TypeScript can use, but does not define what happens in there to JS runtimes.
const a: string = "1234"// Would look like thisconst a/*: string */ = "1234"// To the JS engine
The JS engine would know that a colon after an identifier
: string is the start of a type comment which ends at an
As the TypeScript team, I'm not necessarily sure we see WebStorm as a competitor (the Visual Studio teams likely do though) as we'd treat the WebStorm team like other external IDE teams.
How TypeScript see its position in the Ecosystem
TypeScript wants to be innovating in the type-system and editor tooling space. We have one of the most expressive type systems in a mainstream programming language.
How does TypeScript think of in terms of its audience??
There are a few userbases for TypeScript:
- JS + JSDoc users (language tools)
- TypeScript users (compiler, language tools)
- TypeScript Strict (compiler, language tools)
With compiler being optional if a codebase uses babel/swc/sucrase/esbuild etc. Each of these sets of folks tends to get something each release, but definitely every 2 releases
How does TypeScript track the JS ecosystem?
The team listens to feedback from a few ways:
- The GitHub issues is a constant torrent of comments
- Internal Microsoft teams request features, or request we help debug their slow codebases
- Connecting to the community via Gitter or the TypeScript Community Discord
- Running user-tests on ideas / designs via Microsoft's internal tooling
- Having a very tight relationship with VS Code, lots language tools feedback comes through them
- We read every @typescript tweet
- We keep track migration blog posts, to TypeScript and from TypeScript
- We track industry surveys and programming langauge overviews