由于作业的原因，我和一些外国前端开发有些沟通。他们关于国内环境不了解，有时分会问出一些风趣的问题，大概是这些问题的启发，让我重复在考虑一些更为深入的问题。
今天聊三个工作：
- 小程序
- 微前端
- 模块加载
小程序
每个职业都有一把银座，当坐上那把银座时，做什么便都是对的。
“咱们为什么需求小程序？”
第一次被问到这个问题，是由于一个法国的搭档。他被派去做一个移动端事务，刚好那个事务是选用小程序在做。所以一个法国小哥就在被苦楚的中文文档和黑盒逻辑中来回摧残着 。
所以，当咱们在有一次沟通中，他问出了我这个问题：咱们为什么需求小程序？
说实话，我试图解释了 19 年国内的现状，以及微信小程序推出时分所带来的便当和体会等等。总之，在我看来并不够深入的见解。
即使到现在为止，每次当我运用小程序的时分，依旧会复现这个问题。在 ChatGPT 11 月份出来的时分，我也问了它这个很有国内特征的问题：
看起来它回答的还算不错，至少我想假如它来欺骗那些老外，应该会比我做的更好些。
但假如抚躬自问，单从技能上来讲。以上这些工作，必定是有其他计划能处理的。
所以从某种程度上来看，这更像是一场截胡的商业事例：
运用商场
全国际的互联网人都知道运用商场对错常有价值的工作，能够说操作体系最值钱的部分就在于他们构建了自己的运用商场。
只需运用在这儿注册发行，雁过拔毛，这家公司便是互联网国际里的统治阶级，规矩的制定者。
反之则需求受制于人，APP 做的再大，也仅仅运用商场里的一个运用，做的好与坏还得让运用商铺的评判。
另外，不得不供认的是，一个庞大如苹果谷歌这样的公司，他们的运用商铺关于一般国内开发者来说，的确是有门槛的。
在国内海量的 APP 需求降临之前，能否供给一个更低本钱的处理计划，来消化这些公司的出资？
究竟不是一切的小企业都需求 APP，其实他们大部分需求 Web 就能够处理，可是 Web 没牌面啊，做 Web 还得砸搜索的钱才有流量。(某度搜索又做成那样…)
那做操作体系？太不容易，那么多人都淹死在水里了，这水太深。
那有没有一种办法能够既能构建生态，又有 APP 的心智，还能给入驻企业供给流量？
所以，在 19 年夏天，深圳滨海大厦下的软件展业基地里，每天都在轮流播放着，做 XX小程序，拥抱下一个风口…
全新体会心智
小程序用起来挺便利的。
你有没有想过，这些美妙感觉的详细都来自哪些？以及这些真的是 Web 技能自身无法供给的吗？
- 靠谱感，每个小程序都有束缚和标准，所以你能够将他们整整齐齐的陈放在你的列表里，仿佛你已经拥有了这一个个精心雕琢的著作，相关于一条条记不住的网页地址和鱼龙混杂的网页内容来说，这让你觉得小程序愈加的有分量和靠谱。
- 安全感，沉浸式的头部，没有一闪而过的加载条，这一切无打扰的设计，都让你觉得这是一个在你本地的 APP，而不是随时或许丢掉网页。你不会由于网速白屏而感到焦虑，尽管网络差的时分，你的 KFC 依旧下不了单
- 沉浸感，我不知道是否翻开网页时顶部黑黑的状态栏是成心留下的，仍是不小心的… 这些限制都让用户十分激烈的认识到这是一个网页而不是 APP，而小程序中尽管上面也存在一个空间的空白，可是却能够被愈加沉浸的主题色和氛围图代替。网页这个需求做不了？我不信。
| H5 | 小程序 |
|---|---|
 |
 |
