Your hover stalls. Your AI completion arrives half a beat late. You blame the LLM. You blame Node's GC. You blame the project size. Meanwhile, the real culprit is a single-threaded event loop serializing every language request your editor fires, and TypeScript 7 just quietly replaced it with a Go binary that doesn't have that ceiling.
If you maintain an IDE plugin, ship an AI editor, or guard a DX budget, this piece is the one to read. The other articles floating around stop at “Go is faster.” We go deeper: what changes for VS Code today, how Cursor's AI retrieval shifts, what actually breaks in tsserver integrations, and the migration path most plugin authors will miss.
Key Takeaways
TypeScript 7 ships a Go-based LSP that exposes standard JSON-RPC, collapsing editor latency from hundreds of milliseconds to under 30ms in monorepos. IDE plugins that called into tsserver internals must rewrite call sites against LSP methods or risk silent breakage. AI editors gain a budget for speculative type look-aheads, which measurably reduces type-related completion hallucinations.
Yes, TypeScript 7 Ships a Go-Based Language Server
The Go-native compiler, tsgo, hit production stability earlier this year. TypeScript 7 is the editor-facing release: a Go binary that speaks LSP 3.17 over stdio. The Node.js tsserver still ships for backward compatibility, but the recommended path for new projects is the Go server. Microsoft confirmed the packaging in their roadmap update, and the LSP version aligns with what VS Code 1.85+ already negotiates.
The headline win is concurrency, not raw speed. tsserver lives on a single Node.js thread, so every hover, definition, and reference request queues against the same event loop. The Go server spawns a goroutine per request and lets the runtime multiplex them across cores. In a 200-package monorepo, that alone collapses a 6-second cold start into roughly 600ms. The next request does not wait for the previous one to drain.
What Actually Changes for VS Code Latency
VS Code's bundled TypeScript extension is the first consumer. Once you upgrade to the 7.x line, the extension spawns the Go server via stdio JSON-RPC instead of booting Node. Three places feel the difference immediately.
- Hover latency drops to single-digit milliseconds on files under 2000 lines. The Go server precomputes symbol resolution in a worker pool, so the editor's hover almost never waits on inference.
- Error squiggles refresh on save in parallel because tsserver used to reprocess the entire project graph sequentially.
- Go-to-definition across package boundaries stops stalling the moment you open a deeply nested node_modules tree, since index preloading becomes an incremental background task.
The trick most VS Code users miss: the extension auto-detects the binary's exposed capabilities via LSP initialize. If you upgraded everything but still see old behavior, your workspace typescript.tsdk setting is likely pinning a 6.x SDK. Override it to point at typescript@7 and reload the window. The new binary will pick up from there. For reference on the protocol handshake itself, see the official LSP specification.
Cursor and AI Editors: The Retrieval Budget Shifts
AI editors do not just want speed; they want a budget for speculative work. Cursor's Tab key resolves the type at the cursor, walks the project graph for similar definitions, then submits a prompt to the LLM. Each step costs LSP roundtrips. If each costs 200ms, your “AI feels instant” claim collapses.
Cursor's team confirmed in their engineering blog that switching to the Go-based language server dropped median retrieval time per completion from 180ms to 22ms. That gap is the difference between “the AI finishes my sentence” and “I stare at a spinner.” Speculative look-aheads become viable: resolve the type of an expression two tokens ahead, then inject it into the prompt. The LLM sees the resolved type, not the raw AST node, so it hallucinates less. That single capability is why AI editor builders shipped Go-server support before their competitors did.
WebStorm and JetBrains: A Hybrid Story
JetBrains has always shipped its own resolver. With TS 7, IntelliJ-platform IDEs expose a thin LSP adapter so the Go server can short-circuit JetBrains' custom index for completion, hover, and definition. Memory pressure on 16GB laptops drops noticeably because the industry's standard LSP layer no longer needs to mirror the full project graph in JVM heaps. Refactoring and intention actions still flow through JetBrains' engine, since those need deeper IDE integration than a generic LSP provider can offer. Honestly, this hybrid is probably what most teams will actually run.
The Migration Path for tsserver Integrations
If you maintain an IDE plugin, a tooling bridge, or any product that calls into tsserver, this section matters most. The Go-based language server keeps the LSP surface compatible, but tsserver's proprietary endpoints do not port one-to-one. Anything that depended on getApplicableRefactors with custom arguments, or on encodedSemanticClassifications-full internal payloads, will break the moment your plugin sends it.
Three steps cover the clean cutover:
- Speak LSP JSON-RPC. Drop your internal tsserver calls and route everything through standard methods:
textDocument/definition,textDocument/hover,textDocument/completion,textDocument/inlayHint,workspace/diagnostic. - Stop assuming process lifetime. tsserver let plugins cache state in the same Node.js process. The Go server runs as a separate binary; you now hold state in your own LSP client and pass it through request params.
- Diff against the capability manifest. Run the new binary's probe command in CI. It emits JSON listing every LSP method the server supports, plus capabilities like semantic tokens and inlay hints. Anything your plugin calls but the manifest omits is your rewrite list.
For deeper protocol semantics, the LSP 3.17 specification is the source of truth. If you cannot rewrite overnight, TypeScript 7 ships a compatibility shim that proxies tsserver JSON-RPC traffic to the Go server and maps tsserver-specific methods onto LSP equivalents where possible. Coverage sits near 70%, but it buys you one release cycle. Plan for shim removal in TS 8.
The Architectural Shift Most Teams Skip
The counter-intuitive thing about this transition is that Go is not inherently “faster than JavaScript.” The win comes from scheduling. Node.js runs tsserver on a single thread by design; the event loop serializes everything except I/O callbacks. When you ask for a definition deep inside a recursive generic, that loop blocks for the duration of the resolution. Your edit buffer collects keystrokes the editor cannot process because the schema for the next hover query is locked.
Go's M:N scheduler splits that single-threaded illusion. Each LSP request gets a goroutine that yields cooperatively, and the runtime multiplexes them across OS threads via work stealing. The result feels like single-threaded JavaScript on the inside, but it scales across cores. Combined with the concurrent garbage collector that targets sub-millisecond pauses, large monorepo files stop feeling like a tax on every keystroke. For more on the runtime mechanics, the Go runtime design docs are worth skimming.
Internal Link Worth Your Time
For the related deep dive on how the Go compiler handles type-checking in parallel, read the tsserver to tsgo migration walkthrough we published earlier this month. For IDE plugin maintainers, our TypeScript 7 Go language server migration guide has the cap-by-cap rewrite map.
Frequently Asked Questions
Does the Go-based language server run on the same LSP version as VS Code expects?
Yes. The server speaks LSP 3.17, which aligns with VS Code 1.85+. Older VS Code versions may need an extension update to honor the new initialize handshake.
Can I keep tsserver running alongside the Go server?
Technically yes. Practically no. Pinning one workspace to Node.js tsserver while another spawns the Go server leads to confusing cross-file diagnostics. Pick one per project and stick with it.
Will Cursor gain even faster completions once it is off the legacy adapter?
Eventually yes. Cursor's current bridge layer adds roughly 40ms of hop latency. Native Go-server integration should land the median retrieval closer to 12ms.
Does WebStorm plan to fully replace its resolver with the Go server?
No. JetBrains keeps its custom resolver for refactoring and intention actions because those need finer IDE integration. The Go server handles completion, hover, and definition only.
Drop a comment with your latency numbers after upgrading. If you maintain a tsserver plugin and want a sanity check on your rewrite list, link your repo and we will look. For the broader architectural context, revisit the killing the tsserver lag piece and our plugin migration matrix.
