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

写在开头

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

看前端的技术演进

• 原生Javascript - Jquery为代表的时代，例如，引入Jquery只要

<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,我觉得webpack5的Module Federation设计，就考虑到了这一点，下面是官方的解释：
  • 多个独立的构建可以组成一个应用程序，这些独立的构建之间不应该存在依赖关系，因此可以单独开发和部署它们。
  • 这通常被称作微前端，但并不仅限于此。

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

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标准语法中去，剥离开来希望会大大提升。

重点

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