- 顺滑感，得益于 Native 的容器完成，小程序在一切的视图切换时，都能够体现出于原生运用相同的顺滑感。其实这个问题才是在许多 Hybrid 运用中，首要想凭借客户端来处理和处理的问题。相似容器预开、容器切换等技能是能够处理相关问题的，仅仅还没有一个标准。
我这儿没有提功能，说实话我不认为功能在小程序中是有优势的（Native 调用除外，如地图等，不是一个讨论领域）。作为一般用户，咱们感受到的仅仅离线加载下带来的顺滑而已。
而上述说到的许多优势，这关于一个高质量的 Web 运用来说是能够做得到的，但留意这儿是高质量的 Web 运用。而这种“高质量”在小程序这儿，仅仅入驻门槛而已。
心智，这个词，听起来很黑话，但却很恰当。当小程序经过长期这样的挑选，所沉淀出来一批这样质量的运用时。就会让每个用户即使在还没翻开一个新的小程序之前，也有不错体会的心理预期。这便是心智，一种感觉跟 Web 不相同，跟 APP 有点像的心智。
打造心智，这件工作如同便是国内互联网企业最擅长做的工作，总是能从一些纤细的差别中开辟一条独立的领域，然后不断强化灌注原本就不大的差异，等流量起来再去捞钱变现。
我总是感觉现在的互利网充满着怎么挣钱的主意，如同永久赚不够。“挣钱”这个工作，在这些公司眼里便是圈人圈地抢资源，看看谁先占得先机，别人有的我也得有，这如同是最重要的工作。
很少有企业在考虑怎么发明些没有的商场，发明些真正对技能开展有贡献，对社会开展有推进效果的工作。所以在国内互联网圈也充满着一种奇怪的价值观，有技能的不必定比赚过钱的受待见。
管你是 PHP 仍是 GO，管你是在做游戏仍是直播带货，只需赚到钱便是高人。而且端的是理所应当、理直气壮，有些老板乃至把拍照满屋子的程序员为自己打作业为一种趣味。什么情怀、什么高雅、什么愿景，人生就俩字：搞钱。
不是成心高雅，挣钱这件工作自身不寒碜，仅仅在已经赚到盆满钵满、一家独大的时分还在仅仅想着赚更多的钱，如同挣钱的目的便是为了挣钱相同，这就有点不合适。企业到必定程度是要有社会责任的，龙头企业每一个决议和举措，都有会影响接下来的几年里这个职业的价值观走向。
当然也不是完全没有好格局的企业，我十分珍惜每一个值得尊重的中国企业，来自一个蔚来车主。
小程序在商业上固然是成功的，但吃的盈利能够说仍是来自 网页 到 运用 的心智革新。将原本流向 APP 的盈利，截在了小程序生态里。
但关于技能生态的开展却是带来了很多条新的岔道，小程序的玩法就决议了它有必要生长在某个巨型运用里边，不论是用户数据获取、仍是 API 的调用，其实都是取决于运用容器的标准标准。
不同公司和运用之间则必然会产生差异，而且这种差异是墒增式的差异，只会跟着时刻的推移越变越大。假如每个企业都只关注到自己事务的增长，无外部束缚的话，企业必然会依据自己的事务开展和政策需求，挑选本钱较低的调整 API，乃至会成心制造一些壁垒来添加这种差异。
小程序，应该是 浏览器 与 操作体系 的交融，这本应该是推进这两项技能操刀处理的工作。
微前端
qiankun、wujie、single-spa 是近两年火遍前端的技能计划，相同一个问题：咱们为什么需求微前端？
我不确定是否每个在运用这项技能的前端都想清楚了这个问题，但至少在我面试过的候选人中，我很少遇到对自己项目中已经在运用的微前端，有很深的考虑和了解的人。
先说下我的看法：
- 微前端，重在处理项目管理而不在用户体会。
- 微前端，处理不了该优化和需求标准的问题。
- 微前端，在挽救没想清楚 MPA 的 SPA 项目。
没有全能银弹
银色子弹（英文：Silver Bullet），或许称“银弹”“银质子弹”，指由纯银质或镀银的子弹。在欧洲民间传说及19世纪以来哥特小说风潮的影响下，银色子弹往往被描绘成具有驱魔成效的武器，是针对狼人、吸血鬼等超自然怪物的特效武器。后来也被比喻为具有极点有效性的处理方法，作为杀手锏、最强杀招、王牌等的代称。
一切技能的开展都是树立在前一项技能的根底之上，但技能依靠的挑选过程中必定需求保存第一性原理的认识。
当 React、Vue 鼓起，当 打包技能(Webpack) 鼓起，当 网页运用(SPA) 鼓起，这些出色的技能打破都在不同场景和领域中给职业供给了新的思路、新的计划。
不知从何时开端，前端除了 div 竟说不出其他的标签(还有说 View 的)，项目中再也不会考虑给一个通用的 class 处理通用样式问题。
不知从何时开端，有没有权限需求等到 API 恳求往后才知道，没有权限的话再把页面跳转曩昔申请。
不知从何时开端，咱们的页面都放在了一个项目里，两个这样的巨石运用交融居然变成了一件困难的事。
上面这些不合理的现状，都是在不同的场景下，不考虑适不适合，单一信仰 “一招吃遍天” 下演化出的问题。
B 端运用，是否应该运用 SPA？ 这其实是一个需求考虑的问题。
微前端从某种程度上来讲，是认准 SPA 了有必要是互联网下一代运用标准的产品，如同有了 SPA 以后，MPA 就变得一文不值。别管页面是移动端的仍是PC的；别管页面是面临 C 端的仍是 B 端的；别管一个体系是有 20 个页面仍是 200 个页面，一律行这套逻辑。
SPA 不是全能银弹，React 不是全能银弹，Tailwind 不是全能银弹。在新技能呈现的时分，保持热心也要保持克制。
ps. 我也十分怨恨 React 带来的这种垄断式的生态，一个 React 组件将 HTML 和 Style 都吃进去，让你即使在做一个移动端的纯展现页面时，也需求背上这些称重的负担。
质疑 “故步自封”，翻开视野，深度把玩，理性消费。
分而治之
分治法，一个很基本的工程思维。
在我看来在一个正常商业迭代项目中的首要维护者，最好不要超越 3 个人，留意是首要维护者(Maintainer) 。
你应该让每个项目都有清晰的责任人，而不是某行代码，某个模块。责任人的了解是有归属感，有鸿沟感的那种，不是口头意义上的责任人。(一些公司喜欢搞这种虚头巴脑的工作，什么连坐…)
我想大部分想引进微前端的需求都是相似 怎么更好的区分项目鸿沟，一起保存更好的团队协同。
比方 导航菜单 应该是独立收口独立管理的，而且当其更新时，应该一起运用于一切页面中。相似的还有 环境变量、时区、主题、监控及埋点。微前端将这些概括在主运用中。
而详细的页面内容，则由对应的事务进行开发子运用，毕竟想办法将路由关系注册进主运用即可。
当然这样纯前端的运用切换，还会呈现不同运用之间的大局变量差异、样式污染等问题，需求供给完善的沙箱容器、隔离环境、运用之间通信等一系列问题，这儿不打开。
当微前端做到这一部分的时分，我不禁在想，这如同是在用 JavaScript 完成一个浏览器的运转容器。这种本应该浏览器自身该做的工作，莫非 JS 能够做的更好？
仅仅做到更好的项目拆分，安排协同的话，引进后端服务，由后端管控路由表和页面规矩，将页面直接做成 MPA，这个计划或许并不比引进微前端本钱高多少。
体会差异
从 SPA 再回 MPA，说了半天不又回去了么。
所以不防想想：在 B端 事务中运用 SPA 的优势在哪里？
流畅的用户体会：
这个论题其实包括范围很广，关于 SPA 能带来的 “流畅体会”，关于大多数情况下是指：导航菜单不变，内容变化 发生变化，页面切换中心不呈现白屏。
但要做到这个点，其实关于 MPA 其实并没有那么困难，你只需求保证你的 FCP 在 500ms 以内就行。
以上的页面切换全部都是 MPA 的多页面切换，咱们仅仅简单做了导航菜单的 拆分 和 SWR，并没有什么特别的 preload、prefetch 处理，就得到了这样的效果。
由于浏览器自身在页面切换时会在 unload 之前先 hold 当前页面的视图不变，建议一下一个 document 的恳求，当页面的视图烘托做到足够快和界面结构稳定就能够得到这样的效果。
这项浏览器的优化手法我找了很久，想找一篇关于它的博文介绍，但的确没找到相关内容，所以 500ms 也是我的一个大致测算，假如你知道相关的内容，能够在谈论区弥补，不胜感激。
所以从这个角度来看，浏览器自身就在尽最大的努力做这些优化，而且他们的优化会更底层、更有效的。
离线拜访 (PWA)
SPA 的确会有更好的 PWA 安排才能，一个完好的 SPA 运用乃至能够只针对编译层做改动就能够支撑 PWA 才能。
但假如看微前端下的 SPA 运用，需求支撑 PWA 那就相同需求分析各子运用之间的元数据，定制 Service Worker。这种安排关系和定制 SW，关于元数据关于数据是来自前端仍是后端，并不介意。
也便是说微前端形式下的 PWA，相同的投入本钱，把页面都管理在后端服务中的 MPA 运用也是能够做到相同效果的。
项目协同、代码复用
有人说 SPA 项目下，项目中的组件、代码片段是能够相互之间复用的，在 MPA 下就相对麻烦。
这其实涉及到项目区分的领域，仍是要看详细的需求也事务杂乱度来定。假如说整个体系便是二三十个页面，这做成 SPA 运用前端接收路由高效简单，无可厚非。
但假如你自身在面临的是一个服务于杂乱事务的 B 端体系，比方相似 阿里云、教务体系、ERP 体系或许一些大型内部体系，这种往往需求多团队合作开发。这种时分就需求跟完善的项目区分、安排协同和体系整合的计划。
这个时分 SPA 所体现出的优势在这样的诉求下就会相对较弱，在平等投入的情况下 MPA 的计划反而会有更少的履行本钱。
也不是一切项目一开端就会想的那么清楚，或许一开端的时分便是个简单的 SPA 项目，可是跟着项目的不断迭代，才变成了一个个杂乱的巨石运用，现在假如再拆出来也会有许多迁移本钱。引进微前端，则能够…
这大概是许多微前端项目启动的背景介绍，我想说的是：关于屎山，我从来不信仰“四两拨千斤”。
假如没有想好当下的核心问题，就引进新的“银弹”处理问题，只会是屎山雕花。
项目协同，笼统和复用这些自身不是微前端该处理的问题，这是综合要素影响下的前史背景问题。也是需求一个个资深工程师来把控和处理的核心问题，便是需求面临不同的场景给出不同的管理计划。
这个道理跟防沙治沙相同，哪有那么多一蹴即至、马到成功的功德。
模块加载
模块加载这件工作，从玉伯大佬的成名作 sea.js 开端便是一个十分值得探讨的问题。在当时 jQuery 的年代里，这是一个绝对超前的项目，我也在实践事务中体会过在无编译的环境下 sea.js 的快捷。
实践上，不论是微前端、低代码、会场建立等热门论题离不开这项技能根底。
import * from * 咱们每天都在用，但毕竟的产品往往是一个自运转的 JS Bundle，这来自于 Webpack、Vite 等编译技能的开展。让咱们能够更好的安排项目结构，以构建更杂乱的前端运用。
模块的概念用久了，就会自然而然的在遇到浏览器环境中，遇到动态模块加载的需求时，想到这种相似模块加载的才能。
比方在遇到会场千奇百怪的个性化营销需求时，能否将模块的 Props 敞开出来，给到非技能人员，以愈加灵敏的方法让他们去做自由组合。
比方在低代码平台中，让开发者自定义扩展组件，动态的将开发好的组件注册进低代码平台中，以支撑愈加个性的需求。
在万物皆组件的思维影响下，把一整个完好页面都看做一个组件也不是不能够。所以在一些团队中，乃至发起一切页面都能够建立、建立不了的就做一个大的页面组件。这样及能够减少维护运转时的本钱，又能够统一管控和优化，岂不美哉。
当这样大一统的“天才计划”逐渐开展成为标准后，也必定会呈现一些特别场景无法运用，但不要紧，这些天才设计者肯定会供给一种愈加天才的扩展计划出来。比方插件，比方扩展，比方 IF ELSE。再后来，就会有功能优化了，而优化的 追赶目标 便是用原来那种简单直出的计划。
有没有发现，这如同是在轮回式的做着自己出的数学题，一道接一道，仿佛将 1 + 1的结论从头演化了一遍。
题外话，我从前自己完成过一套经过 JSON Schema 描绘 React 结构的 “库” ，用于一个低代码核心层的烘托。在我的完成过程中，我越发觉得我在做一件把 JSX 翻译成 JS 的工作，但 JSX 或许 HTML 自身不便是一种 DSL 么。为什么必定要把它翻译成 JSON 来传输呢？或许说这样的封装其自身有意义么？这不便是在做 PHP、ASP 直接回来带有数据的 HTML Ajax 相同的工作么。
传统的浏览器运转环境下要完成一个模块加载器，无非是在大局挂载一个注册器，经过 Script 刺进一段新的 JS，该 JS 经过特别的头尾协议，将运转时的代码声明成一个函数，注册进事先挂载好的注册器。
但实践的完成场景往往要比这杂乱的多，也有一些问题是这种非原生方法无法攻克的问题。比方大局注册器的命名抵触；同模块不同版本的加载抵触；并发加载下的时序问题；屡次模块加载的缓存问题 等等等等等…
到毕竟发现，这些工作如同又是在用 JS 做浏览器该做的工作。然而浏览器果然就做了，<script type="module"></script>，Vite 就首要选用这种形式完成了它 1 年之内让各大知名项目切换到 Vite 的壮举。
“但咱们用不了，有兼容性问题。”
哇哦，当我看着咱们随意写出的 display: grid 样式定义，不禁再次感叹人们对不知道的惊骇。
import.meta 的兼容性是另外一个版本，是需求 iOS12 以上，详情参阅：caniuse.com/?search=imp…
试想一下，现在的低代码、会场建立等等各类场景的模块加载部分，假如都直接选用 ESM 的形式处理，这关于整个前端生态和开发体会来说会有多么大的提升。
模块加载，时至今日，原本就已经不再需求 loader。 正如 seajs 中写的：前端模块化开发那点前史
前史不是曩昔，前史正在上演。跟着 W3C 等标准、以及浏览器的飞速开展，前端的模块化开发会逐渐成为根底设施。一切毕竟都会成为前史，未来会更好。
结语
文章的结尾，我想感叹另外一件事，国人为什么必定要有自己的操作体系？为什么必定需求参与到一些标准的制定中？
由于咱们的才智需求有开花的土壤。假如没有自己掌握核心技能，便是只能在问题呈现的时分用特殊的方法来处理。毕竟在一番折腾后，发现更底层的技能只需稍稍一改就能够完成的更好。这就像三体中说到的 “智子” 相同，不断在影响着咱们行进的动力和方向。
不论是小程序、微前端仍是模块加载。试想一下，假如咱们有自己的互联网见识，能决议或许影响操作体系和浏览器的底层才能。这些 “怪啖” 要么不会呈现，要么便是人类的科技立异。
希望未来技能人不用再追逐 Write Once, Run Everywhere 的工作…
