I read four TypeScript roundup articles before writing this one, and three of them opened with a different number that was supposed to prove TypeScript is winning. Two of those numbers were from surveys that cannot be averaged. One of them was the same number cited two different ways in the same paragraph. The fourth article had a chart that, on close inspection, started the y-axis at a number that made the bar look four times taller than the data behind it actually was.
I want to talk about TypeScript in 2026. I also want to talk about why almost every “TypeScript statistics” roundup I have read this year is a small piece of statistical malpractice (using numbers in ways that violate basic rules of fair comparison) dressed up as news. The actual story is interesting. The numbers most people cite to support it are mostly noise. Picking which numbers to trust is the work the roundups are not doing for you.
This is not a hit piece on TypeScript. I write TypeScript. I have shipped it. I am in the camp that the language has earned its place in the toolchain, and the 2026 compiler rewrite is the strongest argument yet that the team behind it is doing the work. The argument I want to make here is narrower, and it is about how you read the noise when the noise is loud.
Why the roundups keep picking the biggest number, and why that is wrong
Every TypeScript statistics article I have read this year leads with a different headline number. One leads with monthly GitHub contributors, which is a real number. One leads with Stack Overflow adoption, which is a different real number. One leads with sentiment, which is a softer real number. One leads with the 12x build speedup, which is the only real number that I can actually feel in my day.
The thing the roundups do not do is tell you which number answers which question. They just pick the biggest one and slap a screenshot on it. That is the failure mode. The biggest number is not the truest number. The biggest number is the one that converts best into a headline, which is a different optimization than “which number is the right one for the question you actually have.”
Here is the rule I use. If I want to know how many developers are working in TypeScript right now, I look at one source. If I want to know whether the pipeline will still be relevant in two years, I look at another. If I want to know whether the people using it actually like it, I look at a third. If I want to know whether my build will get faster when I upgrade, I look at the fourth. The mistake is using any one of those sources to answer any of the other three questions.
- Adoption today comes from one source with a clear methodology.
- Future relevance comes from a different source with a leading signal.
- Sentiment comes from a third source, treated as direction not count.
- Compile time comes from the release notes and your own measurements, not a survey.
The four numbers that matter, and which one answers which question
The four sources I keep returning to in 2026 are GitHub activity, Stack Overflow, State of JS, and the TypeScript release notes. Each one is measuring something specific. Picking the right one for the right question is the skill most roundups skip.
GitHub activity (the monthly contributor counts and new repository creation data) tells you how many humans are pushing code into the language’s orbit. The new-repository number is the leading indicator (a metric that changes before the underlying trend is obvious). The monthly-contributor number is the lagging one (a metric that reflects what already happened). Together they tell you whether the language has a pipeline of new projects being created AND a community still active in the existing ones. That is healthier than a million fresh repos nobody maintains, or a small set of active maintainers on a quiet language. The combination is the story, not either number alone.
Stack Overflow’s annual survey tells you what fraction of working developers touched the language in the last year. The number is fuzzy (it is self-reported, online, and lets people pick multiple languages), but the professional subsample (people who said they are working developers) is the cleanest signal in the dataset. That subsample is the right number to put on a slide for a non-technical audience. The wider sample is too noisy.
State of JS is a different survey with a different methodology and a different sample. It asks how much of your code is written in the language, which is a more aggressive question than Stack Overflow’s “did you do extensive work in it this year.” The gap between the two numbers tells you how many people touch the language versus how many people write their whole codebase in it. That gap is interesting, and most roundups do not mention it.
The TypeScript release notes tell you what changed in the compiler. That is the only source that measures the thing you actually feel when you press save. Surveys cannot tell you whether your build got faster. Release notes can, and you should measure it yourself on your own machine before believing either the roundup or the announcement.
- GitHub measures activity. New repos plus monthly contributors, together.
- Stack Overflow measures adoption. Professional subsample is the cleanest number.
- State of JS measures depth. All-of-it writers versus touched-it users.
- Release notes measure speed. Verify on your own machine, not the roundup.
Why the 12x build speedup is the number I trust, and why the surveys are not
TypeScript 7.0 shipped in the summer of 2026 with a compiler rewritten in Go (a compiled programming language developed at Google, known for fast execution and predictable performance). The headline number from the release notes is the VS Code build, which went from 125.7 seconds to 10.6 seconds. That is a 12x improvement on one of the largest TypeScript codebases in existence, on a build the TypeScript team itself runs as a regression test.
What makes me trust this number more than the survey numbers is that it is a single measurement on a real codebase. There is no self-reporting. There is no fuzzy “did you do extensive work” question. There is a benchmark the team publishes, and the team measures it themselves, and you can run the same benchmark on your own code and see whether the speedup shows up for you. That is what an honest measurement looks like.
Surveys cannot give you that. They are self-reporting from a self-selected sample (people who chose to take the survey, which already skews toward certain kinds of developers). Survey numbers are directions, not counts. Survey numbers drift with the population that takes the survey that year. If the population shifts from web developers toward mobile developers, every language’s number drifts. That is not a flaw of any particular survey. It is just what surveys are, and the roundups that treat them as exact counts are the ones doing the misinforming.
Build speed is also the number that matters to you personally. If you write TypeScript, your day is shaped by how long the compiler takes. If the compiler drops from 125 seconds to 10 seconds, your day is shaped differently. That is the only number in any of these datasets that I can feel without doing the survey myself.
- 12x speedup on VS Code is a real measurement on a real codebase.
- Survey numbers are directions, not exact counts.
- Sample drift affects every survey, every year, in ways the roundups ignore.
- Your build time is the number you can measure yourself and you should.
What I would tell past me if I were starting over
If I could send a message back to the version of me that read the first TypeScript roundup in 2022 and decided the language was hype, I would say four things.
- The compiler speed is the only number that matters in your day. Surveys are for trend-watchers and slide-makers. The compiler is for you.
- Pick the source that answers the question you have. Adoption, future, sentiment, speed. They are different questions with different answers. Do not average them.
- Trust your own machine. Run the benchmark on your project before believing either the roundup or the announcement. Numbers in articles are not your numbers.
- Sentiment is the leading indicator. When 58% of working developers say they want to keep using a language, that is what the next two years of job postings will look like.
Trade-offs
The compiler rewrite is not free. On the VS Code build the time went from 125.7 seconds to 10.6, and the memory cost moved less aggressively. If you run TypeScript on a small laptop with 8 GB of RAM and you watch memory closely, you will probably want to test 7.0 on your own project before flipping the switch in CI (continuous integration, the automated pipeline that builds and tests every change). The speed win is real. The memory profile is workload-dependent, and that is worth knowing before you commit.
The other trade-off is that survey numbers will keep being noisy. That is not going to change. The roundups that quote them without telling you which question each one answers will keep being roundups, and they will keep being wrong in the same way. If you want a cleaner signal, you have to do the work yourself. That is the cost of trusting any dataset that you did not collect.
In my case, the cost was about an hour of running benchmarks on three projects and writing down the numbers in a spreadsheet nobody else will ever read. Your math will be different if you are the kind of person who reads roundups for fun and does not need to verify them. If you ship TypeScript to production, the hour is a clear win. If you do not, the roundups are fine, and you should still pick one number per question.
The thing I gave up to learn this was the assumption that any single article could tell me whether a language is winning. It cannot. The winning is in the compiler. The surveys are the noise.
If you only do one thing from this article, run the build before and after upgrading TypeScript on a small project this week. The number you measure is the only TypeScript statistic that will ever matter to you.