一起来聊聊关于WebIDE的实现
2023-01-10 12:05:28 程序员客栈

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


(资料图)

(本篇内容较多,戳一戳下方点赞收藏,下次不迷路~)

一、什么是WebIDE

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

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

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

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

Web更多是从使用它的产品形态以及技术实现上来界定的。

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

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/

相关新闻: