Most developers today take it for granted that opening a Rust file in VS Code gives them autocomplete, go-to-definition, and inline errors, and that opening the same file in Neovim or Sublime Text gives them roughly the same experience. That was not always true, and it was not obvious it ever would be. What made it true is a fairly unglamorous piece of infrastructure called the Language Server Protocol, or LSP, and its success is worth examining precisely because so many earlier attempts at the same goal quietly failed.
The Problem Every Editor Solved Separately
Before LSP, rich language support, things like autocomplete, jump to definition, find references, and inline diagnostics, had to be built independently for every combination of editor and language. A team maintaining Python support needed a separate implementation for Vim, another for Emacs, another for Sublime Text, and another for whichever IDE came next. This is usually described as the M times N problem: M editors multiplied by N languages, each pairing requiring its own dedicated integration work. The framing comes up repeatedly in accounts of why LSP mattered, because the arithmetic gets ugly fast. A handful of popular editors and a modest list of languages already produces dozens of integrations that all need writing and maintaining separately, and every one of them tends to drift out of sync as the language evolves.
This was not a new realization. Eclipse, first released in the early 2000s, was itself partly an attempt to generalize IDE tooling through a plugin architecture, and it succeeded at making Eclipse extensible. What it did not solve was portability across editors, because an Eclipse plugin written in Java stayed an Eclipse plugin. A C or C++ front end built for Eclipse’s CDT project could not be reused inside a different tool without a substantial rewrite, since the intelligence and the editor integration were bound together in the same codebase. The same story played out with NetBeans, with various Vim and Emacs language daemons, and with early language-specific efforts like OmniSharp, which brought rich C# editing to several tools starting around 2014 but did so through its own bespoke protocol rather than a shared one.
What Changed With LSP
Microsoft’s own TypeScript team ran into this exact wall while building out editor support for VS Code, and, separately, so did the OmniSharp project. According to the Eclipse Foundation’s own account of the collaboration, after Microsoft had already built two separate language servers using two different ad hoc protocols, the team concluded that a shared, formal protocol made more sense than a third bespoke one. On June 27, 2016, Microsoft announced the Language Server Protocol jointly with Red Hat and Codenvy, and moved the specification to a public GitHub repository so any editor or language team could implement it independently.
The core idea is almost aggressively simple. A language server is a standalone process that understands one language deeply, its syntax, its type system, its way of resolving references, and it exposes that understanding over JSON-RPC, a lightweight remote procedure call format. An editor that wants to support that language does not need to embed any of that knowledge. It just needs to speak the same JSON-RPC protocol, sending notifications like “the user opened this file” or “the user changed these lines,” and receiving structured responses back describing diagnostics, completions, or a symbol’s definition location. Once an editor implements the client side of LSP once, it can talk to any language server that exists, past or future. Once a language team implements a server once, any LSP-aware editor can use it. The M times N problem collapses into an M plus N problem, because the number of integrations needed grows additively with new editors and languages instead of multiplying.
A Protocol Family, Not Just One Protocol
LSP did not stay alone for long. Microsoft followed the same pattern for debugging with the Debug Adapter Protocol, formalized around 2018, which separates a debugger’s UI from the specific runtime it is stepping through, the same way LSP separates an editor’s UI from the specific language it is analyzing. A related effort, the Language Server Index Format, arrived shortly after to standardize how static language data can be precomputed and indexed for code browsing at scale, rather than requiring a live server for every query. None of these are single companies solving their own problem in isolation; they are the same architectural idea, reapplied to adjacent parts of the developer tooling stack.
The timeline is short by the standards of developer infrastructure. Barely two years separate the first ad hoc language server efforts from a formal, multi-vendor protocol, and barely two more separate that protocol from a matching debugging standard. Infrastructure that normally takes a decade to standardize, if it standardizes at all, moved fast here because the pain it addressed was already sharply felt across every major editor vendor at the same time.
Why The Arithmetic Actually Matters
It helps to see the M times N problem in concrete numbers rather than as an abstract letter formula. Picture a modest, realistic slice of the ecosystem: eight popular editors and twelve commonly used languages. Under the old model, every editor needed its own dedicated integration for every language it wanted to support well, which multiplies out fast. Under the LSP model, each editor implements the client side once, and each language implements the server side once, so the total integration work grows by addition instead of multiplication.
That gap only widens as more editors and languages join the ecosystem, which is exactly why the protocol kept gaining adopters rather than losing momentum. Every new editor that implements the client side instantly inherits every language server that already exists, and every new language server instantly becomes available in every LSP-aware editor. Nobody has to coordinate with anybody else ahead of time.
Comparing The Old Approaches To LSP
| Approach | Portable across editors? | Where the logic lives |
|---|---|---|
| Eclipse plugin architecture | No, tied to the Eclipse platform and Java | Inside the IDE’s own plugin runtime |
| TextMate grammar files | Widely, but syntax highlighting only | A static grammar file, no semantic analysis |
| Bespoke servers like early OmniSharp | Partly, only to editors that adopted its own protocol | A dedicated server, but a one-off protocol |
| Language Server Protocol | Yes, by design, across any conforming editor | A standalone server, speaking a shared, open protocol |
Why LSP succeeded where earlier universal-IDE efforts stalled
- It separated the editor’s job from the language’s job completely, instead of extending one IDE’s plugin model
- It used a transport-agnostic, language-agnostic wire format, so a server in any language could talk to a client in any language
- It launched with real, working implementations already in production inside VS Code, not just a paper specification
- Multiple vendors backed it publicly from day one, which removed the fear of adopting a single company’s proprietary format
What We Learned
The Language Server Protocol did not succeed because it was clever in a way earlier efforts were not. Eclipse, NetBeans, and various editor-specific daemons all understood the value of separating language intelligence from the editor shell. What LSP got right was scope and timing: it kept the protocol itself deliberately thin, JSON-RPC messages describing documents, positions, and capabilities, and it let every editor and every language keep full control over their own internals. It arrived backed by multiple vendors at once rather than a single company’s roadmap, and it shipped with working code instead of only a specification.
The result turned a problem that used to multiply with every new editor or language into one that simply adds, and that arithmetic shift is the real reason a text editor in 2026 can support a brand-new language on day one, often before that language even has an official IDE of its own.
