The Problem Before the Protocol
Before 2016, adding language intelligence to an editor meant writing it from scratch for that editor. A team building Go support for Vim would produce something entirely incompatible with the same support for Emacs, Sublime Text, or Eclipse. Multiply N languages by M editors and the maintenance surface became unmanageable — duplicated effort, inconsistent behaviour, and tools that lagged badly behind the language they served. Autocompletion, diagnostics, go-to-definition, rename refactoring: each feature had to be reimplemented per editor, in whatever plugin API that editor exposed.
The underlying intelligence — parsing, type-checking, scope analysis — was the same work every time. Only the delivery mechanism differed. That observation was the seed of the Language Server Protocol.
The Architecture the Protocol Introduced
Microsoft published the Language Server Protocol in 2016 alongside Visual Studio Code, extracted from Code's own internal mechanism for communicating with language services. The protocol defines a JSON-RPC conversation between two processes: an editor client that sends requests ("what completions are valid here?") and a language server that replies with structured results. The transport is deliberately simple — standard input and output, or a socket — so any language runtime can host a server without requiring native bindings to the editor.
The protocol specifies a fixed vocabulary of capabilities: textDocument/completion, textDocument/hover, textDocument/definition, textDocument/references, and the diagnostic push notification textDocument/publishDiagnostics, among others. A server advertises which capabilities it supports during the handshake; the client adapts. The result is that one server — say, rust-analyzer for Rust, or Pylsp for Python — can serve Vim, Emacs, VS Code, and any other conforming editor without modification.
This was the N×M problem collapsed to N+M: one server per language, one client implementation per editor, and the protocol in between.
What It Changed for Tool Authors
The practical effect was rapid. Language communities that had struggled to maintain fragmented editor plugins could now concentrate effort on a single server implementation. Microsoft's own LSP specification repository attracted contributions from language teams at Google, JetBrains, and the Apache Software Foundation, and the protocol was adopted by Eclipse's Language Server support layer almost immediately. Editors that had never had sophisticated language support — including many lightweight and terminal-based tools — gained it cheaply by implementing the client side of the protocol once.
The Language Server Protocol did not eliminate editor-specific work entirely; UI presentation, keybindings and extension marketplace integration remain per-editor concerns. What it eliminated was the deepest and most expensive layer: the intelligence itself, which now travels over a stable, language-neutral wire.