> This is one of those cases where having a standards committee or consortium is the way to go. Committees have their problems, but I think it's only reasonable.
I think a committee is a reasonable backup plan, and can even be done without Dirk's approval (see e.g. WHATWG done without the W3C's approval). If the LSP continues to be "good enough" then it seems unlikely.
> If you think about it, doesn't it seem inevitable that eventually, big organizations that make editors would want a consortium of some sort to collaborate on protocols like this?
Maybe? Editors tend to be an afterthought for most companies; JetBrains is the only company I can think of that is big on the LSP and for whom the editor is a primary experience.
Yes I certainly agree, there is not really much of an impetus for this to happen right away or anything. In the long term, though, I do suspect it is inevitable.
> Maybe? Editors tend to be an afterthought for most companies; JetBrains is the only company I can think of that is big on the LSP and for whom the editor is a primary experience.
I have some thoughts:
- I think there will be more. At the very least, I suspect there is a reasonable chance Apple/XCode would eventually adopt LSP.
- Realistically, there aren't that many browser engines either. There's really just two truly distinct browser engines, and really only one of them is the main product of the company that produces it. Arguably there are already more distinct text editor engines that have LSP clients built-in today: Neovim, VSCode/Monaco, Visual Studio, IntelliJ IDEA, Eclipse, Zed, and probably more I'm not thinking of.
- I think that it is likely LSP clients will continue to appear in more places. In "cloud compute" UIs for things like serverless functions, inside of code forge's built-in editors, and so forth. It's not that it's necessarily that it's so easy to do it well, it's more that the value:effort ratio of doing it is pretty great, and every time someone develops a new high-quality LSP, it gets even better.
Note that by fund distribution, Firefox is not the main product of Mozilla. There are zero browser engines that are the main product of their owning companies.
I did think about phrasing it this way, but to be fair, by income, Firefox is definitely their main income source. Although, not in a great way. Not looking forward to how that pans out.
> Editors tend to be an afterthought for most companies; JetBrains is the only company I can think of that is big on the LSP and for whom the editor is a primary experience.
Well, expand beyond "big companies", to include open source prijects, and non-profit foundations, and there are a lot of parties that might be interested in an LSP comity including both groups that develop editors (neovim, emacs, Jetbrains/intellij, eclipse, zed, etc.) and makers of lsp servers (ex. Google for gopls, Rust foundation for rust, etc.)
I don't follow. The reason why you use LSP is because it is a common protocol. LSP is valuable because it is a standard protocol; build an LSP client into your text editor and gain access to the rich ecosystem of existing LSP servers, build an LSP server for your language and get rich code intelligence for your language inside many of the most popular text editors.
Of course someone else could just try to make a competing protocol with LSP, but I think that's a waste of time when it could most likely be incrementally and backwards compatibly improved quite a lot. And also, any given party only is one side of the equation, so any given entity only has so much sway here.
> The reason why you use LSP is because it is a common protocol.
Exactly. And if "everybody" (except MS) in the committee agrees on the implementation of LSP, they can define a new common protocol too. The old LSP clients and servers won't stop working, they may slowly die out if the new protocol "wins".
Don't get me wrong, this is just a hypothetically perfect solution, which didn't happen before LSP and I'm sceptical that it will happen in the foreseeable future, as LSP is "good enough". And with "it" I mean that there won't be such a commitee, much less a new, common protocol.
It will always need a new, better and open protocol implemented in a successful editor or IDE to gain traction and spread (like what happened with VS Code and LSP).
The reason to use LSP is that there are already many existing implementations of it.
Starting over with a new protocol, and replacing implementations for all the existing editors and languages would be a tremendous amount of work for relatively little benefit.
And either forking lsp, or creating a new protocol would cause fragmentation.
Also, VSCode is popular enough that even if the other editors forked LSP and made significant improvements, if VSCode wasn't on board, it would be a tough sell to get many languages and existing LSP implementations to adopt it.
I think a committee is a reasonable backup plan, and can even be done without Dirk's approval (see e.g. WHATWG done without the W3C's approval). If the LSP continues to be "good enough" then it seems unlikely.
> If you think about it, doesn't it seem inevitable that eventually, big organizations that make editors would want a consortium of some sort to collaborate on protocols like this?
Maybe? Editors tend to be an afterthought for most companies; JetBrains is the only company I can think of that is big on the LSP and for whom the editor is a primary experience.