Have you ever wondered how web browsers can offer smart text options such as auto-fill and hover translate/definition? This is made possible through complex development tools, or IDE Software (Visual Studio, Vims, Eclipse, RAD Studio) tailoring features for each server (C/C++, Java, Python, etc.). This used to be a repetitive process, as each development tool would have to customize its programming language to be read by different servers, which have specific requirements.
When Microsoft introduced the language server protocol (LSP) in 2016, it facilitated an open-code, standardized way to communicate between all development tools and servers. Today, developer companies like Red Hat are continuously adding to the protocol, and programming languages are offering their own LSP capabilities.
What is an LSP?
With LSPs, developers can simply integrate these libraries to their editors and refer to existing language infrastructures instead of customizing their codes one server at a time. For editor builders, they only need a single protocol to support different languages. For language developers, they only need to implement their code in one server to be compatible with numerous editors.
Why do we need LSPs?
There are two main ways that LSPs have made the coding process easier.
- Centralized communication. Before LSPs, developers had to duplicate their efforts across major servers, which was time-consuming. With LSP support becoming a service, developers can now focus on integrating LSP into their editors/ integrated development environment (IDE) and expanding their capabilities.
- Enabled developers to use different editors instead of sticking to just one. Developers can experiment with different plugins and work directly from different IDEs.
A word of caution, though. LSPs are still a work in progress, and not all programming languages are equal. Some languages don’t enjoy the same extensive server support as the more developed ones do. Some protocol extensions are also still server-specific. Still, this concern sits on the developers’ shoulders and not the LSPs.
How can I use an LSP?
A typical session goes like this. Suppose a user wants to add a ‘Go to Definition’ feature to a document. When a user opens a document in their IDE, the tool sends a notification to the language server. The tool keeps the file version in memory at this point (instead of in the file directory), which allows all edits to be synced between the tool and the server.
Next, the server acknowledges and analyzes any changes that the user implements on the document. If there are any errors, the server will notify the tool. The user will then send a definition request with specific parameters. The server reflects this request immediately.
Finally, when the user closes the document, the tool informs the server that the document is no longer in memory and has returned to its file location. In general, the editor requests are simplified and the programming language is neutral, which eliminates complexities and confusion.
To further standardize LSPs, there are two major software development kit (SDK) libraries that programmers can refer to. First is the development tool SDK, which focuses on integrating language servers to editors. The other is the language server SDK, which is used for implementing a language server to a specific programming language.
What about enterprise usage of LSP?
LSPs are a game changer for developer firms. With the simplification and standardization of the server communication process, IDEs are expected to come up with more extensive LSP capabilities and features just by using one language library. LSPs have democratized the IDE ecosystem, with many editors creating their own detailed implementation references with actual samples that other developers can adapt.
Programmers can also leverage the existing language infrastructures to save money by reusing codes for very niche clients or product requests. This is especially useful for small startups looking into expanding their features quickly and efficiently. Beginner developers could also take advantage of the available open-code resources out there to explore lesser-known programming languages.