What exactly did they embrace and extend with LSP? And what's going to get extinguished? They created it and others adopted it...

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.

To be cynical, I guess we're at the "embrace and extend" part; "extinguish" hasn't happened yet, but it could. Microsoft controls the LSP and VS Code is very popular; thus Microsoft has all the leverage in the LSP space. I'm not sure what "going rogue" would look like, on Microsoft's part, but with all the power, it could do so without adversely affecting itself.

To be more cynical all products from all companies are in the “embrace and extend” phase

What we are seeing now could fit a timeline where Microsoft is doing EEE again, as well as a timeline where Microsoft is trying to change its ways.

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.

By this logic, they are also currently Embracing and Extending Windows, Office, etc. This doesn't make sense to me. It's their original products, not something they embraced and plan on extinguishing.

Windows and Office are both mentioned as products that are leveraged to do EEE on Wikipedia: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

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.

CSS was to a large extent a Microsoft project (when the time came to introduce stylesheets it was more-or-less Opera and Microsoft against Netscape, and Microsoft had many more users than Opera).

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.

Well then that's clearly not EEE. There can be more predatory market strategies than just EEE.

- Embrace the web with Internet Explorer.

- 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.

Exactly this. It could be either one, but M$ has done zilch to earn goodwill from the community.

The features of LSP are exactly the features of VS Code. So if you create a different editor, it will only support what VS Code does. (Unless you put in per-language effort like the olden days). If you create an LSP, it will work best in VS Code.

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.

> The features of LSP are exactly the features of VS Code. So if you create a different editor, it will only support what VS Code does.

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.

> They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it.

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.

This is much better put than I could have said.

Visual Studio was a meme?

It is still top IDE matched by maybe just JB

Because up until (relatively) recently, you couldn't even compile code on Windows without VS.

I was going to say-- visual studio is phenomenal. The profiler is incredible to use.

You can say a lot about Microsoft the company. You can even take digs at Visual Studio Code and its "telemetry reporting". But LSP is one of the best things that's come out of that whole ordeal. It's far from perfect. But as a Vim user, we've had nothing this good until now. I used TernJS for JavaScript and some other handy plugins for other language specific stuff... and it was such a pain. LSP made things far more uniform. And they gave it away to the community! They didn't force anyone to use it.

I agree. I primarily use(d) Emacs, and while it’s had good support for certain languages for decades, now it handles younger languages like TypeScript and Rust exactly as well as Microsoft’s editors do. That’s freaking magical.

Microsoft does not use LSP for its own language TypeScript. They have something that works better for VSCode: tsserver. When TypeScript evolves, Microsoft updates tsserver and VSCode as needed. To get the updates to Emacs, someone needs to make the respective changes to a third-party TypeScript LSP first. And it won't work as well because LSP isn't as good.

Ugh, I didn't realize that.

typescript-tools for NeoVim uses tsserver