全球焦点！一起来聊聊关于WebIDE的实现

本期聊聊WebIDE的概念和在各种客户端的应用场景；一起探讨在社区里比较主流的WebIDE实现的方法模式与对比，一起来了解WebContainer思路下的WebIDE。

（本篇内容较多，戳一戳下方点赞收藏，下次不迷路~）

IDE基本上技术同学每天都会接触到，比如VS Code就是一个比较偏向IDE的产品，因为VS Code本身内置了很多开发功能，还可以通过插件来实现调试、代码补全、代码提示等各类功能，借助这些功能就可以比较好的做出一个集成开发环境（IDE）。

(相关资料图)

WebIDE相当于IDE产品的Web版。把用户界面这一端放到了浏览器里面，通过导航能够在浏览器里面打开的，且界面和本地的客户端版本几乎是一样的。

有一个WebIDE比较知名的产品是CodeSandBox，同学写一些demo或者做小的功能需要分享给别人，就会用类似的网站；和它类似的还有Codepen，也算是一种WebIDE，它也是把主要界面的操作、交互、开发等放在浏览器里面去做的，这是在业界比较出名的两个例子。

接下来从概念上来看一下构成WebIDE的两个部分：Web和IDE。

与它相对的是像IDEA这种偏客户端的产品。VS Code虽然也是客户端产品，但是它本身用了比较多的Web技术来构建产品的应用，里面混合了一些Web技术；CodeSandbox是偏Web端技术的，是Web端承载的这样一种产品。那么Web的定义就是在技术实现上面去界定的，它也不是两级化的，从Desktop到Web我们可以看到它有各种中间状态，通过分析哪些组件、哪些部分是如何来运用Web技术，可以让我们更好地来分析IDE产品。

与它更相对的是一个偏极端的像Editor这种的编辑器，比如我们可以直接用一个文本编辑器打开一个代码模块，这就是一个最简单的Editor。再比如js这种脚本语言，理论上可以用编辑器直接写代码，写完之后储存成js放到网站上运行就可以了。

更复杂的IDE产品比如Android Studio，它不仅包含写代码和各种预览功能，还可能会包含一些监测应用的性能等功能。

所以在IDE的维度上，需要考虑产品功能的完备程度，以及在开发过程中涉及到的各种功能是否都集成在一个载体里。集成的越来越丰富，越能形成一个集成开发环境，IDE也就更丰富。

以上阐述了 WebIDE的相关概念。从下图（图2-1）也可以看到其实是有一个过渡过程，每一种产品可能会位于坐标轴的某位置。因为不同产品使用的技术战略不同、面向对象不同，所以处于不同位置。它们并不是一个两级对立的状态。

接下来再聊聊WebIDE的应用场景，之前也会有很多同学认为有了客户端的程序来开发代码，在本地能开发的东西也很多，那是不是就不需要其他的东西了？这里带大家看一下业界有哪些产品以及这些产品是如何去定位的，在它们的场景下做了哪些偏WebIDE方向的事情等。上图坐标轴（图2-1）代表的是研发场景的量级。

所以在整个坐标轴上的不同位置都会有不同的场景和产品。

最轻量级的场景第一个便是Playground。比如我写了一个库，或者像Golang之类的各种语言，在推广给新手运用时会有一个Playground，它会有一个地方可以直接写代码片段，然后在旁边输出结果。这实际上也是一个非常轻量级的WebIDE的应用场景。

坐标轴下面列了一些对应产品，像runkit在NPM会用到。比如在NPM官网上，每个包主页的右下角应该可以看到一个runkit的按钮，点击可以立刻打开一个Playground来测试/试用这个包。

第二个则是Demo的编写。比如最近新出的一些前端开源库，在它的网站上就会提供一些轻量级嵌入的WebIDE，可以直接写代码，然后用库看看效果如何。与之类似的还有很多组件库，传统的组件库肯定是先在页面上直接把组件代码写好，然后基于这段代码渲染出可交互的组件，让用户能看到。但缺点就是用户无法自主修改调用代码，如果想试另一个API或者参数值，就无法调整。所以更好的方式是能够直接编辑代码，以及编辑完之后能直接渲染出如何使用这个组件，那么用户很快能知道组件是否符合要求，以及组件的展示情况是否能够满足要求。

比较常用的产品有CodeSandbox。

