关于javascript:面向未来的前端开发模式-写于2021年

在之前，给大家介绍过 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 共事习惯可能不统一，那么导致插件还可能不通用，写代码在编辑器，调试在浏览器，其余的工具也都无奈对立

我只想做一个前端，面向浏览器编程，可是你让我装这么多货色，为了碎银几两，我忍！？

当 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 秒钟工夫，所有的操作都在浏览器环境中实现，留神是浏览器环境中

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=ids

2. 底层应用的是特定的 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 谭, 一位小厂前端开发工程师，喜爱搞架构，对性能优化，跨平台开发有肯定钻研，还喜爱做自媒体，区块链。欢送关注我

关于javascript:面向未来的前端开发模式-写于2021年

面向未来的前端开发模式

前端现状的痛

webcontainer 技术可能会帮咱们解决这些痛点

最让我感到兴奋的点 – 舒服

然而怎么把 webIDE 上的代码本地化呢？

谈谈这种开发模式目前存在的问题

这个技术的原理

总结

看完两件事