前言：一些运行在 Kubernetes 中的复杂微服务架构是 CPU 和内存密集型的（AI 场景下的算法调优过程是 GPU 密集型），在某些情况下编译或测试可能非常耗时且占用大量资源。然而大多数工程师的标准设备是笔记本，有 CPU 和内存的限制。云端开发环境具有动态分配计算资源的特性，能够很好的解决上述需求场景。近些年也出现了一些令人兴奋的云端开发解决方案，比如：GitHub Codespaces、AWS Workspaces。而这些云端开发解决方案都离不开一个 Web IDE，它是连接工程师和远程环境之间的桥梁。
本文探讨 Web IDE 领域全景以及个人对于 Web IDE 领域的一些思考。
在 IDE 领域，VS Code 是目前的领先者：
(Stack Overflow Developer Survey 2022)
在我们往前回顾编程语言及其对应的软件架构的发展历史，从 C/C++，Delphi，到 Java，JavaScript（TypeScript），从单体的 CS 架构到 BS 架构到现在比较流行的微服务架构，每一个时代都有一个相对一统的软件架构，到如今比较一统的 K8S 架构。但是我们发现无论软件架构如何变化，编程语言的百花齐放也没有改变对应的编程工具（IDE）的相对稳定甚至我们可以看到现在编程工具（IDE）是在不断收敛的。就比如 Java 语言来说，从之前几年还在流行的 JBuilder，NetBeans，发展到现在 IntelliJ IDEA 几乎是一家独大了，Eclipse 也在不断萎缩；再比如前端领域从之前的 Notepad ++、Sublime Text、Atom，发展到现在几乎也是 VS Code 一家独大了。云原生来了，微服务来了，但是我们使用的编程开发工具还是这几个常见的。
可以说目前全球范围内编码工具的主要供应商只有两个，微软的 VS 系列以及 JetBrains 的 IntelliJ 系列。微软开源了 VS Code 的源码，现在大量的 WebIDE 其实也是基于 VS Code（或部分借鉴 VS Code 中的能力，比如：Manaco editor、LSP、DAP）进行的上层定制和演化。从大的角度上来看，编程这个事情所依赖的开发工具的交互形态，无论是基础的编辑器体验、还是后续的调试、代码管理等体验基本是趋于一致的。至少从目前来看，还没有出现一个颠覆性的产品去重新定义一个编程语言的开发工具的新型交互使用形态。
随着云计算在最近几年的长足进步，云端开发概念越发的流行，业界也纷纷出现了一系列云端的开发工具（我愿意称之为 Cloud IDE），但是目前 Cloud IDE 的基本形态停留在把本地 IDE 的能力搬到浏览器中，所以其实目前为止 Cloud IDE 的能力基本是等同于 Web IDE 的。我认为这两个是应该有区别的，具体的想法后文中再探讨。
这里还是先停留在 Web IDE 领域继续探讨：Web IDE 虽然很多公司、机构在研发，但是在调研一圈之后我们发现大部分 Web IDE 其实都是基于 VS Code 的衍生物，而这也是因为 VS Code 本身就是使用 Web 技术构建的，当然 VS Code 良好的架构分层也让 VS Code 天然能够更快的支持其基于 Web 浏览器的使用。所以这里先着重介绍 VS Code。
关于 VS Code
Erich Gamma（VS Code 创始人）的团队在编辑器和成熟 IDE 之间取得了适当的平衡，构建了一个精简但功能强大的产品。
Erich Gamma 对于 VS Code 的定位是一款介于编辑器和 IDE 之间的工具，除了拥有编辑器常规的编辑功能之外，还提供了一定的代码理解能力以及基于该能力提供的代码提示功能，甚至能提供一些静态检查和重构功能。VS Code 和 TypeScript 联合研发了 LSP（Language Service Protocol），基于 LSP，任何语言都可以实现符合 LSP 协议的语言服务，任何编辑器也能实现基于 LSP 语言服务提供出来的语言理解能力，从而提供超越简单编辑器的编辑体验。
VS Code 底层使用的 Monaco Editor 就是通过 LSP 协议，配合 VS Code 提供的 Extensions 定制能力，赋予了 VS Code 插件进行各种语言编辑能力的定制。VS Code 自身仅仅支持 html/json/css/javascript/typescript 等有限几门语言的能力，这也保证了 VS Code 本身相对于 IDE 足够小的体积和更快的安装速度，用户可以通过安装插件的形式让 VS Code 支持更多的语言能力。
对于开发者来说，除了基础的编辑能力之外，代码的调试功能是一款 IDE 必不可少的工具，这也是一个 IDE 与编辑器工具之间的能力分水岭，往往 IDE 都具备了代码调试功能，而很少编辑器工具具备此能力。对于一门语言的调试功能来说也面临着跟编辑能力相同的问题，令人沮丧的是市面上那么多的编辑器/IDE，将新语言的调试器添加到编辑器/IDE 中是一个繁琐且庞大的工作，这项工作无法轻易的分摊到多个开发工具上，因为每个开发工具使用不同的 API 来实现相同的功能。DAP（Debug Adapter Protocol）调试适配协议背后的想法是将开发工具的调试支持与调试器或运行时通信的方式抽象为一个协议。DAP 可以为开发工具实现通用调试器，该开发工具可以通过调试适配器与不同的调试器进行通信。调试适配器可以在多个开发工具中复用，这大大减少了在不同的开发工具中支持新语言调试器的工作量。DAP 是调试器提供商和开发工具的双赢。
相对于 IDE 完整但臃肿的功能，VS Code 重点围绕“编辑器 + 代码理解 + 调试”进行打磨，做到这个核心功能足够好用，这个形态下的 VS Code 保证了其核心产品的轻量和高性能。在此基础之上，VS Çode 通过对外暴露 Extension API 来赋能插件开发者进行 VS Code 功能的扩展，截止目前为止，VS Code Marketplace 中已经有超过 40000 个插件。
如果用一句话总结 VS Code 为什么能够获得如此大的成功，那就是：VS Code 在功能上做到了够用，体验上做到了好用，更在拥有海量插件的情况下做到了简洁流畅。
上面这么大篇幅介绍了 VS Code，作为最受欢迎的一款 IDE 产品，除了在功能上做到了够用和好用之外，架构上它也做到了足够的灵活性能够支持 Web 端的部署形态。目前市面上已经开放使用的 GitHub Codespaces 和 vscode.dev就是基于 VS Code 部署的 Web IDE。
为何 VS Code 天然支持 Web 端的部署形态
关于这个话题，不得不提一下 VS Code 的发展历史：
团队负责人：Erich Gamma，JUnit作者之一，《设计模式》作者之一，Eclipse 架构师。2011 年加入微软，在瑞士苏黎世组件团队开发基于 Web 技术的编辑器，也就是后来的 monaco-editor。VS Code 开发团队从 10 来个人开始，早期团队成员大多有 Eclipse 开发团队的背景。
Erich Gamma 早期在微软曾经疯狂的寻找公司内部的落地场景，比如 Visual Studio Online 的在线 Code Diff 页面，TypeScript 官网的 Playground 编辑器，OneDrive 代码文件，Edge 浏览器 Dev Tool 的代码浏览等。伴随着微软整个开放、开源跨平台等风潮，Erich Gamma 敏锐的决定将产品从 Browser Based IDE 转向跨平台的 Desktop IDE，但是仍然使用 Web 技术，结合 Electron，VS Code 团队花了六个月使用 Electron 将 Web 编辑器桌面化，又花了六个月将整个 IDE 插件化，最终 VS Code 成为了一个流行产品的同时也成为了一个典型的 Electron 客户端开源项目。
最早的 VS Code 完全使用 Web 技术（TypeScript/Html/CSS）构建（整个 VS Code UI 都是使用 Web 技术来编写），这也让其具备了天然可以在浏览器中运行的能力。后期改造到 Electron 架构之后，VS Code 也针对客户端、浏览器端做了分层架构设计，使得 VS Code 既可以运行在客户端也支持在浏览器端运行。
VS Code 及其周边 Web IDE
上面介绍了 VS Code 的架构特点，决定了其具备了较小代价进行 Web 端的部署能力；相对来说，JetBrains 的 InteliJ 目前为止尚未宣布其支持 Web 端的部署形态，具体来看目前市面上 Web IDE 形态的产品大部分是 VS Code 的衍生产物：
VS Codium
VS Codium 是 VS Code 的一个分支，它的功能与 VS Code 完全相同，唯一不同的是，VS Codium 不跟踪你的使用数据（关闭了 VS Code Telemetry 功能）。VS Codium 初心是针对纯粹的开源主义者提供一个完全不受微软绑定的 VS Code 版本。
除了在 Telemetry 功能上的差异之外，VS Codium 允许你定制 VS Code 的图标：
Code Server
Code Server 是 Coder Technologies Inc, an Austin TX company 公司开源的一个基于服务端的 VS Code，只要服务器端配置好 Code Server，就可以在任何浏览器上使用 VS Code。
这个项目目前有点尴尬，因为微软于 2022 年 7 月 7 日宣布了 VS Code Server，它简直就是一个 Code Server 的平替产物，并且还是微软官方支持的。VS Code Server 是一项可以在远程开发机器上运行的服务，例如桌面 PC 或者虚拟机（VM）。它允许开发者通过 vscode.dev URL 从任何地方安全地连接到这个远程计算机，而且不需要通过 SSH。
不管是 Code Server 还是微软官方支持的 VS Code Server 方案，允许开发者已新的方式使用 VS Code：
-
在 SSH 支持可能受限的远程计算机上进行开发，或者你需要基于 Web 进行访问
-
在不支持桌面版 VS Code 的机器上进行开发，比如 iPad/平板电脑或者 Chromebook
-
体验所有代码都可以在浏览器沙箱执行的安全优势
OpenVSCode Server
OpenVSCode Server 从名字上就跟 Code Server 非常相近，而实际上他两做的事情基本类似，从 OpenVSCode Server 的官方描述：
This project provides a version of VS Code that runs a server on a remote machine and allows access through a modern web browser. It's based on the very same architecture used by Gitpod or GitHub Codespaces at scale.
这是一套非常类似于 Code Server 的解决方案，这也是目前 Gitpod 公司采用的技术方案。
Eclipse Theia
Eclipse Theia 是一个比较特殊的存在。首先它不是一款 IDE 产品，而是一款 IDE 开发框架，这是它与 VS Code 最大的区别。Theia 和 VS Code 之间存在许多的相似之处，Theia 创建之初就以 VS Code 作为蓝图，甚至直接重用了许多 VS Code 的概念和重要组件代码，包括：Monaco Editor、LSP、DAP 等。Theia 创立的初衷是希望能够提供一个更具扩展性和适应性的 VS Code，技术架构上也是按照更加可扩展、模块化的方式设计的。
相对于 VS Code 只能通过 VS Code API 进行功能扩展，Theia 提供了一种更底层的扩展形式；VS Code 的扩展能力受限于 VS Code API，Theia 提供的基于 DI 形式进行底层服务调用和覆写等能力，让 Theia 扩展理论上可以实现任意功能的扩展。在 UI 层面的定制型上两者体现出来的差异会更大，VS Code 插件无法定制 UI，而 Theia 扩展理论上可以完全定制 UI。
综合来看两者都有各自擅长的领域，一般认为：
-
如果你想提供一些专注于代码的工具，并希望尽可能多的开发人员在他们现有的 IDE 中使用它，那么基于 VS Code 是一个更好的选择。
-
如果你想为客户或你自己的开发人员提供白标产品，该产品针对特定用例量身定制，并且可能包含比代码编辑器更多的功能，那么使用 Theia 是一个更好的选择。
重点再介绍下 Eclipse 推出的 Open VSX，Open VSX 是为了解决 VS Code Extension Marketplace 的访问限制（VS Code Extension Marketplace 只开放了微软产品的可访问和可使用权限），微软的使用条款禁止任何非 Visual Studio 产品的访问。Gitpod 采用了一种方案，用户可以上传 .vsx 文件来安装扩展，但是这个方案会导致不必要的开销，用户必须从 Github 下载文件，然后将他们上传到 Gitpod。微软也禁止了从 Marketplace 下载扩展用于微软之外产品的任何用途。而大多数扩展是有社区开发并在宽松的开源许可协议下发布的，在具有次类限制性服务条款的系统中分发和访问这些社区拥有的 扩展的要求似乎是并不正确。
Open VSX 的目标是通过在供应商中立的组织 Eclipse Foundation 托管一个开源扩展注册来解决这个问题，最终通过 Eclipse Open VSX Registry项目来做到这一点。
Open VSX 除了提供一个公开托管的、供应商中立的扩展程序注册之外，Eclipse 还将代码作为开源使用。这样你可以安装一个私有的服务并提供公司内部使用。并且 Open VSX 也不强迫必须要将专有扩展发布到公共市场，但你仍然可以完全控制它们的可读性。这与 npm、Cargo 和 Maven 等其他生态系统的常见做法类似。
截止目前为止 Open VSX Registry 公共市场中已经存在 2435 个 VS Code 扩展插件。
其它
集团内也有类似的 WebIDE 解决方案：OpenSumi——一款帮助你快速搭建本地和云端 IDE 的框架。定位非常接近于 Theia，其实它的内部也有大量的架构设计参考了 Theia。目前支付宝小程序开发工具、淘宝开发者工具、Gitlink 开源代码托管平台等基于 OpenSumi 搭建。
结合上述 Web IDE 领域的众多产品的现状，下面这张图可以以一个较为全面的视角阐述当前 Web IDE 产品体系架构：
关于 Web IDE 未来形态的畅想
Coding 创始人张海龙曾经发表一篇文章《Cloud IDE 是不是一个伪命题》，他从 IDE 历史分析、IDE 场景分析，并从 PDA 这一系列产品的宿命中反思 Web IDE/Cloud IDE 的形态，首先他认定当前 Web IDE 所呈现出来只是将本地 IDE 搬到云端的形态并不是一种 Cloud IDE 应该是的最终形态，因为只是一种使用端的转移并不能解决软件工程的三大难题：
-
开发效率
-
开发质量
-
维护成本
当然作者最终并未给出他觉得 Cloud IDE 应该是的一种形态，但是他给了一个方向性的个人判断：Cloud IDE 可能就不应该是一个 IDE 的形态。
其次，他还是肯定了云端开发将是软件开发的下一站，而云端开发一定需要一个 Cloud IDE。
上面我们简单回顾了下 IDE 的历史，总体来看 IDE 虽然曾经有百花齐放的阶段，但发展至今阶段整体是在不断地收敛中，这也符合了互联网时代的“头部效应”现象（头部效应指个体一旦处于某一领域或系统的头部位置，往往能够持续自己的优势，影响力也会不断扩大，逐渐呈现强者恒强的趋势）；尤其针对在 Web IDE 领域，VS Code 更加展现了其绝对的统治力，虽然前期 VS Code 本身并没有发展 Web IDE 方向，但是自从微软收购 Github 之后，VS Code 找到了一个 Web IDE 可实际落地的场景（Github Codespace），VS Code 近期在 Web IDE 方向持续的发力：
-
Github Codespaces
从前面的 Web IDE Landspace 全景图中，我们更是可以肉眼可见 VS Code 对于 Web IDE 领域的影响，可以说 VS Code 就是当前 Web IDE 系列产品的基础设施，加上与 Github 的强强联合之后，Web IDE 领域微软的 VS Code 将会呈现更强的统治力。
我们再来看看 VS Code 的周边：
相比于 VS Code 在 Web IDE 领域的持续发力，曾经的 IDE 王者 JetBrains 公司目前已经处于追赶者的身位，尤其是在 Web IDE 领域，JetBrains 至今还没有推出一款产品，JetBrains 最新推出的一款轻量级编辑器——Fleet。这里稍微展开介绍下 Fleet：
Fleet 的目标是为了满足那些可能只需要一个编辑器，但也同时需要 IDE 中的强大功能的场景，想要使用单一工具而非多个专用工具的用户提供不同的体验。可以说这是跟之前的 JetBrains 完全颠覆性的新玩法，之前的 JetBrains 擅长为每一种领域语言打包一个全新的 IDE，比如：WebStorm/PhpStorm 等，对于一些跨领域语言开发者来说，需要切换不同的 IDE 进行开发，考虑到 JetBrains 并不是一个轻量级的产品，这个成本开销对于一般个人电脑来说还是比较大的，而 Fleet 采用了一种多语言架构，可以在一个 Fleet IDE 中同时支持多种语言的开发。
Fleet 使用原生技术 skiko（Skija + AWT）写界面，用了 Kotlin 和一点 Rust，不是 JetBrains Compose，因为 Fleet 项目开启时还不存在 Compose。
Fleet 给我带来了几个惊喜：
第一个惊喜：分布式架构
Fleet 采用了分布式架构，前端、后端、文件系统都是分离的，这三者使用 Workspace 这个组件组织到一起，见下：
这个架构应该说是比较先进的：
-
前端（Frontend）：提供用户界面，解析文件，并为支持的文件类型提供有限的高亮显示。一个工作区可以有一个以上的前端连接，折让 Fleet 具备了协作开发能力。
-
工作区（Workspace）：主要在有几个前端的情况下维护前端的共享状态。
-
后端：一个无头服务，完成繁重的工作：索引、静态分析、高级搜索、导航等。
-
FSD（Fleet 守护进程，Fleet System Daemon）：一个 Fleet 代理，它被用来构建项目，运行代码，执行终端命令，并代表 Fleet 在目标环境中执行其他动作。
这种架构让 Fleet 支持如下场景：
-
协作开发：多个用户在同一个开发环境中工作并相互交互
-
远程/云 IDE：托管在其他地方的开发环境，例如远程机器、集群或云
-
多目标文件系统：开发和运行一个涉及多台机器或容器的项目，例如：一个基于微服务的应用程序
第二个惊喜：Space 提供了编排支持
Space 提供了编排支持，可从源仓库轻松启动远程服务器实例，支持使用 Dockerfile 进行自定义
第三个惊喜：全方位支持团队协作
同团队的人可以同时开发同一个项目，编辑同一个文件或不同文件，运行测试、访问终端以及执行协作 IDE 所期望的其他功能
此处为语雀视频卡片，点击链接查看：f767894e-50f8-11ec-a46f-2a245bec641d.mp4
VS Code 其实也支持协同编辑，这也是通过扩展实现的（VS Live Share），不只是代码编辑可以协作，甚至可以共享终端以及调试：
这是一个很牛的技术，但事实证明协同编辑是一个伪命题，并没有很大的需求场景。
其中需要注意一个点是，Fleet 选用了微软的 LSP 架构来支持多语言的编辑体验，一方面这说明了 LSP 架构的先进性，另一方面我们也可以推测 Fleet 将会在 LSP 这个体系下不断添砖加瓦（JetBrains 的语言支持能力还是强于 VS Code），基于 LSP 架构的语言编辑体验将会再往前推进一步。而且我也相信，基于相同出发点设计的 DAP 协议也会被 Fleet 采纳并应用。
结合上述所述，下面我简单总结下我对于 Web IDE、云端开发技术领域未来发展的看法：
-
Fleet 的目标并不是取代 VS Code，而是瞄准了 Cloud IDE 开发的市场
-
分布式架构将会大行其道，中间通过 LSP/DAP 甚至更多的协议解耦 IDE 服务端和客户端，未来服务端（包括 Language Server、Debugger 等能力）技术方案将会更加一统，IDE 前端更加百花齐放已支持更多的 IDE 垂直场景
-
重点说下 IDE UI 领域，目前 VS Code 和 JetBrains 类似于淘宝和京东的区别，VS Code 类似平台，而 JetBrains 是大一统的解决方案，体验上 JetBrains 还是会领先 VS Code 一步，但是 VS Code 的开源生态是其杀手锏。个人认为这两种形态将会持续存在，但是这个领域一定会变得更加开放，因为 UI 的定制性需求是千人千面并且相对来说是更加具有发展性的