类似轻量级的还有一些做线上代码教学的产品。比如学一些现成的编程课程，或者是做一些线上的面试时，会需要写代码、去运行等，这些情况其实都是比较轻量的。

常用的产品有scrimba，这是一个比较集成性的产品，它有一些可以交互式的视频，在看视频过程中可以随时随地点到视频里面去编辑代码，编辑完代码运行后，还可以继续回来补看。

还有一个replit，能够写各种语言的代码，然后在线上直接执行，还可以做一些教学等。

偏中型的开发场景一个是静态文档开发站。我们现在常用的是用没有plus的、稍轻些的静态文档工具来开发。

实际写代码时（不是所谓的页面代码），比如markdown类的，再结合开发一些小的自定义组件，这样的一个静态站点就出来了。这个开发频率不会特别高，也不用写太复杂的代码，包括几个组件或有Markdown的文案就可以。

对应的产品有Nextjs Live和Nextjs Web，Nextjs Web也是应用了WebIDE的形态，但是和我们一般看到的编辑器稍有不同，感兴趣的同学可以去深入了解。

还有一个也稍微轻量级的场景—开发组件。开发组件相比于实际项目，代码量肯定会更少，又因为它更加的内聚，所以场景也更加的限定，工具链的复杂度、环境的复杂度等也就会更加简单。

可能只需要集中几十个源码文件，且一个组件的总代码量一般也不超过一两千行。

还有一些low-code的场景，这也可以算是一个轻量的WebIDE，只是和我们预想的通用的WebIDE不太一样，因为low-code的编辑后面还会对接自己的运行时等，集成开发环境会更加的定制性，并不是那种通用代码开发的。

还有像gitpod也是一个比较轻量级的产品。

再偏重一些的场景，例如开发FaaS的项目，有很多云厂商会提供Web端编辑FaaS函数的方式，同时也支持在本地用CLI方式或IDE插件的方式去做。

像autocode，它是一个完全基于云端环境、浏览环境的产品，用户可以在Web的环境里去开发部署，并且它围绕WebIDE把很多的云服务在这做了整合。

最复杂的还是我们平常接触最多的比如在VS Code里面去开发一个复杂的完整项目。

以上是关于应用场景的一些介绍，从上图（图2-1）坐标轴也可以看出，不同的位置都可能有不同的WebIDE实现。因为对功能要求的侧重点不同、面向的产品及需求场景也不同，所以WebIDE的产品覆盖度是比较广的。

接下来看一下现在开源社区里面主要的实现思路都是怎样的，以及大家都是怎么做WebIDE。

首先来看一下上图（图3-1），看看界面核心部分也就是WebIDE需要具备哪些能力。比如把上面的导航栏盖掉，会发现下面的部分和本地IDE（Desktop IDE）很类似，所以来看一下这样一个IDE需要具备哪些必要的功能。

下面来看一下在上述提到的基础功能上，在业界的实现思路上是如何做的。

第一个实现模式下比较著名的两个产品，一个是左边（图3-2）VS Code，另一个是近几年稍新一点的Theia产品。这两个产品在大体的技术路线上是类似的，且这两个产品也都是开源的，完全能看到它的源码。

这里举例说一下Theia这个产品，它的设计和代码目录结构是比较清晰的，VS Code相对会更加复杂，拆分设计没有那么清晰。因为最开始这两个产品的定位不太一样，像Theia可以看到里面都有很多的Package，每个Package对应一个具体的功能模块，且功能模块里面目录结构也是很清晰的，它会有一个叫Browser或Node的目录，模块的层级划分是比较清晰的。

整体实现上，前端部分主要负责UI，每一个模块会对应一个前端的实现。比如ternimal里有各种彩色加速应该如何展示出来。同时还会负责一些交互，比如在ternimal输入的东西如何拿到。中间会通过WebSocket的方式做一个协议。像Theia的话就用JSON做了一个自定义格式的协议，来和服务端通信，让后端对应的模块也就是ternimal的Node.js模块收到对应的执行方法。ternimal的后端模块就会把输入的内容放到对应进行的标准输入里，把标准输出取出，再返回给前端来展示。所以它的层级划分是每个功能模块，大致分成前端（Browser）和服务端（Node），中间有一个标准的协议来通信。

