面向未来的前端开发模式

在之前，给大家介绍过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=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谭,一位小厂前端开发工程师，喜爱搞架构，对性能优化，跨平台开发有肯定钻研，还喜爱做自媒体，区块链。欢送关注我