Visual Studio Code 可以翻盘成功主要是因为什么？

我觉得主要几点吧：

一是这货是真心的想做一个程序编辑器的，其实名字不代表什么，但是他确实是贯彻了名字，就是Code，就是写程序的。这个编辑器一切都为写程序优化，一切和写程序没啥关系的东西都不被考虑。很多文本编辑器就是定位问题，什么都想做，什么都做不好。还有很多IDE，集成了太多莫名其妙的功能（例如VS、例如JetBrains什么的）。当然，要商业化需要有卖点，这一点可以理解，而VS Code没有这种包袱，它只需要考虑一个用户群体，就是敲代码的。

二是的确是从VS和各种IDE里面吸收了很多的牛逼Plus的设计，但是大部分功能又是插件提供的，主体很轻巧，这样它启动就很快，如果某个插件影响了性能，大家会怪罪于插件，马上又会有轻量级的插件出现。这就避免了传统IDE的功能越多越慢，隔三岔五的就要来个架构重塑性能优化。像VS真的是什么办法都想了但是还是不可避免地越来越慢。

谈不上翻盘，Vscode的主要对手是Sublime Text和Atom。从有了插件功能支持之后，就一直在攻城略地。

代码编辑器是一个江湖。Vim和Emacs属于上古元老，接触代码时间久了，总有那么一两个时候，是需要这两位大神出马才能方便搞定的。无论在任何时候都使用这两个编辑器的人，也都非常硬核，如果不会被sublime text吸引，基本上也不会理睬Vscode。

而Pycharm，Eclipse这样重度的IDE，和上面三个也不构成面对面竞争，毕竟上面三个是文本编辑器，本质上是玩的字符串，只是通过各种插件来支持各种编程语言；而IDE的目的非常明确，就是具体到某个语言的编程环境。

这就像一个市场一样，Vim/Emacs在最硬核/情怀端，IDE在细分市场端，中间留下的就是GUI下的文本/代码编辑器的市场了。

Sublime Text是原生的C++ GUI界面，「快」是它截止到现在依然对Electron引擎（包括vscode和atom）的优势。但是Sublime Text的问题也在于此。因为Electron框架是高度成熟的网络应用框架，表现能力非常强——本身就是在写网页，原则上网页能展现出什么效果，就可以在文本编辑器里面出现什么效果。

而Sublime Text的作者是Jon Skinner是一个人的公司，当然他是一个优秀的程序员，但是从精力和时间上也确实无法和团队开发相比；其次，sublime text的框架本身局限性很大，像现在作者加入了phantom和minihtml，已经是不错了，但是依然无法和网页的表现力相比。最典型的例子就是当运行Ipython Notebook的时候，在VScode上的体验远远胜过在sublime Text里。还有各种文档预览，网页里面玩PDF内嵌可以玩的飞起，而sublime text就只有调用外部程序这一个选项了。

从插件语言的流行程度上，Sublime用的是Python，Vscode用的是Node.js。这Python vs Node.js，大家半斤八两，双方都有数量庞大的拥护者。现在大家一般不太会为了用一个编辑器而单独学一门脚本了，基本是配置文件用json，然后选一个主流脚本语言开发插件。像vimscript的地位，只能说是历史形成的了。

本来，Atom和Sublime Text是旗鼓相当的对手，Sublime快，Atom表现力强。所以稍微大一点的项目就用sublime text，而小项目用atom就行。但是VScode的加入改变了战局，首先，在加入了插件功能支持之后，VScode就是一个更好的Atom。用这一样的引擎，vscode的速度吊打atom。这种同质竞争是特别残酷了，所以vscode可以不断的吸收使用Atom的使用者，转化atom的插件为自己所用。

而等到vscode插件富足之后，在速度相差不大的情况下，VScode对sublime text功能上的优势就也显示了出来了。像vscode里的Ipython Notebook是一个带Intelligent Autocompletion的原生Python Notebook环境；这一点Sublime Text是做不到的。所以VScode的上位，成为GUI文本编辑器的第一名，可以说是实至名归的。并且目前看不到强有力的挑战者的存在，可以预计在未来一段时间内，还会继续的霸占榜单的前几名。