所以它的具体实践上明显分为两层，第一层是上图（图3-5）红框里面的Browser浏览器，它主要负责Web的UI；第二层的是绿框的Server层，Server会依托于后端环境和操作系统环境。整个Server为了做资源隔离就把它放在一个容器里面，相当于每次在前端对应打开一个WebIDE，背后就有一个Container，里面的Server就会做相关的事情，所以文件系统实际在前端主要是展示，最终还是存储在一个Container里面。

再来看代码编辑器，这是一个纯前端的编辑器，一般不会直接和后端交互，现在常用的选择就是三个：Ace、Monaco和CodeMirror6。

Ace是一个非常老牌的编辑器。已经出来有十几年了，所以功能不一定特别完备，它的UI样式也稍微老一些；

Monaco属于中生代，是VS Code本身用的编辑器，然后后来把它慢慢独立出来做。这个东西也是现在做WebIDE，很多人会去选择的一个开源的编辑器；

Code Mirror是更新一点的。Code Mirror本身不是一个特别新的编辑器，也做了也很长时间了。但是Code Mirror6它是一个完全重构的新版本，在5的基础上就几乎重写了一遍，所以这么一个新版本算是比较新的编辑器，支持很多新特性。

关于编辑器这里有一些简单的对比（https://blog.replit.com/code-editors），因为编辑器属于比较高内聚低耦合的产品，所以在做WebIDE时，为了快速启动，选一个开源的产品会有比较大帮助的，不会拉垮整个WebIDE，且接口也比较简洁的。

再下一步是依赖安装，它有个服务端，通过一个通信指令在服务端把安装包装上。代码编译运行也相似，也是在Server端运行，然后Server通过网络协议和Web里的某一页面进行通信。由于有实际的服务端，所以在这个架构下的页面预览、热更新等和本地开发基本是一致的，服务、编译等都是在Container里面的。

在实时性上主要取决于两点：一是通信是否会有延迟，是否会有带宽问题，以及服务稳定性如何；第二点是由于涉及前端编译运行，所以分配的资源是否足够也会有影响。

下面再说第二个实现思路是CodeSandbox。这个思路和前面的技术路线和想法差异比较大，所以需要单独介绍一下。

CodeSandbox本身是一个开源的产品，它把客户端的IDE部分开源出来了，所以可以直接看到它的源码，了解它的各种实现。在它早期发表的文章上也介绍了一些他们在实现WebIDE上面的关键思考点等。虽然技术实现细节有了非常多的迭代，但是它整体的技术思路大致是这个方向。

上图（图3-7）Code Sandbox的图，可以看到右边这个图上看出，它没有像VS Code或Theia分Broswer或Server，因为这些部分全都在 Broswer里，所以它的文件系统是一个基于浏览器内存的文件系统。编辑器这块在技术路线上没有太大的差异，都是直接用开源的产品。

在依赖安装这部分和前两者也有很大不同，因为它没有一个服务端环境，意味着它不能用“正常”的方式安装，同时因为它是一个基于浏览器内存的文件系统，所以即使在某个server安装上这些东西，也需要它搬到浏览器里面来，然后把它放到这个文件系统上去才行。所以在这里有一个服务（图3-7最右侧），专门来处理NPM包，把NPM包代码处理完后直接给前端浏览器返回，再通过接口的方式返回NPM包里面文件内容以及一些其他信息等。

通过这个转换服务，在左侧这里（上图3-7）去搜一个React时可以把React的版本列出来，在下拉框里选中目标后就会通过这个服务，把所有依赖的NPM包里面的代码内容返回到前端，然后前端把它装载到文件系统里面，这样就可以去做依赖安装。

下一块代码的编译运行主要关注绿色这部分（图3-8），这也是重度开发的部分。代码编译会基于开源工具（babel、vue compiler等）来手写一个可在浏览器内运行的打包器。运行则会依托于iframe，把代码放到iframe里面让它去运行和渲染页面。

关于页面预览，iframe并不是真正的去某一个服务端把资源加载进来，它通过前端的方式，可以是 Service Worker 直接拦截返回，或者直接通过前端的通信机制发送代码来加载。热更新这部分的话，肯定需要自己做一些热更新的这种操作，因为它是把工具链这块自己接管的。

实时性上一般没有太大差别，上面可以看到它是一个纯浏览器内部的操作，浏览器主线程会频繁和web worker进行各种通信，所以相比较要去和服务端通信，它的时间可能会要稍微短一点。

这节的最后给这两种模式做个简单对比（图3-9）：

