Building VSCode, LSP and Typescript could still prove to be the Embrace and Extend phase. There are some worrying signs, e.g. many VSCode extensions built by MS don't work on open-source VSCode builds like code-server and VSCodium. From a business perspective, this makes sense, as GitHub Codespaces and vscode.dev now have features that are difficult to get in competitors. Maybe at some point they will try to Extinguish all local development and push everyone to use a cloud version of VSCode? (See e.g. Python integration in Excel)
The truth is probably a lot more complex, but we can't rule out anything yet.
They are not extinguishing their own products, but using their products to extinguish alternatives. The example I mentioned actually fits the wikipedia definition quite well in my opinion.
Nonetheless Microsoft managed to use CSS to achieve a great deal of user lock-in by refusing to conform to the standard they co-authored.
- Extend the web with CSS as an open standard.
- Extinguish competition by being the main browser and not following the CSS standard.
Still follows the recipe quite well in my opinion.
As well, Microsoft is building a wealth of VS Code-only features and LSPs (locking out VSCodium), by the end, they will have taken from open source and not given anything back.
This is not true since LSPs can add extensions to the existing API. For example: https://github.com/rust-lang/rust-analyzer/blob/master/docs/...
> If you create an LSP, it will work best in VS Code.
Any editor can work just as well as (or even better than) VS Code.
This was something that had puzzled me for a while until just today when reading another post on the original linked article's site.
It seemed odd that after MS had used Atom/VSCode to essentially "suck all the air out" of the FLOSS/free editor space that they would then "share" something like LSP which seemed to then make it easier for other editors to (at least potentially) offer a similar standard of support for languages that had LSP implementations.
(Because from a purely technical POV I do see LSP as a positive development in the editor space.)
But what I'd apparently missed was something mentioned in an earlier "Why LSP?"[0] post by the same author:
> "[...] Microsoft, who were a vendor of both languages (C# and TypeScript)
> and editors (VS Code and Visual Studio), and who were generally losing
> in the IDE space to a competitor (JetBrains)."
and, so:
> "...launched LSP to increase the value of their platform in other domains
> for free (moving the whole world to a significantly better IDE equilibrium
> as a collateral benefit)."
Thus, assuming this is accurate, the actual target in this case was JetBrains and "sharing" LSP was seen as a reasonable "cost" in order to get additional leverage.
Given that I haven't generally paid attention to any of the C#/TypeScript/JetBrains worlds that was an angle that I'd missed.
The assumption on my part that "sharing" LSP still wasn't likely to be an "altruistic" act on the part of MS was primarily driven by the fact that they hadn't really given up on proprietary/control they'd simply moved the demarcation point to be at the LSP implementation level (e.g. the plugin for Python) & "marketplace" access (e.g. remote plugin) etc (e.g. telemetry).
And by defining/retaining control of LSP they've inserted themselves in the path between other editors & LSP implementations which inherently has value (e.g. by being the "reference"/default implementation[1]).
Anyway, that was an aspect of the context for LSP that I wasn't aware of before today, so thought it might be of interest to some.
(Obviously the majority of today's developers see no issue with the actions of MS in any of this, so, if that's you feel free to agree to disagree & leave the rest of us to tilt at windmills in peace--after all, why would we stop now? :D )
[0] https://matklad.github.io/2022/04/25/why-lsp.html#Why-LSP-is...
[1] Which is one of the reasons I'd really like rust-analyzer to one day change to target an editor implemented in Rust by default. VS Code doesn't need any more value added to it for free but any Rust-based editor would benefit from being a "First Class" rust-analyzer citizen & thus strengthen the wider Rust ecosystem.
They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. Instead they took care to make a well documented and reasonably open protocol that others can use for their own language support, and to integrate TypeScript into other IDEs.
I really don't understand what you think they should've done instead.
Do you think that the world where every compiler has its own API is better? You're still free to do so - just develop an extension for VSCode and/or all the other IDEs instead of a single LSP server implementation.