这个问题很大耶……我不敢下断言说什么就是主要原因，也不敢代表广大用户，就从个人来说 VSCode 最打动我的地方是从它身上我看到了 Unix 哲学的影子。（而它来自微软哈哈哈哈哈哈

2016 年我在 IBM 任职的时候参与了 Eclipse Orion 的开发。Orion 并不是那个知名 Java IDE，只是 Eclipse 基金会旗下的一个基于浏览器的 IDE。我个人觉得它的 TextView 比编辑器本身要有名，至少当年我还是能数得出好几个产品本身比 Orion 有名但底层用了 Orion 的 TextView 的 web IDE。

以上是一些个人背景。重点在于我当时做的一个项目是给 Orion 加 debugger。经过了短暂地技术选型之后很快我们就敲定直接上 VSCode Debug Protocol 了。那什么是 VSCode Debug Protocol 而为什么又要选 VSCode Debug Protocol 呢？

所有语言的绝大多数调试工作都是有非常相似的接口的。抛去一些特有技术，诸如微软的内存断点，V8 的运行时代码修改等，包括但不限于：

• 控制程序运行与暂停
• 基于代码的行号（甚至是列号）下各式断点
• 查看堆栈内容
• 运行时的表达式求值

像是 Visual Studio 这类的传统 IDE 一向是支持通过插件开发来支持新语言的。而 VSCode 更近了一步—— debugger 不再是依附于 VSCode 的插件，而是独立运行的进程，双方用 VSCode Debug Protocol 进行通信。而 VSCode Debug Protocol 本身是一个基于 JSON 的文本协议。这个独立的进程虽然可以用 VSCode 宿主提供的 node 环境，但其本质仍然是调用一个可执行文件。不想用 TypeScript 写 debugger adaptor？宿主 IDE 没有 node 环境？统统没问题，只要你能开新进程一切好说。

等等……这听上去是不是有点熟悉？

程序应该只关注一个目标，并尽可能把它做好。让程序能够互相协同工作。应该让程序处理文本数据流，因为这是一个通用的接口。^[1]

这不是 Unix 设计哲学吗？又是文本传输又是独立进程，这意味着 IDE 和 debugger 甚至可以运行在网络的两端（事实上 Orion 就是这样做的，浏览器跑 Orion 服务器跑 debugger adaptor）。为 X11 设计了网络透明传输协议而又为了 Wayland 抛弃了网络透明而捶胸顿足的 freedesktop 遗老怕不是要垂死病中惊坐起，向天再借五百年？

而事实上不光是 debugger protocol，Language Server Protocol 也同样是基于 JSON 的文本协议。我在给 Orion 写 debugger 时候另一组人在给 Orion 做 Java 集成。而我看了一眼代码发现用的就是 LSP……

后来过了两个月我又在给 Orion 增强集成终端。当时我们用的是 term.js + pty.js，但是当时都已经停止维护了。与此同时我发现这两个项目被 fork 成了 xterm.js 和 node-pty，用了 TypeScript 重构，并且微软的人大量参与。而事实上这两个项目正是组成了 VSCode 集成终端的组件。

所以这实际上是个我参与了一个 web IDE 的开发结果最终我对 VSCode 五体投地的故事……

而这种类似 Unix 哲学的设计方式正是我用 VSCode 的最大体验。我用 VSCode 写过 web 前端、写过 web service、写过嵌入式、写过 OpenGL、写过 LaTeX，写过的东西种类多到数不清。而每次自己要集成一个新环境的时候我思考的都是：目前有什么工具链，而这个工具链如何和 VSCode 对接。因此我才说 VSCode 并不适合完全新手，而更适合知道如何用命令行或 API 完成所有工作的人自己去做 IDE 的集成。

最后补充两点比较小但是我个人觉得还挺重要的点。

早期 VSCode 是没有带 GUI 的设置界面的，一切设置都要手写 JSON。然而作为手写设置的一股清流，VSCode 居然是有静态检查的，不光能告诉我有些什么 field 可用，甚至能告诉我这里的值只能是 "warning" 或 "error"。有的时候面对插件提供的自定义设置，代码生成的设置界面会有大大小小的问题，开发成本也很高；而不带静态检查的手写设置又必须对着手册写，运行了才知道会不会炸。相比之下 VSCode 带静态检查的手写设置集两家之长。TypeScript 真的战斗力太强了……

