https://devblogs.microsoft.com/typescript/typescript-native-port/ Skip to main content [RE1Mu3b] Microsoft Dev Blogs Dev Blogs Dev Blogs * Home * Developer + Microsoft for Developers + Visual Studio + Visual Studio Code + Develop from the cloud + All things Azure + Xcode + DevOps + Windows Developer + Developer support + ISE Developer + Engineering@Microsoft + Azure SDK + Command Line + Perf and Diagnostics + React Native * Technology + AutoGen + DirectX + OpenAPI + Semantic Kernel + SurfaceDuo + Windows AI Platform * Languages + C++ + C# + F# + TypeScript + PowerShell Community + PowerShell Team + Python + JavaScript + Java + Java Blog in Chinese + Go * .NET + All .NET posts + .NET Aspire + .NET MAUI + AI + ASP.NET Core + Blazor + Entity Framework + Servicing + .NET Blog in Chinese * Platform Development + #ifdef Windows + Azure Government + Azure VM Runtime Team + Bing Dev Center + Microsoft Edge Dev + Microsoft Azure + Microsoft 365 Developer + Microsoft Entra Identity Developer Blog + Old New Thing + Power Platform + Windows MIDI and Music dev * Data Development + Azure Cosmos DB + Azure Data Studio + Azure SQL + OData + Revolutions R + SQL Server Data Tools + Unified Data Model (IDEAs) * More [ ] Search Search * No results Cancel * Dev Blogs * TypeScript * A 10x Faster TypeScript March 11th, 2025 A 10x Faster TypeScript Anders Hejlsberg Anders Hejlsberg Show more Today I'm excited to announce the next steps we're taking to radically improve TypeScript performance. The core value proposition of TypeScript is an excellent developer experience. As your codebase grows, so does the value of TypeScript itself, but in many cases TypeScript has not been able to scale up to the very largest codebases. Developers working in large projects can experience long load and check times, and have to choose between reasonable editor startup time or getting a complete view of their source code. We know developers love when they can rename variables with confidence, find all references to a particular function, easily navigate their codebase, and do all of those things without delay. New experiences powered by AI benefit from large windows of semantic information that need to be available with tighter latency constraints. We also want fast command-line builds to validate that your entire codebase is in good shape. To meet those goals, we've begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage. By porting the current codebase, we expect to be able to preview a native implementation of tsc capable of command-line typechecking by mid-2025, with a feature-complete solution for project builds and a language service by the end of the year. You can build and run the Go code from our new working repo, which is offered under the same license as the existing TypeScript codebase. Check the README for instructions on how to build and run tsc and the language server, and to see a summary of what's implemented so far. We'll be posting regular updates as new functionality becomes available for testing. How Much Faster? Our native implementation is already capable of loading many popular TypeScript projects, including the TypeScript compiler itself. Here are times to run tsc on some popular codebases on GitHub of varying sizes: Codebase Size (LOC) Current Native Speedup VS Code 1,505,000 77.8s 7.5s 10.4x Playwright 356,000 11.1s 1.1s 10.1x TypeORM 270,000 17.5s 1.3s 13.5x date-fns 104,000 6.5s 0.7s 9.5x tRPC (server + client) 18,000 5.5s 0.6s 9.1x rxjs (observable) 2,100 1.1s 0.1s 11.0x While we're not yet feature-complete, these numbers are representative of the order of magnitude performance improvement you'll see checking most codebases. We're incredibly excited about the opportunities that this massive speed boost creates. Features that once seemed out of reach are now within grasp. This native port will be able to provide instant, comprehensive error listings across an entire project, support more advanced refactorings, and enable deeper insights that were previously too expensive to compute. This new foundation goes beyond today's developer experience and will enable the next generation of AI tools to enhance development, powering new tools that will learn, adapt, and improve the coding experience. Editor Speed Most developer time is spent in editors, and it's where performance is most important. We want editors to load large projects quickly, and respond quickly in all situations. Modern editors like Visual Studio and Visual Studio Code have excellent performance as long as the underlying language services are also fast. With our native implementation, we'll be able to provide incredibly fast editor experiences. Again using the Visual Studio Code codebase as a benchmark, the current time to load the entire project in the editor on a fast computer is about 9.6 seconds. This drops down to about 1.2 seconds with the native language service, an 8x improvement in project load time in editor scenarios. What this translates to is a faster working experience from the time you open your editor to your first keystroke in any TypeScript codebase. We expect all projects to see this level of improvement in load time. Overall memory usage also appears to be roughly half of the current implementation, though we haven't actively investigated optimizing this yet and expect to realize further improvements. Editor responsiveness for all language service operations (including completion lists, quick info, go to definition, and find all references) will also see significant speed gains. We'll also be moving to the Language Server Protocol (LSP), a longstanding infrastructural work item to better align our implementation with other languages. Versioning Roadmap Our most recent TypeScript release was TypeScript 5.8, with TypeScript 5.9 coming soon. The JS-based codebase will continue development into the 6.x series, and TypeScript 6.0 will introduce some deprecations and breaking changes to align with the upcoming native codebase. When the native codebase has reached sufficient parity with the current TypeScript, we'll be releasing it as TypeScript 7.0. This is still in development and we'll be announcing stability and feature milestones as they occur. For the sake of clarity, we'll refer to them simply as TypeScript 6 (JS) and TypeScript 7 (native), since this will be the nomenclature for the foreseeable future. You may also see us refer to "Strada" (the original TypeScript codename) and "Corsa" (the codename for this effort) in internal discussions or code comments. While some projects may be able to switch to TypeScript 7 upon release, others may depend on certain API features, legacy configurations, or other constraints that necessitate using TypeScript 6. Recognizing TypeScript's critical role in the JS development ecosystem, we'll still be maintaining the JS codebase in the 6.x line until TypeScript 7+ reaches sufficient maturity and adoption. Our long-term goal is to keep these versions as closely aligned as possible so that you can upgrade to TypeScript 7 as soon as it meets your requirements, or fall back to TypeScript 6 if necessary. Next Steps In the coming months we'll be sharing more about this exciting effort, including deeper looks into performance, a new compiler API, LSP, and more. We've written up some FAQs on the GitHub repo to address some questions we expect you might have. We also invite you to join us for an AMA at the TypeScript Community Discord at 10 AM PDT | 5 PM UTC on March 13th. A 10x performance improvement represents a massive leap in the TypeScript and JavaScript development experience, so we hope you are as enthusiastic as we are for this effort! 53 37 64 * [facebook] Share on Facebook * Share on Twitter * [linkedin] Share on Linkedin Category TypeScript Author Anders Hejlsberg Anders Hejlsberg Microsoft Technical Fellow and lead architect of TypeScript. Original designer of C#, Delphi, and Turbo Pascal. 37 comments Join the discussion. Leave a commentCancel reply Sign in [ ] [Reply] [Cancel] Code of Conduct Sort by : Newest Newest Popular Oldest * [png] David Hanson March 11, 2025 0 Collapse this comment Copy link I'm not sure maybe I missed it. But this needs to be delivered in wasm otherwise it'll be a huge pain for onboarding in the enterprise. Log in to Vote or Reply * [png] Zura For Reg 3 hours ago 1 Collapse this comment Copy link If you have concluded that native binary is the way to go, why should we be using a JavaScript garbage as end users? People should stop using web tech for applications. Log in to Vote or Reply * [png] Michael J. Ryan (tracker1) 4 hours ago * Edited 1 Collapse this comment Copy link This isn't to bash Go. Given the effort that many open-source projects have put into processing TS with Rust, I'm not sure why they weren't used as a baseline for this. I know that MS tends to go into a lot of NIH syndrome. It just seems like a lot of duplicated effort here. Log in to Vote or Reply + [png] Daniel Whitney March 11, 2025 1 Collapse this comment Copy link Watch the technical breakdown, this isn't a rewrite its a port. And go is a lot closer to js than rust being that is has a garbage collector. Also the point is already invalid as esbuild exists. Log in to Vote or Reply * [png] Forrest Allison 4 hours ago 1 Collapse this comment Copy link I constantly feel that Microsoft has lost the ball with typescript and maybe never really had it. If they're building a new compiler, here is what they need to do in my opinion. Every one of these ideas has to do with treating typescript as a primary language and not a linting syntax for JS. * Support compiling and running typescript directly without JavaScript as an intermediary step. As we all know, there are major speed advantages to static languages, don't throw them away before runtime * Crystalize the language's expected syntax, eliminating the flexibility of early TS that has... Read more I constantly feel that Microsoft has lost the ball with typescript and maybe never really had it. If they're building a new compiler, here is what they need to do in my opinion. Every one of these ideas has to do with treating typescript as a primary language and not a linting syntax for JS. * Support compiling and running typescript directly without JavaScript as an intermediary step. As we all know, there are major speed advantages to static languages, don't throw them away before runtime * Crystalize the language's expected syntax, eliminating the flexibility of early TS that has mostly just become legacy, since everyone uses the same TSconfig settings now anyway. Standardize on esmodule imports. So many god damn limitations arise from supporting multiple import syntaxes. And get rid of or redesign TSconfig while you're there, it's a dumpster fire of misnamed legacy shit. * Support macros/compile time code to allow type reflection, type generation from other languages, etc, allowing libraries to natively extend the language and completely and forever eliminating all code-gen There. Do that. Microsoft. Read less Log in to Vote or Reply + [png] Wrick Savvi 3 hours ago 1 Collapse this comment Copy link Interesting, I am just from telling a friend this exact same thing. Skip JS altogether Log in to Vote or Reply o [png] Seifeddine Largat March 11, 2025 0 Collapse this comment Copy link same here ! glad to see that other people are discussing the same idea ! * [png] Adeel Ali 4 hours ago 1 Collapse this comment Copy link Awesome Can't wait for v7. Log in to Vote or Reply * [png] Muryel Cabral 4 hours ago 1 Collapse this comment Copy link This is incredible. If I stop to count how many years of my life I've wasted waiting for the build... lol Log in to Vote or Reply * [png] Lapointe, Jasmin 4 hours ago 4 Collapse this comment Copy link Amazing news! Will make large projects much more fun to navigate & work in! Log in to Vote or Reply * [png] Julian Coy 5 hours ago 2 Collapse this comment Copy link Well this is absolutely fantastic! I can't wait for 7.0. Log in to Vote or Reply * [png] Michael Ferris 5 hours ago 2 Collapse this comment Copy link I'm so excited about getting a real native compiler for TypeScript! Log in to Vote or Reply * [png] Color Kat 5 hours ago 1 Collapse this comment Copy link Is it possible to make backend on Typescript and translate it to Go or Binary executable file to run in production? It's my dream to make TS compilied Log in to Vote or Reply + [png] Will Shaw March 11, 2025 0 Collapse this comment Copy link I guess they could take the AST of your code and then use the Go compiler but at that point you might as well just be writing in Go because Go already has super fast compile times and cross-compilation. I cannot think of many benefits to TS over Go other than devs already knowing TS and them not willing to learn Go. Log in to Vote or Reply + [png] Kumar Gaurav 5 hours ago 0 Collapse this comment Copy link While not a completely compiled solution, but how about using Deno to get the executable ?? Does that help you ?? Log in to Vote or Reply + [png] saint4eva 5 hours ago 1 Collapse this comment Copy link It would be better to compile to wasm and run in production. Log in to Vote or Reply Load more comments Read next February 28, 2025 Announcing TypeScript 5.8 Daniel Rosenwasser Daniel Rosenwasser February 13, 2025 Announcing TypeScript 5.8 RC Daniel Rosenwasser Daniel Rosenwasser Stay informed Get notified when new posts are published. [ ] Subscribe By subscribing you agree to our Terms of Use and Privacy Follow this blog Stackoverflow Are you sure you wish to delete this comment? OK Cancel Sign in Theme Insert/edit link Close Enter the destination URL URL [ ] Link Text [ ] [ ] Open link in a new tab Or link to existing content Search [ ] No search term specified. Showing recent items. Search or use up and down arrow keys to select an item. Cancel [Add Link] Code Block x Paste your code snippet [ ] Ok Cancel Feedback What's new * Surface Pro * Surface Laptop * Surface Laptop Studio 2 * Surface Laptop Go 3 * Microsoft Copilot * AI in Windows * Explore Microsoft products * Windows 11 apps Microsoft Store * Account profile * Download Center * Microsoft Store support * Returns * Order tracking * Certified Refurbished * Microsoft Store Promise * Flexible Payments Education * Microsoft in education * Devices for education * Microsoft Teams for Education * Microsoft 365 Education * How to buy for your school * Educator training and development * Deals for students and parents * Azure for students Business * Microsoft Cloud * Microsoft Security * Dynamics 365 * Microsoft 365 * Microsoft Power Platform * Microsoft Teams * Microsoft 365 Copilot * Small Business Developer & IT * Azure * Microsoft Developer * Documentation * Microsoft Learn * Microsoft Tech Community * Azure Marketplace * AppSource * Visual Studio Company * Careers * About Microsoft * Company news * Privacy at Microsoft * Investors * Diversity and inclusion * Accessibility * Sustainability Your Privacy Choices Your Privacy Choices Consumer Health Privacy * Sitemap * Contact Microsoft * Privacy * Manage cookies * Terms of use * Trademarks * Safety & eco * Recycling * About our ads * (c) Microsoft 2025