A Word of Caution about Language Server Protocol
Bear in mind Language Server Protocol is not a silver bullet: although not bad, LSP is not perfect and comes with some inherent issues. Client developers, for example, noticed that different servers were behaving differently to certain requests, or assuming clients would handle responses in a certain way, expecting different requests at different times. On their side, server developers might rely on one client implementation to develop their server, leading to discrepancies between the expected and actual behavior. Some protocol extensions, too, such as CodeAction, can be server specific, making it hard for a client to write a generic handler for such responses.
But these issues primarily impact client and server developers, not LSP users. Still, there are some small issues from a user standpoint. Much of the time, Language Server Protocol will not fully work entirely well “out of the box” and will require some tweaking.
Moreover, not every server will be configured in the same way. For example, the C/C++ server will require a compilation database, while jdt.ls server will require a gradle setup. This exposes a gap that IDEs can fill as IDEs can use Language Server Protocol while abstracting or unifying such configuration processes. However, now it is necessary to choose which server and which client to install and, if you are using an IDE, chances are that those choices have already been made for you.
If you are using a text editor, you most certainly have to choose, but there can be multiple servers for any given language and multiple clients for a given editor. Unfortunately, the best server will be close to worthless if you do not use a good client that exposes all of its capabilities, and vice versa. The final issue – and perhaps the greatest point of concern – is that not every language benefits from the same level of support and some server implementations are in a state of abandon or seeing little activity. This does not mean they are not functional, but it does raise questions about their capacity to reach a state of maturity or remain futureproof in the absence of an alternative implementation.
Current Language Server Protocol servers and clients can be found here and here.
By separating the language support services into a server and editor integration into the client, Language Server Protocol has adopted a ‘divide and conquer’ approach to a common developer complaint. LSP has helped in defining a way language support services are developed, exposed and integrated, and allowed developers to focus on integration while putting very advanced features into the reach of regular text editors. LSP is not perfect, though, and there are issues waiting for fixes still. The imperfect protocol is not the main blocker; instead, some languages are left with incomplete, or abandoned server implementations. This can potentially leave Language Server Protocol heterogeneous and unsuitable for several development use cases. For example, users may not want to spend time understanding why a server is not working, or which one to use if there is more than one server available.
Some server implementers continue to rely on VSCode as the de-facto standard for validating their server, and this can be problematic if, in the future, VSCode-specific extensions are developed and injected into the protocol. However, there are a number of languages that continue to be well supported, and the technology has clearly benefited those languages. Moreover, “new” languages like Rust were able to leverage the protocol to offer support services in modern IDEs and text editors.
In the future, we can hope Language Server Protocol evolves to be fully generic, enforces or at least clarifies some implementation details and provides reference implementation samples for developers to work with. Some editors are already taking this path and started implementing their own LSP client rather than relying on a plugin ecosystem. It is not absurd to imagine a text editor shipping with an integrated LSP API. Language Server Protocol has made language support services more accessible, and many editors/IDE can benefit from it.