另一点很重要的是它开放。开源软件其实是个很大的话题，而我作为一名最终用户而言，我可以自己动手修角落里的 bug，还能用上各种奇怪平台（想是树莓派 32 位 arm）的 build，这种自由度夫复何求。

说道开放性，最后我要吐槽一下 C# 工具链的协议问题。.NET Core 全面开源了，然而工具链中依然存在微软的专有软件，比如做 code coverage 的 Microsoft.CodeCoverage 和 C# 的调试器 vsdbg。后者甚至禁止用于 Visual Studio 系列以外的软件，包括 VSCodium（三星有接口兼容的实现，建议用那个替代）。这绝对是历史的倒车……而这严重影响了 C# 在我司内部的 adoption，我感到很不开心……

参考

1. ^ https://zh.wikipedia.org/wiki/Unix%E5%93%B2%E5%AD%A6#McIlroy%EF%BC%9AA_Quarter_Century_of_Unix

2015 年 4 月 29 日的 Build 大会上，微软发布了 Visual Studio Code 第一个预览版本。短短五年不到的时间里，VS Code 高速成长。

根据 2019 年 2 月的 PYPL Top IDE index 的排名，VS Code 的涨势迅猛，在所有编辑器与 IDE 中排名第六，领先于其他主流的代码编辑器：Sublime、Atom 和 Vim。可以说是已经在代码编辑器中拔得头筹。

在 Stack Overflow 的 2019 年开发者调查中，VS Code 成为了最受欢迎的开发工具，并遥遥领先其他的开发工具。

那么，VS Code 为什么能这么成功？有哪些地方是开发者所喜爱的呢？让我们从各个方面与 Sublime、Atom 和 Vim 比较下，逐一分析。

学习曲线

对于任何人来说，特别是新手，一个工具的学习曲线也会影响到它的受欢迎程度。还记得 Stack Overflow 上著名的问题之一："How to exit the Vim editor?" 吗？它已经有接近两百万的访问量。 VS Code、Sublime 和 Atom 在学习曲线上，一定是遥遥领先于 Vim。同时，VS Code 的使用文档相比于其他编辑器也是做的最好的，无论是“快速入门”还是每一个功能的使用，在官网上都写的一清二楚有条有理。官网还提供了 PDF 版的键盘快捷键参考表，让开发者轻松上手。此外，考虑到一些开发者是从 Vim、Sublime、IntelliJ 或是其他开发工具转来的，依旧习惯于原来开发工具的键盘快捷键。VS Code 也提供了各种键盘映射的插件，让你可以在 VS Code 中继续使用不同开发工具的快捷键，而不用重新学习 VS Code 的快捷键。

用户体验

VS Code 提供了许多良好的开箱即用的用户体验。与 Vim、Sublime 和 Atom 一样，VS Code 都提供了代码编辑的体验。此外，VS Code 在保持其轻量级代码编辑器的前提下，还内置了一些 IDE 中会有的重要功能：

• Terminal：内置的 Terminal 使得开发者可以直接在 VS Code 中快速地运行脚本，而不需要在 VS Code 和系统的 Terminal 之间来回切换。
• 调试器：直接在 VS Code 中调试代码，断点、call stacks、交互式的 debug console，使得调试变得异常轻松。
• 版本控制：开箱即用的 Git 支持，让你方便地进行文件更改比较，管理你的源代码。

特别是对于前端开发者来说，VS Code 有着非常好的支持。除了对 JavaScript 的智能提示、重构、调试等功能的支持，像 HTML, CSS, SCSS, Less 和 JSON 这些前端技术栈，都有着很棒的支持。

曾经在一些用户体验上，VS Code 的用户体验也有不足之处。比如，曾经 VS Code 的设置页面的体验就没有 Atom 好，Atom 有着图形化的配置界面，而 VS Code 是基于 JSON 文件的。VS Code 对此也是听取用户的反馈，增加了图形化的配置界面，也保留了基于 JSON 文件的配置方式，满足了不同人群的使用习惯。

开源

开源对于一个产品的长期发展极为重要。在四款编辑器中，Sublime 是闭源的，VS Code、Vim 和 Atom 都是开源的，而 VS Code 可以说是开源做的最好的。

