Xtext LSP vs. Xtext Web
The Eclipse Xtext language development framework can be used to implement domain-specific languages (DSLs) as well as fully blown programming languages. In addition to a modern compiler architecture, it comes with tool support for different platforms, like Eclipse, IntelliJ and Web.
Since supporting all these different editor platforms is a lot of effort, we are strong supporters of the Language Server Protocol (LSP). The LSP defines a set of requests and notifications for editors to interact with language servers. A language server essentially is a smart compiler watching a workspace and exposing services for an editor. Such services cover things like content assist, find references, rename refactoring and so on. So the big question is :
When should I use Xtext LSP instead of a native editor integration?
As of today if you are looking for an Eclipse Plug-in my answer is clearly, go with the traditional Xtext Eclipse Plug-in. With Eclipse LSP4E there is Eclipse support for language servers, but it is not even close to what our native Eclipse support does. I also doubt that this will change any time in the future. The native Eclipse integration of Xtext is here to stay.
For IntelliJ IDEA the situation is different. Neither the Xtext integration has been updated with the last release, nor has Jetbrains yet started to work on LSP support. The code for the IDEA integration is quite extensive and deep. So deep that we get regularly broken because we use non-public API. Since the demand for IDEA integration is not high, maintaining it doesn’t make sense to us. That is why I asked Jetbrains to work on LSP integration last year already. So far they don’t seem to be convinced, but you could add your 2cents or +1 to this ticket if you think LSP would be a good IDEA.
For the rest of this post, I want to talk about Xtext Web and why you should not use it anymore and prefer the LSP integration instead.
The Xtext Web support was our first attempt to generalize language features over multiple editors. At that time we only abstracted over the web editors Ace, CodeMirror and Eclipse Orion (the editor widget, not the IDE). We did it over a REST interface and focussed on single code editors, only. The LSP integration works with any editor supporting it and while Eclipse Orion is still working on supporting it, the Monaco code editor from Microsoft fully supports it already. So here are my four reasons why you should use LSP for web applications:
Monaco Is Awesome
Our team has been working with Monaco since it came out last summer. For instance, we are developing a data science IDE for r-brain.io (you can try it for free :-)), where we use Monaco with language servers (currently Python and R). The R language server has been implemented in Xtext using the brand new LSP support. Please have a look at this article to learn more about its features.
So far working with Monaco has been a decent experience. The code is well written and organized, and the quality is very high. Microsoft uses TypeScript, which we do, too, when working on a JavaScript stack. It is to JavaScript what our Xtend programming language is to Java :).
Feature-wise I can say that it has all the things other editors have, but also comes with additional nice features like code-lenses, peak definition or the integrated find references. Moreover, it is very extensible letting use inline any kind of html for instance.
Multiple Editor Support
Monaco directly supports to work with multiple editors in a single website and connect them for e.g. navigation. This is also a big difference between Xtext LSP and Xtext Web. Xtext LSP is built on top of our incremental builder infrastructure, so it can naturally deal with multiple documents and even projects and dependencies. This doesn’t mean that you need to serve your files from a file system or need to deal with complicated project setups. It just supports this once you want to do it.
Xtext Web, on the other hand, can only handle a single document, and the underlying resource set needs to be provided programmatically.
Write Once, Run Everywhere
Having a fully compliant language server for your Xtext DSL will allow to use it in other contexts, too. Single-sourcing your language implementation and being able to run it in all different LSP-supporting editors is a huge plus. You decouple the work that you put into your language from the decisions you make regarding in which editors or applications you integrate it.
Future Proof
When it comes to integrating Xtext languages in web applications all our passion and love goes to the LSP. Our customers use either Eclipse or LSP, and we are happy helping people to migrate their existing Xtext Web solutions to LSP and Monaco. Going forward we won’t invest into the Xtext Web support but likely will deprecate it soon. In the future, given the adoption of the LSP, there will be even more tools and editors that can run your Xtext languages.
Final Words
So for me, the main focus in Xtext will be the traditional Eclipse support and the LSP support for everything else. The Eclipse support will benefit from the LSP support as well since we plan to implement new tool features in a way such that it can be used from Eclipse as well as from LSP.
Please get in touch if you have questions or any doubts whether your use case is well covered by this focus.