Theia的模式由于需要有服务端的实现，所以在资源开销和运维成本上有劣势；而CodeSandbox由于需要自研工具链，所以在前端这个新框架迭代频繁的领域有较大开发成本，同时由于缺乏服务端能力，能满足的场景也有限，主要还是纯前端的代码编译。

最后来说一下 WebContainer的思路下是如何做IDE的。WebContainer是stackblitz公司提出的一种技术模式，算是第三种模式。目前社区没有开源实现，因为这个是比较核心的技术，所以做这个的stackblitz公司也没有在公开的资料里说过具体的技术细节，只有一些概念。

可以体验下（https://stackblitz.com/），实现原理大致是利用了wasm的特性，将node相关代码进行转换为在浏览器work可以执行的wasm代码，这样在浏览器就支持了node的运行。

WebContainer的核心目标是，既想跑服务端代码（跟VS Code一样），但又不想有服务端容器。

它在这里提了一个概念，把服务端代码运行在一个所谓的WebContainer里，这个WebContainer是完全运行在浏览器里的，这样就做到了类似这样一种架构。

这种架构和Theia对比层级结构很像。Web UI这边可以说大致类似，层级图的下面这部分，在Theia里面是完整跑在服务端的Node.js的环境里的，而在WebContainer 这样的实现下面，就要跑在浏览器里面（图4-2）。由于前端相关的服务端应用基本都依赖Node.js，所以这里非常重要的一个问题就是怎样让Node.js程序能够跑在浏览器里面？如果把Node.js跑到浏览器的问题解决，就解决了很大一部分的技术问题。各种Node.js代码、应用、各种NPM包、构建工具就可以直接跑在浏览器里面，之前需要一个Server环境来做，现在就不需要了。所以在这样一个思路下，就可以把server搬到浏览器里面来做。

它和CodeSandbox不一样，CodeSandbox在绿色部分（图4-2）也就是在Web woker的技术上做了各类技术栈的构建工具链，NPM也需要去单独做处理。

这个对比可以看到二者实现的事情和层级上是不同的。理论上基于WebContainer的方式NPM也不需要再单独处理。如果实现了完整的Node.js运行环境，可以把npm install抛到worker里面去，但是可能会有一些性能和效率的问题。所以做 WebIDE需要定制一个在浏览器里面能够独立运行NPM CLI工具。

这里要涉及三点：第一个是依赖的解析；第二个是怎么去把包拉下来；最后是拉到之后你需要去解包解压。

基于WebContainer模式下的WebIDE能够较好规避前两个模式的缺点（图4-4）：

由于所谓的server也运行在浏览器中，所以资源消耗和运维成本就降为0，安全隔离也不需要docker container这种技术，浏览器自带了沙箱特性。同时由于模拟了Node.js运行环境和基础的shell能力，所以在工具链上可以大量服用前端已有工具包，无需定制开发工具链。

最后总结一下，基于WebContainer的WebIDE在整个应用场景从轻到重上来说，属于是一个它可以处理从轻到重的产品。在轻量级场景下，我们可以用它做playgroud，做demo编写，都是可以的。然后再偏中量级上面的话，可以在它上面运行vuepress或者vitepress（Vue团队做的工具）来进行静态的站点搭建，你可以在这上面直接去开发你的静态站然后联通部署服务。

现在我们是做了一个产品（暂不对外开放），可以进行一些在线Demo的编写、分享，除了运行纯前端组件、包之外，也可以运行一些命令行工具、或者Node.js包。随着开发体验与周边工具（例如git）的补齐，它这种技术模式在这个场景轴上，所能覆盖范围会更长一些。然后本身它内部的各个子模块也可以独立输出出来，像最近CodeSandbox它其实也有意把自己的Sandbox给抠出来，独立出来做一个轻量级的输出，就不整个输出WebIDE这块东西。

（下方 为文章中提到的技术产品和文档链接，感兴趣的同学可点击查阅~）

https://blog.replit.com/code-editors

https://github.com/codesandbox

https://codesandbox.io/post/creating-a-parallel-offline-extensible-browser-based-bundler-for-codesandbox

https://codesandbox.io/post/how-we-make-npm-packages-work-in-the-browser

https://codesandbox.io/post/sandpack-announcement

https://codesandbox.io/docs/environment#container-environment

https://codesandbox.io/post/announcing-codesandbox-containers

https://stackblitz.com/