Language Servers are the New Frameworks
Tags: dx
Published: 2020-12-05 20:51:05

---
title: Language Servers are the New Frameworks
published: true
description: Developer Experience is shifting left, all the way to onKeyUp.
tags: DX
slug: language-servers
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/3xvu11v9ayvaxnakzsk9.png
canonical_url: https://www.swyx.io/language-servers
---

When Svelte 3 [launched](https://news.ycombinator.com/item?id=19719118) in 2019, the top demanded feature was TypeScript support. And when TypeScript support was [finally announced](https://twitter.com/sveltejs/status/1285627864310743043?lang=en) in 2020, the reception was ecstatic. 

But the secret is - not much needed to change in Svelte's core code. It simply added [language tooling](https://github.com/sveltejs/language-tools) to its core responsibilities. Svelte already had TypeScript preprocessors for years - but it wasn't considered to have "TypeScript support" until the VS Code extension shipped.

I think this is indicative of a broader trend:

**In the [Third Age of JavaScript](https://www.swyx.io/js-third-age/), all frameworks will provide their own language servers.**

By way of proof, you see this pattern emerging in other frameworks as well:

- [Vetur](https://github.com/vuejs/vetur) is standard tooling for all Vue.js developers
- React strongly recommends [ESLint checks](https://reactjs.org/docs/hooks-rules.html#eslint-plugin) to enforce the Rules of Hooks (this is probably an understatement; probably no React professional would trust themselves to write Hooks right without the ESLint checker today)
- Angular has the [Angular Language Service](https://github.com/angular/vscode-ng-language-service) (thanks [Mike](https://twitter.com/mhartington/status/1335338641447587840)) and Ember is [working on it](https://marketplace.visualstudio.com/items?itemName=lifeart.vscode-ember-unstable) (thanks [Alex](https://twitter.com/vaier/status/1335482247810592768?s=20)) 
- Tailwind Labs' [first hire](https://blog.tailwindcss.com/welcoming-brad-cornes-to-the-tailwind-team) was Brad Cornes, who made the Tailwind IntelliSense plugin
- [GraphiQL](https://github.com/graphql/graphiql), [Relay Compiler](https://relay.dev/docs/en/installation-and-setup#set-up-relay-compiler) and [Apollo VS Code](https://www.apollographql.com/docs/devtools/editor-plugins/) can be regarded as language servers for GraphQL development

Linting, typing, always-running-compilation and other forms of write-time checks and optimizations are not new. In fact, when dev teams write unit tests and lint rules, they are essentially creating their own bespoke language server for their own app. What's new is that **giving realtime feedback is now a responsibility shared by frameworks**. This standardization increases productivity both when starting a new project and moving between projects.

## Why

The proximate *reason* this is a thing is simple: Cost.

IBM coined the term "[Shift Left](https://devops.com/shift-left-can-you-be-left-out/)" after finding that [the earlier you catch errors, the cheaper they are to fix](https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_Software_Development_Life_Cycle_SDLC) ([Neil](https://twitter.com/mknz/status/1335351649720668161?s=20) points out that this research goes as far back as [Barry Boehm in the 1980s](https://dzone.com/articles/real-cost-change-software)). If you arrange the software development lifecycle from left (design) to right (production), the idea is that if you shift your errors "left" then you'd save actual money by catching errors earlier ([this is disputed](https://gist.github.com/Morendil/6d664bf990c17ea0f88f9bb0cc403c64) — and [finding proof is hard](https://buttondown.email/hillelwayne/archive/i-ing-hate-science/)!). 

Of course, the flip side of Cost is *Developer Experience*. **Cost is what our bosses pay, DX is what we *feel***. And we always gravitate to tools that guide us down the [pit of success](https://blog.codinghorror.com/falling-into-the-pit-of-success/).

You could translate this idea to modern terms:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/4nyfjt36m2ueummlqfsc.png)

And then plot the slow leftward shift of frameworks:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/3xvu11v9ayvaxnakzsk9.png)

Remember I said cost was a *proximate* reason. I believe there's a deeper, more fundamental reason.

## Tom was Right (and still is)

In 2017, Tom Dale of the Ember core team observed the first part of this evolution, that [Compilers are the New Frameworks](https://tomdale.net/2017/09/compilers-are-the-new-frameworks/). 

> My current “investment thesis” is that what we call web frameworks are transforming from runtime libraries into optimizing compilers. When it comes to eking performance out of hand-authored JavaScript and accompanying runtime libraries, we’ve reached the point of diminishing returns.

He was not only astoundingly right (Svelte is built from the ground up as a compiler) but this process is also not done (Next.js is arguably an optimizing compiler for React, but the React team itself is working on Selective Hydration and a [hybrid client/server model](https://twitter.com/dan_abramov/status/1259615094163607561)). Every framework basically invents its own metalanguage ([React](https://www.youtube.com/watch?v=QiR9viVIJgo), [Svelte](https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c32185b61934), [ActiveRecord](https://medium.com/@llkktt/blog-707634e025cf)) to solve for developer experience under constraints of a more popular general purpose language, and this language will eventually want to be compiled.

I'm simply extending this train of thought to its natural conclusion: what we call web frameworks are transforming from runtime libraries, into optimizing compilers *with first class language server support*.

I don't know how unique this observation is but it felt revelatory [when I first realized it](https://twitter.com/swyx/status/1259121891555467264?s=20). After you observe the evolution of a few frameworks and developer platforms you start seeing the same movie play out over and over again. To offer better developer experience, you end up creating a language. A language needs a compiler. A compiler eventually wants a language server.

## Sell the Shovels

Language servers do a lot of [undifferentiated heavy lifting](https://jeremybower.com/articles/undifferentiated-heavy-lifting-2-0.html) - file watching, processing, reporting, supporting plugins for every IDE, and so on. If we're all going to be building language servers, why do we have to reinvent the wheel every time? 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/s1ixc6yvv6b1xfj10ate.png)

Naturally, if language servers are the new bar for frameworks, those who *own* the common rails for the language server layer will do very well. Microsoft first developed the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) for VSCode and [standardized it in 2017](https://www.infoworld.com/article/3088698/microsoft-backed-langauge-server-protocol-strives-for-language-tools-interoperability.html). This was a generous move that ensured the protocol would work with non-Microsoft IDEs like [Eclipse](https://www.eclipse.org/community/eclipse_newsletter/2017/may/article1.php), [IntelliJ](https://youtrack.jetbrains.com/issue/IDEABKL-7409) and even [vim](https://www.vimfromscratch.com/articles/vim-and-language-server-protocol/), and non-Microsoft languages like [Python](https://visualstudiomagazine.com/articles/2020/07/01/pylance-vs-code.aspx). Because LSP is ironically language and tooling agnostic, you also greatly lower the barrier for entire generations of language and editor agnostic startups, like [Sourcegraph](https://langserver.org/) and [Kite](https://www.kite.com/).

Here's my advice for anyone who wants to make their dev tools project successful: **time to learn how language servers work.**

> Author's note: Orta from the TS core team [left a great comment](https://dev.to/orta/comment/18o1d) with more resources to learn about LSPs from Anders Hejlsberg and a coming "Build Server Protocol"!

---


*[see Twitter conversation](https://twitter.com/search?q=https%3A%2F%2Fdev.to%2Fdx%2Flanguage-servers-are-the-new-frameworks-1lbm&src=typed_query)* 

---

> Note: this was 1/3 of the thesis of [my second React Rally talk](https://docs.google.com/presentation/d/1sBb7KjhSOiONML61fnYwkVI-7yzJCoP-Zgs6E37T-nY/edit?usp=sharing).

{% youtube 18F5v1diO_A %}


----

> [DX Circle](https://codingcareer.circle.so/c/dx-blog) is a new journal on Developer Tools, Developer Communities, and Investing in Developer Experience Startups. If you'd like to submit an article, [let me know](https://twitter.com/swyx)!