关于前端:被尤大diss的Native-CSS-Modules是什么

大家好，我是卡颂。

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

尤：诚实说，我认为 Native CSS Modules 规范是仓促的，再次显示了参加该规范制订过程的人的高傲

常常看尤大和其余大佬们交换技术，仓促、高傲这样的字眼是很少看到的。

明天咱们来看看是什么样的规范，让尤大都忍不住diss。

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

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。

往年 6 月，谷歌工程师 Justin Fagnani 在推上颁布了 CSS Modules 的最新进展：

此 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 数据结构如下：

配合 Constructable Stylesheets 个性，能够解决CSS：

在多个 shadow DOM 之间复用
FOUC问题（Flash of Unstyled Content，即因为款式未加载完导致 DOM 款式从无到有的闪动状况）

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

首选，通过比照能够发现：

该规范命名与现有开源计划抵触
规范的语法与现有开源计划语法雷同

第一点，假如在将来一个初学者搜寻CSS Modules，那么后果可能会让他困惑，我搜到的是谁？

第二点，以后各大打包工具都有对开源 CSS Modules 计划的反对。

如果将来须要实现 Native CSS Modules 的polyfill，轻则造成反复工作、重则遇到两种计划更迭造成的凌乱（想想社区从 CJS 过渡到 ES Modules 遇到多少问题）。

除此之外，该计划可能对 SSR 不敌对。

并且，因为 Native CSS Modules 须要在所属 JS 模块加载后再异步加载，可能会产生很多碎片化的 CSS 文件申请。

在有如此多潜在问题的状况下，Justin Fagnani仍踊跃推动该规范的落地，可能这就是尤大认为对方高傲的起因吧。

你能够在探讨 1 与探讨 2 看到单方残缺的探讨

新的规范，既要在原有根底上有所突破，又受限于现状不能大刀阔斧扭转。

这种冲破与衡量的博弈每时每刻都是开源的世界演出。

在开发中你有遇到什么特地喜爱或特地想吐槽的个性吗？欢送评论区探讨～

关于前端:被尤大diss的Native-CSS-Modules是什么

此 CSS Modules 非彼 Modules

Native CSS Modules

这么多问题？

总结