前端是不是又要回去操作真实dom年代?

2022-03-22 14:50:40 浏览数 (1)

写在开头

  • 近期我有写两篇文章,一篇是:petite-vue源码解析和掘金编辑器的源码解析,发现里面用到了Svelte这个框架
  • 加上最近React17,vite大家也在逐步的用在生产环境中,我于是有了今天的思考

看前端的技术演进

  • 原生Javascript - Jquery为代表的时代,例如,引入Jquery只要
代码语言:javascript复制
<script src="cdn/jquery.min,js"></script>
  • 接着便又有了gulp webpack等构建工具出现,React和Vue也在这个时候开始火了起来,随即而来的是一大堆工程化的辅助工具,例如babel,还有提供整套服务的create-react-app等脚手架
  • 这也带来了问题,当然这个是npm的问题,每次启动项目前,都要安装大量的依赖,即便出现了yarn pnpm`等优化的依赖管理工具,但是这个问题根源不应该使用工具解决,而是问题本质是依赖本地化,代码和依赖需要工具帮助才能运行在浏览器中 总结就是:现有的开发模式,让项目太重,例如我要使用某个脚手架,我只想写一个helloworld演示下,结果它让我装500mb的依赖,不同的脚手架产物,配置不同,产物也不同

理想的开发模式

  • 1.不需要辅助的工具配置,我不需要webpack这类帮我打包的工具,模块化浏览器本身就支持,而且是一个规范。例如vite号称不打包,用的是浏览器本身支持的esm模块化,但是它没有解决依赖的问题,因为依赖问题本身是依赖的问题,而不是工具的问题
  • 2.不需要安装依赖,一切都可以import from remote,我觉得webpack5Module Federation设计,就考虑到了这一点,下面是官方的解释:
    • 多个独立的构建可以组成一个应用程序,这些独立的构建之间不应该存在依赖关系,因此可以单独开发和部署它们。
    • 这通常被称作微前端,但并不仅限于此。

但是这可能并不是最佳实践,目前是有import from http,例如

代码语言:javascript复制
import lodash from 'https://unpackage/lodash/es'
  • 这里又会有人问,那你不都是要发请求吗,都是要每次启动的时候去远程拉取,还不如在本地呢。import from http我想只是解决了一个点的问题,就是不用手动安装依赖到本地磁盘
  • 前段时间我写过,在浏览器中本地运行Node.js

这个技术叫WebContainers技术,感兴趣的可以去翻翻我公众号之前的文章

  • 等等,别急。这些仅仅开了个头,新的技术往往要探索才能实现价值最大化,我想此处应该可以彻底颠覆现有的开发模式,而且应该就在3-5年内。

将几个新的前端技术理念融合?

  • vite的不打包理念:直接使用浏览器支持的esm模块化
  • WebContainers技术:让浏览器直接运行node.js
  • import from remote,从一个个远程地址直接引入可以使用的依赖
  • 现在很火的webIDE:类似remix编辑器,直接全部可以在云端搞定
  • 浏览器的优化,天然有缓存支持

会发生什么变化?

  • 我们所有的一切开始,都直接启动一个浏览器即可
  • 浏览器中的webIDE,可以直接引入远程依赖,浏览器可以运行Node.js,使用的都是esm模块化,不需要打包工具,项目启动的时间和热更新时间都非常短,构建也是直接可以在浏览器中构建

这些看似解决了我们之前提出的大部分问题,回到今天的主题

回到主题

  • 前端会不会回到操作原生dom的时代?
  • 我觉得,有这个趋势,例如petite-vue,还有Svelte。 因为之前写过petite-vue源码解析了,我们今天就讲讲Svelte

Svelte

Svelte 是一种全新的构建用户界面的方法。传统框架如 React 和 Vue 在浏览器中需要做大量的工作,而 Svelte 将这些工作放到构建应用程序的编译阶段来处理。

  • 与使用虚拟(virtual)DOM 差异对比不同。Svelte 编写的代码在应用程序的状态更改时就能像做外科手术一样更新 DOM
  • 上面是官方的介绍,我们看看知乎这篇文章https://zhuanlan.zhihu.com/p/97825481,感觉他写得很好,这里照搬一些过来吧直接
  • React和Vue都是基于runtime的框架。所谓基于runtime的框架就是框架本身的代码也会被打包到最终的bundle.js并被发送到用户浏览器。
  • 当用户在你的页面进行各种操作改变组件的状态时,框架的runtime会根据新的组件状态(state)计算(diff)出哪些DOM节点需要被更新 可是,这些被打包进去的框架,实在太大了。 (今天还在跟同事说,前年写的登录站点,纯原生手工打造,性能无敌)
  • 100kb对于一个弱网环境来说,很要命,我们看看svelte减少了多少体积:

科普

虚拟dom并没有加快用户操作浏览器响应的速度,只是说,方便用于数据驱动视图,更便于管理而已,并且在一定程度上,更慢。真正最快的永远是:

所以Svelte并不是说多好,而是它的这种理念,可能未来会越来越成为主流

React17的改变

  • 大家应该都知道,现有的浏览器都是无法直接解译JSX的,所以大多数React用户都需要使用Babel或者TypeScript之类的编译器来将JSX转换为浏览器能够理解的JavaScript语言。许多预配置的工具箱(如:Create React App 或者Next.js)内部也有JSX的转换。
  • React 17.0,尽管React团队想对JSX的转换进行改进,但React团队不想打破现有的配置。这就是为什么React团队与Babel合作,为想要升级的开发者提供了一个全新的JSX转换的重写版本。
  • 通过全新的转换,你可以单独使用JSX而无需引入React. 我猜想,或许React团队有意将jsx语法推动到成为es标准语法中去,剥离开来希望会大大提升。

重点

  • 说了这么多,大家可能没理解到重点,那就是:大家都在想着减轻自身的负重,把丢下来的东西标准化,交给浏览器处理,这也是在为未来的只需要打开一个浏览器,就可以完成所有的事情做铺垫
  • 而我,相信这一天应该不远了,据我所知已经有不少顶尖的团队在研发这种产品

0 人点赞