In March, a significant announcement was made: the official plan to port TypeScript to Go, claiming a tenfold performance improvement.
From the perspective of a language server developer, this project holds substantial implications, particularly in enhancing AI-assisted programming.
TypeScript Users: Smoother Programming Experience and Build Speed
The community has debated the choice of language for this transition. Some argue Microsoft should have opted for its own C#, while others suggest Rust, aligning more closely with the modern frontend ecosystem. The official decision considered the costs of porting and maintenance. Regardless of the specific choice, any native language would outperform JavaScript in terms of performance.
The improvement in tsc compilation performance is evident. When building web frontend applications or Node.js applications, TypeScript needs to be compiled into JavaScript. This was the first point mentioned in the official blog post: compiling the VS Code source code saw a 10.4x speed increase.
Additionally, when coding in editors like VS Code or Cursor, TypeScript provides language services based on the Language Server Protocol (LSP), specifically through a language server known as tsserver.
Each time you type, features like code completion, go-to-definition, and error prompts require tsserver to compile and analyze, providing real-time feedback.
Due to the performance limitations of JavaScript as a dynamic language, language servers face performance bottlenecks in large applications. This is why code completion can sometimes be slow. By leveraging a native language and TypeScript’s excellent architecture and design, this issue can be significantly improved.
Language servers aim for a smooth, natural, and intuitive product experience, where performance enhancements play a crucial role.
Standardizing TypeScript to LSP
Both TypeScript and LSP are Microsoft technologies. In fact, as a language server, tsserver hasn’t strictly adhered to LSP. This is because tsserver predates LSP, which was inspired by tsserver: separating the editor’s UI process and providing intelligent programming services in an independent process.
However, the official statement mentions the desire to achieve LSP compatibility through this porting effort. This means that the future tsserver will be a standard LSP language server.
The lack of LSP compatibility has been a shortcoming of TypeScript, making it challenging to leverage LSP’s cross-client (code editor) advantages.
Moreover, I believe that once tsserver is LSP-compatible, it will play a significant role in AI-assisted programming.
Enhancing AI-Assisted Programming
Take GitHub Copilot as an example to understand the current (as of May 2025) functionalities of AI-assisted programming:
-
Inline code completion
-
Chat/editing
-
Agent
Inline completion was the first feature to impress users. Essentially, it uses large language models (LLMs) to generate code suggestions. The core lies in constructing prompts that enable the LLM to generate the desired completions.
Copilot has made significant efforts to make prompts more precise. Precision involves aligning with the semantics of the code the user is typing. For example, collecting code near the cursor, referenced dependencies, opened files, relevant function signatures, comments, and other information to extract the most effective data for prompt generation.
I have an idea: language servers are particularly adept at providing such semantic information for prompt builders.
Collecting Comprehensive Semantic Information
Due to token limits, performance constraints, and other factors, Copilot finds it challenging to fully analyze large local applications (build local workspace index). Even with remote indexes, there are various limitations, such as the need to upload to GitHub.
Language servers, like compilers, need to compile projects and naturally parse the entire project’s semantic information to provide intelligent programming services.
Of course, parsing the entire project doesn’t mean compiling every file entirely. For instance, a file can be precompiled to obtain exported signature information (variable types, function signatures, etc.), and then fully compiled on-demand (e.g., when the user opens the file).
Handling User Interactions
A significant difference between language servers and compilers is their ability to handle continuous user coding. With incremental update technology, language servers can compile on-demand, computing only changed data and efficiently building semantic information dynamically to ensure timely updates. For example, tsserver supports incremental compilation.
A simple example: when a user deletes a line within a function, the function’s signature remains unchanged, so only the internal semantic information of the function needs updating.
This capability is crucial for Copilot: as the user codes, the context in the prompt must be updated promptly.
Function Calling and MCP Support
Beyond inline completion, the Agent mode has become a recent hotspot. With function calling, LLMs can more accurately obtain context information.
For example, VS Code includes a Find Usages tool (tool, function calling, etc.), allowing the LLM to locate a symbol’s definition, references, and other positions.
This sounds familiar, doesn’t it? It’s essentially LSP’s go-to-definition (textDocument/definition) and find references (textDocument/reference).
The language server’s job is to serve the client, continuously providing semantic queries and other functions as the user codes, thereby enabling intelligent programming capabilities. Packaging these capabilities as function calls for the LLM to query semantic information is a natural progression.
In fact, the community has already made some attempts in this direction. For example, mcp-language-server uses MCP to standardize communication between language servers and LLMs, allowing language servers to become MCP servers.
Besides using MCP’s general approach, there’s also a lightweight method within VS Code to provide function calling capabilities. This involves VS Code plugins implementing them directly, with plugins describing available tools through configuration files (JSON).
However, considering tsserver’s ambition to be LSP-compatible, I believe the official approach will lean towards implementing the MCP server method, enabling more editors to utilize this capability, not just VS Code. Of course, as a Microsoft product, VS Code will still be the primary focus for adaptation.
Both MCP and the Go port are still in very early stages. I’m very optimistic about this project. I believe that by 2026, with native porting and AI integration, the best way to write TypeScript will be using VS Code + GitHub Copilot, not Cursor, and certainly not WebStorm.
Other Aspects
Two additional points are worth mentioning, although the overall project is still in its early stages, and future changes are possible:
Potential for WebAssembly (WASM)
The TypeScript compiler is essentially a Node.js application, meaning it can’t run in the browser. This limitation affects applications like browser-based playgrounds and online preview compilations. However, after porting to Go, it will support WASM, allowing TypeScript to run in the browser and explore new possibilities.
For Downstream
tsserver has a plugin system that allows third-party developers to write Node.js code to extend TypeScript’s language services. For example, Vue, Astro, and Svelte language servers utilize this system to write TypeScript code in files beyond .ts. This requires using the plugin system to provide language services for TypeScript code in their files.
How these existing Node.js plugins will interact with the natively built tsserver is a concern. However, considering the official statement that the Node.js version of tsserver will coexist with the Go version for the long term, this may not be an insurmountable issue.
The post is authorized to translate and republish by imbAnt, original post link is at https://imbant.github.io/blog/2025/05/07/ts-go/
