You've seen it. That little spinning icon in the VS Code status bar. "Initializing JS/TS language features..." followed by some loading animation while your editor "thinks."
I always noticed it. Every time I opened a TypeScript project, there it was — indexing, loading, doing something behind the scenes.
I never questioned it. Just waited for it to finish and got back to work.
Then one day I actually looked into what was happening behind that loading icon. And what I found changed how I think about every code editor, every AI coding tool, and honestly — the entire developer tools ecosystem.
That little icon? It's the most important thing in your editor. And it has nothing to do with VS Code.
The Feature You Think VS Code Built
Hover over a function and see its type signature. Ctrl+click to jump to a definition. Rename a symbol across your entire codebase.
These feel like VS Code features. They feel built into the editor.
They're not.
Every single one of those — hover info, go-to-definition, auto-completions, error squiggles, rename refactoring — comes from a separate program running in the background. For TypeScript, that program is called tsserver. It's a language server. And it talks to VS Code through a protocol called LSP — the Language Server Protocol.
VS Code is just the messenger. The intelligence lives elsewhere.
That loading icon I kept seeing? That was tsserver booting up, parsing my entire project, building a map of every type, every function, every connection in my codebase. VS Code was just... waiting for it.
Before LSP: The Dark Ages Nobody Talks About
Here's the thing most developers don't realize — before 2016, none of this existed as a standard.
If you wanted smart code features in your editor, the editor itself had to understand your programming language. Every editor. From scratch. Separately.
Think about what that means.
Want TypeScript support in Vim? Someone had to build TypeScript intelligence specifically for Vim. Want it in Sublime Text? Build it again. Eclipse? Again. Atom? Again.
Every editor team was solving the same problem independently. Every language community was doing the same work five, ten, fifteen times over for different editors.
The result was predictable. Most editors had mediocre language support. A few editors had great support for a few languages. And developers were locked into editors based on which ones happened to have decent tooling for their stack.
It was a mess. A slow, fragmented, duplicated mess.
The HTTP Moment
In 2016, Microsoft introduced LSP. And honestly, this is the part that doesn't get enough credit.
The idea was almost embarrassingly simple: separate the editor from the language intelligence.
Let the editor handle what editors are good at — showing text, managing tabs, rendering UI. Let language-specific intelligence run in its own server. Then define a standard protocol for them to talk to each other.
Editor says: "Hey, the user is hovering over line 42, column 15. What's there?"
Language server responds: "That's a function called processOrder that takes a CartItem[] and returns a Promise<OrderResult>."
That's it. JSON messages over a standard protocol. The editor doesn't need to know TypeScript. The language server doesn't need to know what editor you're using.
This is why I call it the HTTP moment for code editors.
Think about what HTTP did for the web. Before HTTP, if you wanted to access information on a network, you needed specific client software for specific servers. HTTP separated the browser from the server. Suddenly any browser could talk to any server. The web exploded.
LSP did the same thing for developer tools.
Build one language server for Python, and it works in VS Code, Neovim, Helix, Sublime, Emacs — everywhere. Build one editor with LSP support, and it instantly gets intelligence for every language that has a server.
One protocol. The entire ecosystem unlocked.
The Love Story That Built an Empire
Now here's where it gets interesting.
TypeScript's language server, tsserver, wasn't just any language server. It was arguably the most sophisticated one ever built. And VS Code wasn't just any editor — it was built by the same company, Microsoft, specifically designed to be a thin, fast LSP client.
This pairing was intentional. And it was devastating for the competition.
When you opened a TypeScript project in VS Code, the experience was magical. Instant type information. Intelligent auto-imports. Refactoring that actually worked across files. Error detection before you even saved.
None of this was VS Code being clever. It was tsserver being brilliant, and VS Code being the perfect lightweight client for it.
But here's the beautiful part — because it was all LSP, that same tsserver intelligence worked in Neovim. In Helix. In any editor that spoke the protocol. VS Code just happened to be the smoothest client for it.
That's how VS Code won the editor wars. Not by building the best editor. By being the best client for the best language servers.
The Plot Twist Nobody Saw Coming
Fast forward to today. AI coding tools are everywhere. Cursor, Continue, GitHub Copilot, Cody, Windsurf — every month there's a new one promising to revolutionize how you write code.
Want to know what they all have in common?
They're LSP clients. Advanced ones, sure. But LSP clients nonetheless.
When Cursor's AI suggests a refactoring, it doesn't magically "understand" your codebase by reading files. It sends LSP requests — the same requests VS Code sends — to get type information, symbol references, diagnostics. It feeds that structured context to an LLM, which generates smarter suggestions.
The AI didn't replace LSP. It built on top of it.
Think about that for a second. The protocol designed in 2016 to let editors talk to language servers is now the backbone feeding context to AI models. Language servers provide the structured understanding — types, references, errors, symbols — that makes AI coding tools actually useful instead of just autocomplete on steroids.
LSP didn't just survive the AI wave. It became the foundation the wave is built on.
The Quiet Revolution
Honestly, this is what gets me.
We talk endlessly about which AI coding tool is best. Which LLM writes better code. Whether agents will replace developers.
But underneath all of that noise, there's a nine-year-old JSON-RPC protocol quietly doing the actual work. Making sure your AI tool understands that user on line 47 is the same user defined on line 12. That renaming a function here doesn't break an import there. That the type signature your agent needs to make a smart suggestion is available in milliseconds.
Code intelligence became open, composable infrastructure. Not locked inside any one editor. Not owned by any one company. A shared foundation that editors, plugins, and now AI agents all build on equally.
A freelance developer in Lagos using Neovim gets the same TypeScript intelligence as a staff engineer at Google using VS Code. A brand new AI startup gets the same structured code understanding that GitHub Copilot does.
That's what LSP actually did. It didn't just connect editors to language servers. It made code intelligence a public utility.
So next time your editor magically understands your code, or your AI agent suggests a refactoring that actually works — look for that little loading icon in the status bar. Thank a 2016 protocol that quietly became the HTTP of developer tools.
That's exactly what I'd like you to take away from this article.
The most transformative infrastructure isn't the kind that makes headlines. It's the kind that disappears into the background — so invisible, so reliable, that you forget it exists. Until you realize everything you depend on was built on top of it.
That, My Friend, is the Language Server Protocol, The unsung Hero that nobody talks about.
More From Me
If you enjoyed this, check out my GitHub Copilot Competition submissions — two projects where I pushed the boundaries of what developer tools can do:
- I Built a Voice-Controlled IDE in 16 Days. My Voice Is Now My Editor.
- I Watched an Anime and Built a VS Code Theme Bundle Inspired by 17th-Century Japanese Art
I write about AI tools, developer workflows, and who gets power when technology becomes accessible.
Top comments (5)
Great article. LSP really doesn't get the credit it deserves. It's like the backend team: when it works correctly people don't even know it is there, but when it breaks it gets all the blame for everything.
"Ctrl+Shift+P -> Restart TS Server" is muscle memory at this stage.
Thank you for reading the article (:
LSP are the unsung heroes! Makes me kinda sad that vibe coders and next gen of Software Engineers will never be able to experience before/after the LSP revolution.
I never thought about it before, but it does seem magical. I never questioned how they managed to make it work. I'll read more about LSPs.
Thank you!
Thank you (: