被尤雨溪diss的Native CSS Modules是什么

╰+攻爆jí腚メ 2022-09-06 05:00 169阅读 0赞

前天早上正吃着早饭，唱着歌，开开心心摸鱼时，看到一条尤大的推文：

![720cfd5394782b7da156b0afbc56cf8a.png][]

> 尤：老实说，我认为`Native CSS Modules`标准是仓促的，再次显示了参与该标准制定过程的人的傲慢

经常看尤大和其他大佬们交流技术，**「仓促」**、**「傲慢」**这样的字眼是很少看到的。

今天我们来看看是什么样的标准，让尤大都忍不住`diss`。

![7fd78131de1544587e2c7f8b37168017.png][]

## 此CSS Modules非彼Modules ##

想必做前端的同学对`CSS Modules`不会陌生，这里简单介绍下。

![4b9af13d6e5aa420034b0b93c8042629.png][]

`CSS Modules`是一套开源的规范，用以解决`CSS`的以下问题：

*  命名冲突
 *  没有模块化
 *  依赖关系不明（样式覆盖问题）

该规范需要打包工具实现。

我们用一个例子来简要了解他的实现细节：

将`CSS`文件`style.css`引入为`style`对象后，通过`style.title`的方式使用`title class`：

import style from './style.css';
    
    export default () => {
      return (
        <p className={style.title}>
          I am KaSong.
        </p>
      );
    };

对应`style.css`：

.title {
      color: red;
    }

打包工具会将`style.title`编译为**「带哈希的字符串」**：

<h1 class="_3zyde4l1yATCOkgn-DBWEL">
      Hello World
    </h1>

同时`style.css`也会编译：

._3zyde4l1yATCOkgn-DBWEL {
      color: red;
    }

这样，就产生了独一无二的`class`，解决了`CSS`模块化的问题。

而今天的主角，并非这位`CSS Modules`。

![57719dcba63551c59d5f9b4a6b2838c8.png][]

## Native CSS Modules ##

今年6月，谷歌工程师**「Justin Fagnani」**在推上公布了`CSS Modules`的最新进展：

![f88ba9d4b66c761bf35f1776168b6233.png][]

此`CSS Modules`并非上文提到的开源方案，而是`ES Modules`标准下的一个标准。

该标准实际名称为`CSS Module Scripts`，但社区习惯称其为`CSS Modules`。

为了与开源方案区别，下文称其为`Native CSS Modules`。

该标准用来在`JS`中导入`CSS`，语法类似`ES Modules`：

// ES Modules
    import React from "https://cdn.skypack.dev/react@17.0.1";
    
    // Native CSS Modules
    import styleSheet from "./styles.css" assert { type: "css" };

导入的`CSS`可以应用于`document`对象或`shadow DOM`。

导入的`styleSheet`数据结构如下：

![3ce76771e8d56d41058003efba5dac95.png][]

配合Constructable Stylesheets\[1\]特性，可以解决`CSS`：

*  在多个`shadow DOM`之间复用
 *  `FOUC`问题（`Flash of Unstyled Content`，即由于样式未加载完导致`DOM`样式从无到有的闪烁情况）

看起来很`nice`，那么尤大`diss`的点在哪里呢？

![8c3bf4d22bd91247f5f3c9eee0248e77.png][]

## 这么多问题？ ##

首选，通过对比可以发现：

*  该标准命名与现有开源方案冲突
 *  标准的语法与现有开源方案语法相同

第一点，假设在未来一个初学者搜索`CSS Modules`，那么结果可能会让他困惑，我搜到的是谁？

![a756b5546351c9a3a56ea65d51cbafab.png][]

第二点，当前各大打包工具都有对开源`CSS Modules`方案的支持。

如果未来需要实现`Native CSS Modules`的`polyfill`，轻则造成重复工作、重则遇到两种方案更迭造成的混乱（想想社区从`CJS`过渡到`ES Modules`遇到多少问题）。

![f37f99b8c66ec5fe5cdb5a88fac62023.png][]

除此之外，该方案可能对`SSR`不友好。

并且，由于`Native CSS Modules`需要在所属`JS`模块加载后再异步加载，可能会产生很多碎片化的`CSS`文件请求。

![15af0f18710e691a305331fa8455ef79.png][]

在有如此多潜在问题的情况下，**「Justin Fagnani」**仍积极推进该标准的落地，可能这就是尤大认为对方**「傲慢」**的原因吧。

> 你可以在讨论1\[2\]与讨论2\[3\]看到双方完整的讨论

## 总结 ##

新的标准，既要在原有基础上有所突破，又受限于现状不能大刀阔斧改变。

这种突破与权衡的博弈每时每刻都是开源的世界上演。

在开发中你有遇到什么特别喜欢或特别想吐槽的特性吗？欢迎评论区讨论～

### 参考资料 ###

\[1\]

Constructable Stylesheets: https://developers.google.com/web/updates/2019/02/constructable-stylesheets

\[2\]

讨论1: https://twitter.com/justinfagnani/status/1403495082506866690

\[3\]

讨论2: https://twitter.com/Joelbdenning/status/1427427564532887565

[720cfd5394782b7da156b0afbc56cf8a.png]: /images/20220829/04469fbf4fae4f8898e92cfb3b175e74.png
[7fd78131de1544587e2c7f8b37168017.png]: /images/20220829/92aaf9cdba8f4fbdba0c57cc5818acdc.png
[4b9af13d6e5aa420034b0b93c8042629.png]: /images/20220829/0436f4ab4ec045b19f95daffa30b9d51.png
[57719dcba63551c59d5f9b4a6b2838c8.png]: /images/20220829/257908122f79449faf194cb3d9081092.png
[f88ba9d4b66c761bf35f1776168b6233.png]: /images/20220829/13fe6d0ea4454afd890a6d937825c9d2.png
[3ce76771e8d56d41058003efba5dac95.png]: /images/20220829/25dc3ae4e6b845949af47d87f099e47d.png
[8c3bf4d22bd91247f5f3c9eee0248e77.png]: /images/20220829/7358b4414b8a478fb8fee62aaeab81e1.png
[a756b5546351c9a3a56ea65d51cbafab.png]: /images/20220829/78986c42e3ce4d848ce65d48f45cee75.png
[f37f99b8c66ec5fe5cdb5a88fac62023.png]: /images/20220829/bda6f51598d94f8b8616f7e762bc81c5.png
[15af0f18710e691a305331fa8455ef79.png]: /images/20220829/15d3d178f51b4d3283c7dc45e9fd2ef4.png