周报 2023W40：别胡乱吹捧那些技术
失业的第 38 周，别人出去潇洒快乐，我在家里苦逼学习。
不知从何时起，我养成了个「坏毛病」——别人鼓吹神化什么，我就想去唱反调，除了得到我从心底认同的那些。
Tailwind CSS
昨早起来后，开始看书前刷了会手机，在掘金上看到一篇站台 Tailwind CSS 的文章《要喷也得先做做功课吧？驳Tailwind不好论》。
本来我就因 Tailwind CSS 提倡 utility-first 并流行起来而没好感（原因可见《聊聊前端 UI 组件：组件设计》），心里对它充满「敌意」。
掘金那篇文章带有挑衅意味的标题以及自称「前端架构师」的作者在正文和评论区的言辞中所体现出的态度成功激起了我想要批判 Tailwind CSS 的欲望。
当然，我不会在这里进行批判，而是看情况写篇文章；但在这我想说下 Tailwind CSS 真没啥先进性，创新性也基本没有——
在我看来，Tailwind CSS 只是做了我总结的 UI 组件体系中「风格组件」层面的事情，也就是所谓的「Design Token」；我稍微花点时间写个转换工具，就能把我在 Petals 中定义的 Sass 变量转换为与 Tailwind CSS 差不多的 utility classes，完成它大部分的功能。
Tailwind CSS 的价值只有两个：1. 一套还可以的默认主题；2. 如一位掘友说的，形成了 utility classes 的命名标准。
不是我在吹牛逼，而是我 Petals 的体系比 Tailwind CSS 先进且完善，根本不在一个层次上——在高维解决低维的问题难道不是轻轻松的么？
Petals 中已经内置一些功能性的 utility class，即调整布局、对齐方式等的；因遵循 component-first 的设计理念而没提供主题类的 utility class，取而代之的是一大堆 Sass 变量与 CSS 自定义属性，即「风格组件」。
即便如此，就像上文所说，想弄出一套主题类的 utility class 只需写个小脚本就能搞定——
|
上面是 Petals 中定义基础的字体相关主题变量的文件内容，我可以写个脚本读取文件，并根据变量名生成 CSS class 与规则，再保存为新文件：
|
之所以能很轻松地生成主题类的 utility class，是因为「风格组件」就是很原子化的，且变量的命名有固定模式。
不可否认的是，Tailwind CSS 确实解决了个人或小团队项目的美观度问题——它的价值不在技术和管理上，而是视觉效果上。
微前端
听起来很屌很复杂的「微前端」也没啥了不起的——
可能是之前内推的面试被拒理由有「不懂微前端」，并且最近看的工作机会很多要求会微前端，这让我很是在意。
再加上我好像真没认真地去了解过，或者是忘了，总之就是对微前端没有太深的印象。
另外，近期想深入总结下在前端模块化编程相关理论与实践的「基础」。
综上所述，令我对微前端有点「执念」，迫不及待想要了解并记住它到底是什么鬼！
忽然想起来 Phodal 的书《前端架构：从入门到微前端》中有介绍，并且我几年前买了它的电子版（几乎没看过），就立马去看了对微前端的介绍。
如图所示，微前端也不过如此，那 6 种方式不是我早就实践过的，就是我的配置式框架 Handie 规划中要做的——只不过是给这几种模式起了个名字，造了个新概念。
面试就是这样，很多用得滚瓜烂熟的实践，当以一个貌似牛逼高大上的术语被提问时，自己就「不会」了……
今早起来后看到即刻上有人评论：「微前端的难点在于不同技术之间的整合，比如一个项目 react 和原生混用，把这个项目整合进微前端你会脱一层皮」
我「狂妄」地回了个：「简单😀」
处理这种问题的基本思路我都已经有了——
运行时层面，只要目标库/框架没修改内置对象原型，就可以通过文件级 IIFE 参数的方式将库/框架的依赖对象传进去；但如果修改了，那就得利用 iframe 去隔离了。
相同库/框架不同版本的问题，若新版本能兼容旧版本，就只采用新版本，否则多版本共存，在上面说的文件级 IIFE 参数中传入相应的版本即可。
一些其他在运行时搞不定的东西，就在编译时用「黑魔法」修改下生成后的代码。
当然，必定会有一些细节处理问题，但都是些能够解决的「小问题」。
结语
开源社区的绝大部分东西，就别神化乱吹了；但有那么一小部分项目，我是真的敬佩！