Microsoft has previewed a port of the TypeScript compiler to native code with huge performance gains, including a new language service that will speed project load and enable new AI features within Visual Studio Code (VS Code).

The port was introduced by technical fellow Anders Hejlsberg, creator of both TypeScript and C#. TypeScript has failed to scale to the largest projects, he said, and customers have reported out of memory situations with large projects. “We’ve reached the limit of what we can squeeze out of JavaScript,” he said in an accompanying video presentation.

JavaScript has a just-in-time (JIT) compiler, but Hejlsberg said limitations include the overhead of JIT compilation, lack of shared memory concurrency, and lack of support for optimizations such as inline allocation of structures.

The project, codenamed Corsa, is a port of the TypeScript code that forms the existing TypeScript compiler. Since it is a port rather than a rewrite, Hejlsberg believes the behavior will be the same, even in edge cases, so that it will be a “plug and play replacement.” There will also be a new inter-process API enabling other languages to talk to the compiler.

The implications for developers are substantial. Microsoft itself has a large TypeScript project in the shape of VS Code, which is around 1.5 million lines of code. Hejlsberg showed how the new compiler reduces compile time from just over a minute to under 6 seconds. 

There will be further benefit though for VS Code users, since features such as squiggly line errors and hover-over help depend on parsing the entire project while it loads, so the new native compiler will greatly speed project loading and enable new AI features such as type-checking the output from LLM (Large Language Models) immediately.

A side-effect of the project is that the TypeScript language service will now be based on the Language Service Protocol (LSP), a standard which did not exist when the existing service was developed. This does mean that unlike the compiler, the new language service will have different behavior and Hejlsberg said the team is investigating areas such as refactoring to consider how this should work.

The project is open source on GitHub under the Apache 2.0 license.

One of the first hot discussions on GitHub is the question of why Go was used, rather than C#, especially considering Hejlsberg’s involvement and the fact C# supports AOT (ahead of time) compilation.

In his presentation, Hejlsberg said that when the project began six months ago, a lot of time was spent prototyping in “all the various languages.” Go proved the best fit, he said, with “optimized native code for all platforms, great control over data layout, ability to have cyclic data structures and so forth,” as well as “automatic memory management with a garbage collector, and great access to concurrency.”

Some developers reacted with disappointment. “This comes off as a bit of a vote of no confidence in C#, given that Anders is the original creator of C# and his team has now chosen not to use it,” said one.

Another said “things like this make me ashamed to even build my career on C# .NET … If they don’t use their own tools in their flagship products, I have no confidence in their tools.”

In an interview with Michigan TypeScript, Hejlsberg said that despite advances in AOT, “C# is bytecode-first”, is not on all platforms, “doesn’t have a decade of hardening” and “was not engineered that way.” 

Another factor is that C# is heavily object-oriented whereas Go “is functions and data structures,” making the TypeScript compiler port smoother.

Go was chosen as the lowest-level language available that still has garbage collection, he said.

While many shared disappointment that Microsoft has missed a possible opportunity to promote .NET’s capability, others said for example that “I really like the fact that the TS team decided to go with Go over C# … it shows their ability to put the needs of the community first.” Others suggested that Rust would have been a better choice.

Hejlsberg insisted though that the decision to use Go was driven by “specific technical requirements” and “it does not diminish our deep and ongoing investment in C# and .NET. A majority of Microsoft’s services and products rely heavily on C# and .NET.”  C#, he said, is ideal for “scenarios demanding rapid, maintainable, and scalable development.”

Microsoft has a long history of language diversity, and this is not the first time .NET developers have complained about the company’s choices. Windows is largely C/C++, following disappointments in the early development of Windows Vista, and desktop Office is another example.

Those outside the .NET community will be pleased that the team has made its decision on technical grounds, and this will be the biggest advance for TypeScript for many years, relieving a pain point for many teams working on large projects. 

When do we get native TypeScript? Hejlsberg expects a “fully functional replacement command line compiler” before the end of the year. It will be released as TypeScript 7.0. The existing JavaScript-based compiler will continue to be maintained and will become TypeScript 6.0. Both streams will be maintained until TypeScript 7 and higher “reaches sufficient maturity and adoption.”