面向未来的前端开发模式
在之前，给大家介绍过webcontainer这个技术，就是可以让Node.js运行在浏览器中的技术
什么是
webcontainer技术：- Web 已经发展到可以提供本地安装的应用程序的大部分功能的地步。借助WebAssembly的强大功能、现代浏览器 API（如 Web/ServiceWorker 和 SharedArrayBuffer）以及对硬件的访问增加，释放 Web 全部潜力的要素已经创建，原生应用程序和基于 Web 的应用程序之间的界限从未如此狭窄。过去，像Electron这样的解决方案通过为基于 Web 的应用程序创建一个沙箱来访问系统级资源，从而帮助填补了这一空白。围绕WASI 等接口进行标准化，我们实际上可以拥有一个与本机应用程序的功能相匹配的可移植运行时，同时保持我们所期望的 Web 的安全性和一致性。虽然 WASI 旨在带来模块化系统接口，但仍然需要有一个操作系统，供 WASI 模块在浏览器中进行接口。WebContainer 提供了一个为现代应用程序设计的小型便携式容器和操作系统。WebContainer 工作组旨在弥合这一差距，并帮助加速世界向基于 WebAssembly 的计算的过渡。
一切源于我收到了这封邮件，之前在文章里面写过，这个技术可能会颠覆目前的前端开发模式，那到底会怎么颠覆呢？
前端现状的痛
- 依赖管理的痛 :使用某些知名的cli需要用npm或者yarn或者pnpm安装一大堆依赖，我只想写一个helloworld，可能会达到1G的依赖，如果是mac电脑，不用的时候删除这些node_modules文件的话还好，但是windows删除起来，可能会很慢，导致电脑很卡，还会遇到权限问题等等
- 搭建环境困难的痛：先装nodejs、npm,不然项目本地都跑不起来，明明是页面仔，却不得不接触nodejs，对新手不友好，可能还会存在各种不同操作系统的坑
- 工具太多且无法统一：我们可能要在webstorm/vscode里面写代码，然后安装xx插件，且A同事跟B同事习惯可能不一致，那么导致插件还可能不通用，写代码在编辑器，调试在浏览器，其他的工具也都无法统一
我只想做一个前端，面向浏览器编程，可是你让我装这么多东西，为了碎银几两，我忍！？
webcontainer技术可能会帮我们解决这些痛点
当node.js可以运行在浏览器中的时候，我们就不需要安装vscode,node.js和各种插件在电脑上了，只需要打开浏览器，输入（例如react环境）：
https://stackblitz.com/fork/react
感受一下，打开浏览器就可以编程，毫秒级别启动、热更新的感受
有人会说，你这不就是个webIDE吗？ 但是webIDE缺失了nodejs的能力，webcontainer是具有node.js能力的。
例如，我在浏览器里面写nodejs,可以执行我的命令，安装对应的依赖等
以上两点，就解决了我们的node_modules黑洞，和安装各种软件到电脑上的痛点,我只需要安装一个浏览器，我就可以写React，写nodejs,写next，想怎么写就怎么写
最让我感到兴奋的点 - 舒适
进入next项目，从安装依赖到启动，只要几秒钟时间，要知道如果是在日常的开发中，这个时间可能会需要几分钟
试着安装lodash
yarn add lodash -D
大约7秒钟时间，所有的操作都在浏览器环境中完成，注意是浏览器环境中
但是怎么把webIDE上的代码本地化呢？
URL上按钮，一键本地化，只要两秒钟，代码就到本地了
热更新从代码编写，到编译打包，完全在浏览器中闭环，只要打开一个浏览器就完成所有的动作
是不是很香？ 是不是很舒适？ 打开一个浏览器就搞定了所有的事情。
谈谈这种开发模式目前存在的问题
1.在浏览器沙箱环境中运行，在浏览器环境下，会产生跨域的情况，那么意味着 数据库、mysql、redis连接都会受限（谷歌浏览器可能未来会支持 native socket,做过私有化通信协议开发的同学应该就知道这个是什么，这是issue地址，目前是open状态)
https://bugs.chromium.org/p/chromium/issues/detail?id=909927&can=2&q=proj-fugu&sort=pri&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&x=m&y=releaseblock&cells=ids2.底层使用的是特定的Turbo包管理器，而不是npm或者yarn,针对浏览器做了特定优化(这个貌似只要做好兼容就行)
3.目前还是beta状态，尚未发布正式版本
4.兼容性问题，一些浏览器对Web/ServiceWorker 和 SharedArrayBuffer不兼容
5.打包目前不是esm
这个技术的原理
- 目前源码尚未开放，以下都是本人根据文档和猜测而来
在我看来，webcontainer这个技术更像是一个wasm的一个框架、库，例如：让nodejs能跑在浏览器中，那么这个nodejs肯定是wasm的二进制文件，引入了webcontainer之后，nodejs就可以跑在浏览器中了
像一些安装依赖的缓存优化，用到了ServiceWorker的tcp网络请求能力，还有拦截请求，优化等。这样也可以在后期电脑离线的时候使用
包的安装，像npm yarn 都是安装到本地磁盘上，但是在浏览器环境中，不是安装在本地磁盘上，根据官方的说法，每次进入一个环境，都是重新干净的,需要重新install一次，这里我还没确定，因为官方说打包不是esm，那么意味着可能自己对依赖做了处理然后再打包构建，可能安装的时候也是把内容放在内存中，并没有落入磁盘，或者是存在了ServiceWorker的缓存中（这里我发现一些文件会被缓存在或者是存在了ServiceWorker的缓存中）
总结
目前这个技术还不算成熟，但是强烈建议去尝试使用，stackblitz这种理念很棒，一个浏览器搞定所有的事情，但是目前存在的问题最大的是:native socket能力并没有放开，但是做过IM或者Electron的人都知道，浏览器如果放开native socket,又有webcontainer这种技术，以后我们真的只要安装一个浏览器就完事了
一切可以用javascript来实现的，最终都将用javascript来实现 - 鲁迅
看完两件事
如果你觉得这篇内容对你挺有启发，我想邀请你帮我几件小事
1.点个「在看、赞、关注」，让更多人也能看到这篇内容（点了「在看」，bug -1 😊）
2.关注微信公众号「前端巅峰」，让我持续为你推送精选好文
我是Peter谭,一位小厂前端开发工程师，喜欢搞架构，对性能优化，跨平台开发有一定研究，还喜欢做自媒体，区块链。欢迎关注我
