共计 2562 个字符，预计需要花费 7 分钟才能阅读完成。
写在结尾
- 近期我有写两篇文章，一篇是:
petite-vue源码解析和掘金编辑器的源码解析，发现外面用到了Svelte这个框架 - 加上最近 React17，vite 大家也在逐渐的用在生产环境中，我于是有了明天的思考
看前端的技术演进
- 原生
Javascript - Jquery为代表的时代，例如，引入Jquery只有
<script src="cdn/jquery.min,js"></script>- 接着便又有了
gulpwebpack等构建工具呈现，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.jsimport 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并没有放慢用户操作浏览器响应的速度，只是说，不便用于数据驱动视图，更便于管理而已，并且在肯定水平上，更慢。真正最快的永远是：currentDom.innerHtml = '前端巅峰';所以
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 规范语法中去，剥离开来心愿会大大晋升。
重点
- 说了这么多，大家可能没了解到重点，那就是：大家都在想着加重本身的负重，把丢下来的货色标准化，交给浏览器解决，这也是在为将来的只须要关上一个浏览器，就能够实现所有的事件做铺垫
- 而我，置信这一天应该不远了，据我所知曾经有不少顶尖的团队在研发这种产品
写在最初
- 如果你感觉有什么疑难，在下方给我留言吧
- 如果你感觉写得不错，帮我的公众号：
前端巅峰点个在看 / 赞 / 关注三连吧，原创不易
