写在开头。我最近写了两篇文章。一是：petite-vue源码分析和nuggeteditor源码分析。我发现里面用的是Svelte框架，还有最近的React17。大家在vite中也逐渐在生产环境中使用，所以才有了今天的思考，看看前端技术的演进。以原生Javascript——Jquery为代表的时代。比如引入Jquery只需要然后就是gulpwebpack等构建工具，React和Vue也在这个时候开始火起来，紧接着由很多工程辅助工具，比如babel、create-react等提供全套服务的脚手架，比如-app也带来了问题。当然这是npm的问题。在开始一个项目之前，必须安装大量的依赖项。即使有优化过的依赖管理工具如yarnpnpm`，这个问题的根源应该不是使用工具来解决问题，而是问题的本质还是依赖本地化。代码和依赖项需要工具才能在浏览器中运行。总结就是：现有的开发模式使得项目过于繁重。比如我要使用某个脚手架，我只是想写一个helloworlddemo，结果它让我安装500mb的依赖，不同的脚手架产品，不同的配置，不同产品的理想开发模式1。不需要辅助工具配置，不需要像webpack这样的工具帮我打包，模块化浏览器原生支持，是一个规范。比如vite号称不打包，而是使用了浏览器本身支持的esm模块化，但是并没有解决依赖问题，因为依赖问题本身就是依赖问题，不是工具问题2.不需要安装依赖，一切都可以从远程导入，我想webpack5的ModuleFederation设计考虑到了这一点，官方解释如下：多个独立构建可以组成一个应用程序，这些独立构建之间应该没有依赖关系，所以他们可以单独使用开发和部署它们。这通常被称为微前端，但不限于此。但这可能不是最佳做法。目前有importfromhttp，比如importlodashfrom'https://unpackage/lodash/es'，这里又有人要问了，你不是一直发请求吗？每次启动时远程拉取比在本地拉取要好。我觉得importfromhttp只是解决了一个问题，就是不需要手动安装依赖到本地盘。我刚才写过。在浏览器本地运行Node.js的技术称为WebContainers技术。如果您有兴趣，可以查看一下。公众号之前的文章等等，别着急。这些仅仅是开始。通常需要探索新技术以实现价值最大化。我觉得这应该会彻底颠覆现有的发展模式，而且应该在3-5年内。融合几种新的前端技术概念？Vite的非封装理念：直接使用浏览器支持的esm模块化WebContainers技术：让浏览器直接从远程运行node.jsimport，从远程地址直接导入可以使用的依赖。现在流行的webIDE：类似于remix编辑器，可以直接在云端优化浏览器，如果有天然的缓存支持会怎样？我们通过直接启动浏览器来启动一切。浏览器中的webIDE可以直接引入远程依赖。浏览器可以运行Node.js，采用esm模块化，不需要打包工具，项目启动时间和热更新时间很短，也可以直接在浏览器中构建。这些似乎已经解决了我们之前提出的大部分问题。回到今天的主题，主题前端会不会回到操作原生DOM的时代？？我认为有这种趋势，比如petite-vue和Svelte。因为之前写过petite-vue源码分析，所以今天要说的是SvelteSvelteSvelte，这是一种全新的用户界面构建方法。React和Vue等传统框架在浏览器中完成大量工作，而Svelte则在构建应用程序的编译阶段处理这些工作。与虚拟DOM不同。Svelte写的代码可以在应用状态发生变化时像外科手术一样更新DOM写的不错，这里复制一部分吧。React和Vue都是基于运行时的框架。所谓基于运行时的框架，是指框架本身的代码也会被打包成最终的bundle.js发送到用户的浏览器。当用户在你的页面上执行各种操作改变组件的状态时，框架的运行时会根据新的组件状态（state）计算（diff）哪些DOM节点需要更新。但是，这些打包的框架太大了。（今天还在跟同事说，我前年写的那个登录站点是纯原生手工搭建的，性能无敌）100kb对于弱网环境来说太可怕了。看看svelte减少了多少体积：科普virtualdom并没有加快用户操作浏览器响应的速度，只是方便数据驱动的视图，更容易管理，一定程度上更慢。真正最快的永远是：currentDom.innerHtml='前端巅峰';所以Svelte不是说它有多好，而是它的概念，未来可能会越来越主流。大家应该都知道React17的变化，现有的大部分浏览器都不能直接解释JSX，所以大部分React用户需要借助Babel或者TypeScript等编译器，将JSX转换成浏览器可以理解的JavaScript语言。许多预配置的工具包（例如：CreateReactApp或Next.js）内部也有JSX转换。React17.0，虽然React团队想改进JSX的改造，但React团队不想破坏现有的配置。这就是为什么React团队与Babel合作，为想要升级的开发人员提供JSX转译的全新重写。通过一个新的转换，你可以单独使用JSX而无需引入React。我猜想，也许React团队有意推动jsx语法成为es标准语法，分离的希望会大大提高。说了这么多，大家可能没明白重点，那就是：大家都想着减轻自己的负担，把留下来的东西标准化，交给浏览器去处理。这也是为了未来。据我所知，很多顶级团队已经在开发这种产品了。如果您有任何问题，请在下面提出。让我留言。觉得写的不错，帮帮我公众号：点击前端峰看/点赞/关注三联，原创不易
