本期聊聊WebIDE的概念和在各种客户端的应用场景；一起探讨在社区里比较主流的WebIDE实现的方法模式与对比，一起来了解WebContainer思路下的WebIDE。
（本篇内容较多，戳一戳下方点赞收藏，下次不迷路~）
(资料图)
IDE基本上技术同学每天都会接触到，比如VS Code就是一个比较偏向IDE的产品，因为VS Code本身内置了很多开发功能，还可以通过插件来实现调试、代码补全、代码提示等各类功能，借助这些功能就可以比较好的做出一个集成开发环境（IDE）。
WebIDE相当于IDE产品的Web版。把用户界面这一端放到了浏览器里面，通过导航能够在浏览器里面打开的，且界面和本地的客户端版本几乎是一样的。
有一个WebIDE比较知名的产品是CodeSandBox，同学写一些demo或者做小的功能需要分享给别人，就会用类似的网站；和它类似的还有Codepen，也算是一种WebIDE，它也是把主要界面的操作、交互、开发等放在浏览器里面去做的，这是在业界比较出名的两个例子。
接下来从概念上来看一下构成WebIDE的两个部分：Web和IDE。
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的一些应用场景以上阐述了 WebIDE的相关概念。从下图（图2-1）也可以看到其实是有一个过渡过程，每一种产品可能会位于坐标轴的某位置。因为不同产品使用的技术战略不同、面向对象不同，所以处于不同位置。它们并不是一个两级对立的状态。
接下来再聊聊WebIDE的应用场景，之前也会有很多同学认为有了客户端的程序来开发代码，在本地能开发的东西也很多，那是不是就不需要其他的东西了？这里带大家看一下业界有哪些产品以及这些产品是如何去定位的，在它们的场景下做了哪些偏WebIDE方向的事情等。上图坐标轴（图2-1）代表的是研发场景的量级。
轻量级指的是开发频次较少，每次开发时间较短，开发代码量比较简单。比如一个月开发一两次左右，每次开发1-1.5个小时，源码也不会出现这种几十万行的源码。重量级的场景是指每天可能都需要迭代开发一些项目，且源码量非常巨大，代码也极其复杂，整个开发环境很庞杂。所以在整个坐标轴上的不同位置都会有不同的场景和产品。
（一）轻量级的应用场景最轻量级的场景第一个便是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的主要实现思路与对比接下来看一下现在开源社区里面主要的实现思路都是怎样的，以及大家都是怎么做WebIDE。
首先来看一下上图（图3-1），看看界面核心部分也就是WebIDE需要具备哪些能力。比如把上面的导航栏盖掉，会发现下面的部分和本地IDE（Desktop IDE）很类似，所以来看一下这样一个IDE需要具备哪些必要的功能。
（一）IDE需要具备的必要功能（以前端为例）首先第一个需要有文件系统。第二部分需要在编辑器非常核心的中部区域能够编写代码。最基础要有个编辑器。第三个部分是需要能支持依赖包的安装。因为我们在写前端项目时，应该都不会编写这种在编译时、运行时完全不需要第三方依赖的项目（除非场景极其定制收敛）。像上述（图2-1）的坐标轴右侧偏重型的产品和场景，肯定会需要依赖安装。第四点在写代码时需要做代码编译才能运行。现在写的代码都已经不是原始的js和css，像是vue模板、jsx；也很少有人直接写css，会选一个Less或者Sass等；还要做各种编译、需要兼容各个浏览器及各种版本。所以现在写的代码一定要做编译才能运行，因为几乎现在没有项目是直接写纯粹的最原始代码。需要页面预览。左侧中间这里（图3-1）有一个浏览器，可以用来预览现在写到的页面，前端希望能够写完后立刻看到页面上的东西和效果。因为在编写复杂样式时，可能无法准确完全的一步到位，会需要通过不断调校，所以这也是很关键的一个部分。与此相关的是热更新。我们现在可能会有很多种状态库，即使不使用状态库，组件也会有自己内部的状态，如果页面全部reload，就会造成直接丢失。所以前端标配就是能够做模块的热更新，能够局部刷新某个模块，这也是一个比较标配要求。还有一个是实时性。通过使用Web技术来编辑保存，保存完之后刷新页面需要及时，页面刷新的实时性体验是否流畅这点也是比较重要的。在本地编译器上编译过程可能会稍微慢些，但客户端上的操作还是比较流畅的，体验还是不错的。（二）业界内WebIDE的实现思路下面来看一下在上述提到的基础功能上，在业界的实现思路上是如何做的。
1、VS Code和Theia第一个实现模式下比较著名的两个产品，一个是左边（图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里面的。
在实时性上主要取决于两点：一是通信是否会有延迟，是否会有带宽问题，以及服务稳定性如何；第二点是由于涉及前端编译运行，所以分配的资源是否足够也会有影响。
2、CodeSandbox下面再说第二个实现思路是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思路下的WebIDE最后来说一下 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/