VS Code 不仅仅是把代码开源出来。而是把整个产品的开发过程建立于开源之上，与整个社区深入合作，倾听用户在 GitHub 上的反馈，使 VS Code 越做越好：

• 每一年，VS Code 团队都会在 GitHub Wiki 发布 Roadmap ，列出一整年的规划图。
• 每个月初，在产品设计阶段，VS Code 团队会在 GitHub Issue 上会发布 Iteration Plan ，列出这个月会做的每一个功能，每一个功能基本会对应一个 GitHub Issue，你可以看到详细的设计以及 mockup，并且可以提出你自己的见解。
• 每个月末，临近产品发布，你可以在 GitHub 看到 Endgame 了解到 VS Code 是如何进行产品测试与发布的。

不仅代码开源，VS Code 整个产品的计划，设计以及发布管理都是“开源”的：每一个阶段对每一个用户是公开透明的，你不仅可以开 Issue，发PR，你甚至也可以参与到每个功能的设计与讨论中去！

性能

天下武功唯快不破。相信从 IDE 转投 VS Code 的童鞋，一定是对 VS Code 的性能非常满意。同为基于 Electron 开发的产品，VS Code 在性能的优化上要比 Atom 领先许多。当然，我们必须承认的是，在速度上 VS Code 与 Vim 和 Sublime 相比，还是有略微的差距。但是，我们依旧能看到 VS Code 不断的在性能上的优化。从插件进程与主进程的隔离、插件的延迟加载，再到 Text Buffer 的优化，提升大文件的加载与编辑速度，减少内存使用率。我们看到了 VS Code 的不断进步。

插件

VS Code 有着丰富且快速增长的插件生态，如今，已经有超过一万个插件。不仅有中心化的插件市场，而且在 VS Code 编辑器里也可以轻松搜索插件，直接进行安装与管理。相比之下，Sublime 只有 5000 不到的插件，而且在编辑器里不能很方便地搜索管理插件；Vim 插件虽多，但因为没有一个中心化的插件市场，查找插件很麻烦；Atom 有 8000 多的插件，比 VS Code 少一些，虽然在编辑器内也是可以查找插件，但 VS Code 的搜索和浏览功能做的要比 Atom 要好。

此外，VS Code 还推出了 Extension Packs，方便开发者一键安装多个插件。比较出色的 Extension Pack 有 Java Extension Pack、PHP Extension Pack、Vue.js Extension Pack 等，使得 VS Code 秒变 IDE。

生态

VS Code 不仅仅是一个代码编辑器，它有着强大的生态。VS Code 把它的许多重要组件抽离出来，成为大家都可以复用的开源产品，与社区合作，把产品越做越好：

• Language Server Protocol ：它是 Editor/IDE 与语言服务器之间的一种协议，可以让不同的 Editor/IDE 方便嵌入各种程序语言，允许开发人员在最喜爱的工具中使用各种语言来撰写程序。Eclipse, Atom, Sublime Text, Emacs 等主流 Editor/IDE 都已经支持了 LSP。
• Debug Adapter Protocol ： DAP 与 LSP 的目的类似，DAP 把 Editor/IDE 与 不同语言的 debugger 解耦，极大地方便了 Editor/IDE 与其他 Debugger 的集成。Eclipse, Emacs, Vim等已经支持了 DAP 。
• Monaco Editor ：作为 VS Code 的核心组件，Monaco Editor 在 GitHub 已经拥有了超过一万三千个 star 。国内比较有名的比如 Cloud Studio 和 Gitee Web IDE 都使用了 Monaco Editor。

VS Code 作为 Visual Studio Family 的重要产品，与 Visual Studio IDE 一样，也有两大重要的功能：

• Visual Studio Live Share：极大地方便了协作编程：实时共享代码编辑、跟随光标、团队调试、分享本地服务器、共享终端等等。
• Visual Studio IntelliCode：通过 AI 赋能，根据上下文给出编程建议和智能提示，提高开发者的效率。

此外，还有 2019 年微软在开发工具领域最重磅的产品 —— Visual Studio Online。

未来

VS Code 快五岁了，他还是个很年轻的编辑器。未来的路很长，相信他会越来越好，成为更多开发者所喜爱的开发工具。

最好，欢迎大家围观我出版的书，一起学习 VS Code 的强大，带你快速玩转 VS Code！