Editor's Note
In this month's newsletter we will be re-thinking how advanced editor support for all kinds of languages is built. The current state of the art is implementing support for each language like Java, PHP or C++ independently for every IDE. This labor-intensive and error-prone approach is about to change with the introduction of the Language Server Protocol (LSP).
The more advanced the tooling you are developing, the closer you are to writing a full-blown compiler/interpreter for the language. This is a huge waste of time, as the developers of the language have already written these tools, but often not with IDE requirements in mind. They are usually designed to only handle complete, valid source files, while an IDE usually has to handle source files that are currently being edited and thus by definition incomplete.
Another caveat about the traditional approach is attracting contributors. Let's say your IDE is written in Java and provides PHP support and some PHP developers are pointing out bugs. Many of them would probably love to fix those bugs themselves, but the completely different language creates a high barrier for contribution.
Last but not least, language tooling developers not only have to support a broad range of IDEs, but they also need to chase after new languages features/versions. What about Java 10 features? PHP 8? Swift 4?...
The LSP developed by Microsoft for Visual Studio Code, aims at fixing these shortcomings. It is a language and IDE agnostic protocol which clearly separates language semantics from UI presentation. Language developers can implement the protocol and benefit from immediate support in all IDEs, while IDE developers who implement the protocol get automatic support for all these languages without having to write any language-specific code. This way both parties can focus on what they do best; language developers can ensure that auto completion proposals and error markers match the language specification perfectly, while IDE developers can focus on providing a great user experience. Even better, both parties can implement the protocol using the technology of their choice. The Eclipse IDE can consume the protocol with a Java API, while a PHP language server might be implemented in PHP. Did we just find the Holy Grail?
Not quite yet. The Language Server Protocol is still limited. You do not yet get all the wonderful Java tooling that Eclipse JDT provides. But it's a paradigm shift. As I see it, IDEs will become a set of UI clients for several tooling services, all communicating via standard protocols. Microservices are everywhere, and they are coming to your IDE very soon.
Read the 8 great articles below to learn more!
Mikaël Barbero (@mikbarbero)
|
