写在开头
近期我有写两篇文章,一篇是:
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
并没有加快用户操作浏览器响应的速度,只是说,方便用于数据驱动视图,更便于管理而已,并且在一定程度上,更慢。真正最快的永远是:
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标准语法中去,剥离开来希望会大大提升。
重点
说了这么多,大家有可能没理解到重点,那就是:大家都在想着减轻自身的负重,把丢下来的东西标准化,交给浏览器处理,这也是在为未来的只需要打开一个浏览器,就可以完成所有的事情做铺垫
而我,相信这一天应该不远了,据我所知已经有不少顶尖的团队在研发这种产品
写在最后
如果你感觉有什么疑问,在下方给我留言吧
如果你感觉写得不错,帮我的公众号:
前端巅峰
点个在看/赞/关注
三连吧,原创不易