Everyone's heard by now that TypeScript "went native." And I keep seeing the same wrong conclusion drawn from it: that TypeScript now somehow runs ...
For further actions, you may consider blocking this person and/or reporting abuse
At the moment it feels like nothing really changed for most developers besides the performance improvements. But changing the compiler core is a huge step. I think the real impact will come in future releases because this new foundation should make it much easier to introduce bigger features and optimizations without being limited by the old architecture.
Agreed, the foundation is the real story here. The old compiler was locked to a single thread by JavaScript itself, so a whole class of optimizations was off the table no matter how clever the code got. Now that the checker already scales across parallel workers, I would expect future releases to push much further on incremental builds and editor performance than the old architecture ever allowed.
Good point. Which area do you think will benefit the most, incremental builds or editor responsiveness?Do you think we'll start seeing those bigger improvements already in the next major release?
My money is on editor responsiveness, simply because you feel it hundreds of times a day while a full build you feel a few times. There is also a funny side effect, when a clean full check of a huge codebase takes ten seconds, incremental state matters less than it used to. So the editor is where the parallel checker really pays off. On timing the only thing announced for 7.1 is the stable compiler API, so my guess is the bigger performance pushes come after that once the ecosystem is back on one version.
Yeah, that makes sense. Faster editor feedback is something every developer notices immediately. It'll be interesting to see how much they can improve once the ecosystem catches up.
One interesting point is that performance improvements are often most valuable when they don't require developers to change the way they work. Faster tooling with minimal migration effort tends to have a much bigger long-term impact than introducing new language features that require teams to rethink existing codebases.
Well said. The zero migration part was a deliberate choice too since the team ported the old compiler almost function for function precisely so adoption would feel like a minor version bump instead of a rewrite gamble. And I think the long term impact goes beyond the saved minutes, teams quietly stop doing things like skipLibCheck everywhere or splitting repos just to keep the compiler bearable and that changes how codebases grow without anyone announcing anything.
That is a good point. Better defaults can have a bigger impact than people expect.
Well said. JavaScript got new syntactical sugar every year, but it's still missing type safety. So we're still writing --C0ffeeScript-- TypeScript that needs to compile. Most devs used to transpile their vanilla JS as well, too, to use the new syntax and still provide backward compatibility.
So, TypeScript 7 didn't really chang anything from a web developers' perspective.
Thanks Ingo. You are right that nothing changed in what ships to the browser,that was half the point of the article. Where I would push back a little: the feedback loop is also part of the web developer perspective and waiting for squiggles and CI is where a lot of our day actually goes. The code stayed the same but the waiting did not and I will take that trade.
The multithreading point is the part most coverage buries, and it's actually the more durable insight. I work in JS-based static analysis — ESLint rule authoring — and hit the same structural ceiling: rules traverse the AST in a single-threaded walk, and parallelizing via worker threads means serializing and copying the same graph rather than sharing it. TypeScript's Go port is essentially a controlled experiment that puts a number on what that ceiling costs at scale: roughly 10x over real-world codebases. That's a useful data point for anyone reasoning about the long-term performance trajectory of any JS-based analysis toolchain, not just tsc.
The controlled experiment framing is excellent, and it works precisely because this was a port rather than a rewrite: the algorithms stayed the same, so the 10x isolates the cost of the runtime and the single threaded ceiling instead of mixing in better engineering. Your ESLint example is the same graph problem in miniature, workers that copy the AST instead of sharing it pay the tax on both ends. It also explains why the newer native lint tools went ahead of time compiled from day one. Curious where you think ESLint itself lands long term, given that type aware rules are already waiting on the TypeScript 7.1 API anyway.
The controlled-experiment framing extends further than the port itself: even within a single-threaded run, ESLint's cost is mostly graph traversal and JSON serialization at rule boundaries, not the actual matching logic. I've profiled configs where AST-to-plugin marshaling ate 30-40% of lint time on large monorepos, before any rule executes. So the worker-copy tax you're describing isn't just an IPC problem, it's baked into how the rule API shape works today. Type-aware rules waiting on 7.1 makes it worse, since type info is the most expensive thing to serialize across a boundary. I think ESLint proper stays JS-hosted for compatibility, but the real gains go to tools willing to break the plugin API and compile rules in-process.
Like that you separated the real changes from the hype and made it clear that most developers will mostly notice the performance improvements, not major language changes. Do you think the ecosystem will catch up quickly, especially tools like ESLint and ts-jest? Also, have you tried TypeScript 7 on a large production project yet, and if so, did the build times improve as much as expected?
Thanks! On the ecosystem question, the key date is 7.1 when the stable compiler API ships. Tools like typescript eslint and the framework template checkers need that API which is why the dual setup with TypeScript 6 exists today. My guess is the catch up will be quick after that since the big tool teams have been preparing since the preview days. As for production experience, I have not migrated a large codebase myself yet,so I am relying on the published numbers from teams like Slack and Canva and those came from real production pipelines.
That makes sense. Waiting for the stable compiler API before migrating sounds like the safest approach. It will be interesting to see how quickly the major tooling projects adopt it after 7.1. Thanks for the detailed explanation and for clarifying where the performance numbers are coming from. I will definitely keep an eye on real world migration reports.
Same here, the real world migration reports will be the interesting part. Thanks for the good questions!
Absolutely. Benchmarks are useful, but real world projects usually reveal the edge cases. Looking forward to seeing how the first large migrations go. Thanks again, nice reading!
Thanks!
The "first box and last box did not change, only the middle one" framing is the clearest way to say what actually shipped. Most people read the headline as "TypeScript is faster" when the real story is "the TypeScript toolchain is faster." Your editor experience, your CI pipeline, your type-check-on-save — all of those benefit from a Go binary that does not need JIT warmup or garbage collection pressure on every run.
The interesting question this raises is whether Go becomes the default language for rewriting developer toolchains. esbuild started the trend (also Go), Biome went Rust, and now tsc is Go. The pattern is the same: a hot-path tool that was written in the same language as its users gets rewritten in a language that compiles ahead of time and starts fast. The users still write TypeScript, JavaScript, or whatever — the tool itself becomes invisible infrastructure.
One thing worth watching: the native binary replaces tsserver, which means editor integrations that depend on the tsserver protocol need to either adapt or wrap. VS Code ships with TypeScript so Microsoft controls that path, but third-party editors and language servers may need a compatibility shim. The 10x speedup only matters if the integration layer does not add back latency through IPC overhead.
Thanks, glad the framing landed. On the editor side there is actually good news: the new language service speaks the standard Language Server Protocol, and the old tsserver protocol was the custom one that needed wrappers. So third party editors like Neovim or Zed should have an easier time now, not harder. The Go vs Rust question is fun to watch too, though here Go won mainly because it let the team port the old compiler almost function for function instead of rewriting it.
The line I keep coming back to is
skipLibCheck: true. Half the tsconfigs I have inherited carry it, and nobody in the room remembers it was a performance concession. It just quietly became "how we configure TypeScript" while silently giving up real type checking at library boundaries.That is the part of this release worth watching: the workarounds do not remove themselves. A 10x compiler means teams can afford correctness they had already stopped paying for, but only if someone goes back through the config and asks which flags were beliefs and which were just the clock. Same story with the project references people split repos over. Fast enough changes what is reasonable, and reasonable is where the cleanup has to happen deliberately.
I really like the idea of treating upgrades as a chance to revisit old compromises. Sometimes a config option survives long after the original problem is gone, simply because nobody wants to touch something that works. Faster tooling changes that balance and gives us a good reason to clean things up.
True, and the nobody wants to touch it fear is real. A ten second full check makes that experiment cheap enough that fear stops being a good reason.
You are right that the workarounds do not remove themselves and I would add that the upgrade PR is the natural moment to do the cleanup, since that is the one time the whole team is actually looking at the tsconfig anyway. A cheap experiment is to flip skipLibCheck off right after upgrading and just measure because the answer used to be minutes and now it is often seconds, and that turns a philosophical debate into a number. Also I am absolutely stealing the line about flags that were beliefs and flags that were just the clock.
Take the line, it is yours.
One practical note for when someone does flip it off after the upgrade: expect the first run to go red, and expect most of it to be duplicate or mismatched @types in the tree rather than real bugs in your code. That is worth knowing in advance because a red wall on the upgrade PR is exactly what makes a team put the flag back and never revisit it. The move that survives contact: run the strict version as a separate non-blocking CI job for a week. You get the number and the error list without holding anyone's PR hostage, and then the decision to fix or keep is made with evidence instead of at 6pm on a Friday.
The upgrade PR being the one moment everyone is already looking at the tsconfig is a very good point. It is also the only moment the diff has an audience.
The non blocking shadow job is the right move and it generalizes to any tightening, new strict flags, new lint rules, anything where the first run goes red for reasons that are mostly noise. A week of data turns put the flag back from a reflex into a decision made with evidence. And the only moment the diff has an audience might be an even better line than the first one, so now I owe you two.
The compiler rewrite is probably just the first step. If TypeScript is no longer limited by JavaScript runtime performance, we might finally see features that were previously considered too expensive for large codebases. Better type analysis could become the default instead of an opt in.
and I think, the biggest win might not be faster builds but what happens inside editors. If type checking becomes cheap enough, IDEs can provide much richer refactoring and diagnostics without developers noticing any latency.
I think you are onto something, especially with the editor angle. Project wide diagnostics are a good example, today most editors only fully check the files you have open, because checking the whole project on every keystroke was unthinkable and a parallel native checker makes it thinkable. The same logic applies to defaults, since things like skipLibCheck exist purely because checking node_modules was too expensive, and that tradeoff just changed. Curious which one you would want first if the type checking budget is suddenly ten times bigger.
This is so cool! Kudos to Microsoft for making the effort to rewrite the transpiler from the ground up, in Go. (I would have expected Rust. But those rascals picked Go! Tricksy Hobbitses.)
I haven't used TypeScript since 0.8. So it's been a long while. But I enjoyed the language, loved that it provided ES6 capability for ES3 and ES5 targets. That particular feature of TypeScript is entirely irrelevant these days. But at the time (~2012) it was the bee's knees.
We wrote a considerably large project in TypeScript, which I would have been less confident in had we written it in straight up JavaScript.
Thanks! Funny thing about the Rust expectation: Go won precisely because this was a port, not a ground up rewrite. The team translated the old compiler almost function for function to keep its behavior identical, and idiomatic Go could mirror that shape while Rust would have forced a redesign. Also, coming back after last touching 0.8 you picked a good decade to check in, the ES6 for ES5 party ended but the compiler got a jet engine.
It's kind of refreshing when a major release focuses on tooling instead of adding more syntax to memorize.
Agreed, sometimes the best feature is getting your time back instead of a new thing to learn.
The skipLibCheck thread nails the real story. One thing I'd add from a NestJS shop: we already moved our builds to SWC for the speed, and SWC transpiles without type-checking at all, so tsc quietly became a pure correctness gate running on its own. Once your build tool stops type-checking, a slow tsc is exactly what pushes a team to check less. A 10x tsc makes "type-check everything on every push" affordable again, right when the build pipeline has stopped doing it for you.
This is a great data point, because the SWC path is where a lot of teams already live. The ecosystem quietly split transpiling and type checking into separate jobs, esbuild and SWC took the first one, and the checking half was left slow and easy to skip. TypeScript 7 fixes exactly that half, so the correctness gate gets cheap again right when it became the only gate you have.
That's the exact framing I was missing. Once transpile and type-check split into separate jobs, the check became the optional half, and optional in CI means skipped under deadline. We watched it happen: builds moved to SWC, and "type-check everything on every push" quietly turned into "type-check on the branches someone remembers." A 10x tsc doesn't just make it faster, it makes it affordable to put the gate back where it belongs, blocking the merge. Speed is what makes the discipline stick.
Speed is what makes the discipline stick is the whole story in one line. Thanks for bringing the production view, this thread turned out better than the section it started from.
@nazar-boyko The LSP switch is the part most people are missing -- "the new language service speaks the standard Language Server Protocol" should be in every summary, because it changes who can plausibly build a TS editor. With the old custom tsserver protocol, the wrapper cost was real and the implementation list was short. With LSP being native, Neovim/Zed/Helix are not playing catch-up anymore, they are first-class. That moves the editor choice for TS work closer to "use whatever you like" instead of "use VS Code or suffer."
The "Go won because it let them port function-for-function" line is the underrated engineering observation. A Rust port would have forced a rewrite, and a rewrite changes the type checker, and a changed type checker means regression in millions of codebases. The whole reason the upgrade is low-risk is that the team chose the language that let them preserve the existing behavior, not the language that let them express a new architecture. Most readers will frame Go as a performance decision; the real framing is that Go was the lowest-cost way to keep the contract identical.
The use whatever you like framing is exactly it, and I think it will be one of the quiet legacies of this release. And your reframing of Go is sharper than mine: performance was the goal of the project but the language choice itself was a compatibility decision and the speed came from going native and parallel regardless of which language won. Two different decisions that most coverage collapses into one.
Nazar,
Right — "compatibility decision that happened to also deliver performance" is the cleaner read. Two separate decisions that most coverage collapses into one. The LSP standardization point is the one with the longest tail: third-party editors that previously needed a custom tsserver bridge can now speak standard protocol. That matters more in the long run than the benchmark numbers.
Agreed, and that would make a fitting epitaph for this release: the benchmarks got the headlines, the protocol change gets the decade. Thanks for one of the best threads under this post.
We actually noticed something similar on our team. After upgrading, one of us thought the TypeScript check hadn't even run because it finished so quickly. We ended up checking the logs just to make sure everything was working. The funny part is that nothing changed from a developer's perspective. Same code, same types, same errors. We just spent less time waiting. Those kinds of improvements don't usually make flashy demos, but when you're working in a large codebase every day, they make a bigger difference than most new language features.
That is my favorite kind of upgrade story, when the tool gets so fast you assume it must be broken. It says a lot about how much waiting we had all normalized that a passing check now looks suspicious enough to go read the logs. Thanks for sharing a real world data point, this is exactly the boring but huge kind of impact I was trying to describe.
Exactly. It's funny how quickly "waiting" became part of our workflow without anyone questioning it. Now the fast feedback almost feels wrong.
Great breakdown. I like that you focused on what actually changes versus what is just marketing hype. Do you think the biggest challenge for most teams will be updating the surrounding tooling rather than migrating their TypeScript code itself?
Thanks Jeremy! That is exactly how I see it. The compiler was built to match TypeScript 6 behavior, so your own code mostly just compiles faster with no migration to speak of. The real friction is in tools that consume the compiler as a library,like type aware lint rules and template checking in Vue or Svelte and that gap should close once the stable API lands in 7.1.
Thanks for the clarification. That makes a lot of sense. Do you think most popular tools will be ready soon after 7.1, or will it take a few release cycles before the ecosystem catches up?
Good question! My bet is the major tools move fast,since teams like typescript eslint and the framework language tools have been tracking the native port since the preview days and are mostly waiting on the stable API. The long tail is a different story, and smaller plugins that reach into compiler internals will probably need a few cycles. In practice I think most teams will be able to drop the dual setup within a release or two after 7.1.
That seems like a realistic timeline. It will be interesting to see how quickly the smaller plugins catch up. Thanks for sharing your thoughts.
Your explanation of Go's shared-memory multithreading vs. JS worker threads is probably the clearest breakdown of TS 7 I've read so far! 🎯
Also, pointing out why the team chose Go over Rust (to mirror the codebase shape rather than rewriting memory logic from scratch) was such a great engineering insight.
Don't worry about the AI usage for English—the article flows naturally and the technical depth is top-tier. Thanks for clearing up the myths around Node's type stripping vs Native TSC! 🚀
Thank you, that is very kind! Especially the note about the language, it means a lot. The Go over Rust decision is my favorite detail of the whole story too, because the boring choice is exactly what made the compatibility promise possible. Glad the type stripping section helped clear the myths up!
You nailed it! Sometimes the 'boring choice' in software architecture takes the most engineering discipline. Loved the article, and looking forward to reading more of your deep dives in the future! 🙌🚀
Great breakdown 👏. One additional wrinkle I see in mature monorepos is that TypeScript 7's performance story and its migration story don't necessarily have the same boundaries.
The native compiler gains are absolutely compelling. But the interesting question for an existing system is: how much of your actual developer feedback loop is dominated by TypeScript work, and what has to move before you can benefit from those gains?
The missing programmatic compiler API in 7.0 is a good example. Some tooling that depends on it still needs TS6 alongside TS7, and that constraint propagates upward. I recently looked at a mature Nx monorepo several major versions behind current Nx; the current Nx compatibility matrix lists TypeScript 7 support starting with Nx 23.x.
So “upgrade TypeScript” can quickly become “upgrade Nx, compiler config and parts of the surrounding toolchain - then upgrade TypeScript.”
That's where the ROI gets interesting. A dramatically faster compiler can make the developer's workshop much faster without changing the speed of the product leaving the workshop. And in a long-lived codebase, upgrading the workshop may still be absolutely worth it - but only after you understand what else is bolted to the same floor.
For me, that's the broader modernization question: not just “can we upgrade this dependency?”, but “what migration surface comes with the benefit?”
This is the sharpest version of the point, the performance boundary and the migration boundary aren't the same line. The missing programmatic API is the clearest example: anything downstream that hooks into the compiler pins you to TS6 until it catches up, so "upgrade TypeScript" quietly becomes "upgrade everything bolted to the compiler first." The faster workshop is worth it, but you're right that you have to map what's on the floor before you get to enjoy it.
This is one of the clearest explanations I've seen. The phrase "TypeScript went native" is catchy, but it has led many people to believe the language itself changed. In reality, the execution model is the same—TypeScript is still transpiled to JavaScript before it runs. The major change is that the compiler and language service are now native binaries, which means faster type-checking, lower memory usage, and a much more responsive developer experience, especially on large codebases. Faster tooling without changing how developers write or deploy TypeScript is a solid win.
Thanks Saleha, that is a tidy summary of the whole piece in one paragraph.
I think one of the biggest changes here is not just the compiler speed, but the opportunity it creates for teams to question old decisions.
A lot of TypeScript configuration is basically a snapshot of past limitations. The interesting part is that faster tooling does not automatically remove those compromises, but it finally makes revisiting them affordable.
Maybe future upgrade guides should include a "what can we delete now?" section, not only "what can we enable?" because removing old complexity is often the biggest improvement.
The what can we delete now section is a great idea and I suspect it would be the most read part of any upgrade guide. Deletion really is the underrated half of upgrades: things like tsbuildinfo choreography and project references drawn for speed instead of domain shape only ever existed because the clock was slow. And you are right that none of it disappears on its own, so turning the cleanup into an explicit checklist item instead of a someday task is exactly the right framing.
Hi, is there any data on how many regression tests passed? Are there any edge cases where version 7.0 differs from version 6.0? What is the test coverage for the Go port itself? A brief comparison of the test statistics would be helpful.
Good questions. The Go port runs against the same conformance suite and baselines the old compiler accumulated over a decade and the team also fuzz tested the two compilers against each other to catch divergence. The last public checkpoint from December 2025 reported only 74 remaining test case discrepancies,all tied to known unfinished work or intentional changes. The intentional differences in 7.0 are mostly config level, like strict on by default and dropped ES5 and AMD output, not type system semantics and declaration file output is reported to be identical between the two. I have not seen a published coverage number for the Go codebase itself but the baseline suite is public in the typescript-go repo if you want to dig into the details.
Great breakdown. I like how you clarified that the language itself hasn't changed, only the compiler behind it. The performance improvements sound impressive, but it's good to know the focus is on faster tooling rather than changing how TypeScript code actually runs.
The "port, not a rewrite" decision is the most underrated part of this whole story, and the article calls it correctly. Choosing Go specifically because it could mirror the existing pointer-heavy, shared-mutable-state shape of the JS compiler, rather than a "better" language like Rust that would've forced a redesign, is what let them prove behavioral identity instead of just hoping for it. That's the difference between a compiler upgrade and a compatibility gamble.
The architectural side-effects point is the sharper long-term observation though. skipLibCheck, project references chosen for build performance rather than domain boundaries, a decade of "coping mechanisms" quietly became load-bearing architecture, and nobody had to name them as workarounds because the slow compiler made them feel like defaults. Watching which of those quietly get abandoned over the next year or two is a more interesting signal than the 10x number itself.
Good call separating this clearly from Node's type stripping too, conflating "faster type-checking" with "no type-checking needed" is an easy mistake, and the two are actually solving opposite problems that happen to compose well together.
Thanks! I fully agree that the disappearance curve is the better signal. The 10x is a number Microsoft can publish in a day while watching skipLibCheck and speed driven project references quietly fade from tsconfigs across GitHub will take a year or two and will tell us whether the pressure actually eased.That would make a great follow up post once the data exists.
This explanation clears up a common misunderstanding. I also noticed many people assumed TypeScript files would now run directly without compilation, but the real change is the compiler itself.
Moving the compiler to a native implementation can make a huge difference, especially for large codebases where every second saved in type checking and builds improves the developer experience.
Thanks Vikash. That misunderstanding was the whole reason I wrote this one, the headline travels faster than the details. And agreed on scale: the bigger the codebase, the more the speedup compounds because the check runs on every save, every push and every PR, not just once.
Really enjoyed the article! I like that you focused on what actually changes and what doesn't. There's been so much hype around TypeScript 7 that it's easy to think it's a completely new language, while it's really a new compiler under the hood.
One thing I'd probably add is that the biggest impact may not be on application developers but on people building tools around TypeScript. Most apps will likely upgrade without much drama, but projects using the Compiler API, custom transformers, AST tooling, or code generators might have a bit more work to do.
It also feels like TS7 is more about laying the groundwork than shipping new language features. Faster builds are great but the new architecture could make it much easier for the TypeScript team to keep improving performance and tooling in future releases.
Overall, great read. Thanks for putting together such a balanced explanation!
Thanks! You are right about who carries the real migration weight. App developers mostly get a faster tsc for free while anyone consuming the compiler as a library, transformers, AST tooling, code generators, is waiting on the stable API in 7.1 and may need real rework, since the compiler is no longer a JavaScript library living in the same process as their code. I agree on the groundwork framing too: a parallel native core raises the ceiling for what the team can ship next and that may matter more long term than the 10x itself.
Great breakdown of the TypeScript 7 changes. The shift toward a native implementation is a major technical milestone, but understanding what actually changes for developers versus what stays the same is the most valuable part. Thanks for separating the hype from the practical impact! 🚀
Thanks! The hype/practical split was the whole reason I wrote it - "native" got read everywhere as "no build step," which is exactly what it isn't.
Nice job! I'll have to check it out 😀
Me too 😊 I haven't tested it yet. 😁 I've only updated one project, and to be honest, I don't see a difference yet. But I know there are some!
Spot-on distinction between "running TS natively" vs "type-checking natively."
The point about multithreading is what most people miss when discussing the Go rewrite. Shifting off Node's single-threaded event loop so the compiler can traverse the type graph across multiple cores is where that massive 10x jump really comes from, far more than just AOT compilation alone.
Also appreciate pointing out the temporary asterisk around programmatic APIs (like typescript-eslint needing TS 6 until 7.1). Great breakdown of what actually shifted under the hood!
The breakdown contrasting Node's type stripping vs tsc's native validation is super clear and necessary right now.
Shaving CI type-check steps down from minutes to seconds without touching runtime JavaScript output is the ideal upgrade path. Fewer language server crashes in VS Code and faster cold starts make a massive daily quality-of-life difference. Fantastic overview!
Thanks! The multithreading point deserves even more attention than I gave it because the two effects compound with the checkers flag raised to 8 workers the VS Code benchmark goes from 11.9x to 16.7x over TypeScript 6. Native code made the work faster but parallelism is what keeps scaling it.
the "only the middle changed" framing is the clearest way i've seen this explained. people keep conflating "native TypeScript" with runtime execution, and the first/last box description cuts right through that.
the Go port also has real implications for language server latency. tsserver on a large monorepo can take several seconds to catch up after a file edit — if the native compiler lands similar gains there as it does on cold builds, that's the change most devs will actually feel day to day, not CI times.
curious whether the incremental checker (the thing keeping your editor's squiggles live) is also Go in 7.0, or if that's still the JS layer?
Good question, and the answer is yes, the language service in 7.0 is part of the same native Go binary, not a JS layer on top. That is where the editor numbers in the release come from: project load on the VS Code codebase went from 9.6 seconds to 1.2, and opening a file with errors dropped from 17.5 seconds to under 1.3, and both of those are language service measurements, not cold builds. The service was also rebuilt to speak LSP natively instead of the old custom tsserver protocol, and Microsoft reports far fewer failing commands and crashes than the 6.0 server. So the squiggle catch up lag you describe on a big monorepo is exactly the part that changed.
Great breakdown! I'm curious whether teams will start revisiting some of the performance trade-offs they've made over the years.
Do you think features like project references and aggressive compiler optimizations will become less important now, or will they still be standard practice even with a much faster compiler?
Good question. I think the build-performance reason for project references fades a lot, but that was only ever half of why people reached for them. The other half, enforcing boundaries between packages, doesn't get any less useful because the compiler got fast. So I'd expect them to stick around, just less as a performance workaround and more as a deliberate architecture choice.
The 'your build step isn't going anywhere' framing is the part most hot takes missed. Curious how tsserver feels with the Go port on huge codebases — if the red squiggles get noticeably faster, that's the real daily-life win.
That's the win I'd point to first, honestly. The tsc batch number is nice for CI but tsserver is where most people will actually feel it. Hover, autocomplete and the squiggles catching up on a big repo instead of trailing a few seconds behind your cursor. The per-keystroke latency is the thing you notice every minute.
Nice work! Will try to update my projects to check out the speed 😊
Thanks! I'm currently updating 😃 Will see the result soon.
Awesome post! 🔥 Loved how you explained everything so simply. Super helpful! 🙌
nice writeup!
Wow this was very informing thank you
Glad it helped, thanks for reading!
Excellent article! This is one of the clearest explanations I've read about what actually changed in TypeScript 7. I've seen similar discussions on CodeCan.net, but your breakdown of the native compiler, Proxy concepts, and migration path makes everything much easier to understand. Thanks for sharing!
Great breakdown of the TS7 changes! It's wild to see those 10x speedups just by shifting the compiler to Go. High performance is a game-changer for creative workflows too, much like how Kirkify uses AI to rapidly generate Kirkified memes and video content.