大家好，我是Kason。昨天早上，在开心的吃早餐、唱歌、钓鱼的时候，看到一条友达推文：你：老实说，我觉得NativeCSSModules标准仓促，再次说明了参与标准制定的过程。一些人的狂妄经常看到游达等大佬交流技术，“草率”“狂妄”之类的字眼很少见。今天就让我们一起来看看，这是一个怎样的标准，让游达忍不住diss一下。这个CSS模块不是其他模块。学前端的同学一定对CSSModules不陌生。这里简单介绍一下。CSSModules是一套开源规范，用于解决CSS的以下问题：命名冲突没有模块化依赖不明确（样式覆盖问题）该规范需要通过打包工具来实现。下面通过一个例子来简单了解一下它的实现细节：将CSS文件style.css作为样式对象导入后，通过style.title使用title类：importstylefrom'./style.css';exportdefault()=>{return(爱卡松。
);};对应style.css:.title{color:red;}打包工具会把style.title编译成“stringwithhash”:
HelloWorld同时，style.css也会被编译：._3zyde4l1yATCOkgn-DBWEL{color:red;}这样就生成了一个独一无二的class，解决了CSS模块化的问题。今天的主角不是CSSModules。NativeCSSModules今年6月，谷歌工程师“JustinFagnani”在推特上公布了CSSModules的最新进展：这个CSSModules并不是上面提到的开源方案，而是ESModules标准下的一个标准。该标准的实际名称是CSSModuleScripts，但社区习惯称它为CSSModules。为了区别于开源方案，下面称之为NativeCSSModules。该标准用于在JS中引入CSS，语法类似于ESModules：//ESModulesimportReactfrom"https://cdn.skypack.dev/react@17.0.1";//NativeCSSModulesimportstyleSheetfrom"./styles.css"assert{类型：“CSS”}；导入的CSS可以应用于文档对象或影子DOM。导入的styleSheet数据结构如下：配合ConstructableStylesheets[1]特性，CSS可以解决：MultiplexingFOUCbetweenmultipleshadowDOMs(FlashofUnstyledContent,即DOM样式由于未加载样式而从头开始闪烁的情况)看起来很不错，那么友达diss的意义在哪里呢？这么多问题？第一选择，通过比较我们可以发现：该标准的命名与现有的开源解决方案冲突。该标准的语法与现有开源解决方案的语法相同。点，假设一个初学者以后搜索CSSModules，结果可能会让他一头雾水。我找到谁了？其次，目前各大打包工具都支持开源的CSSModules方案。如果以后需要实现NativeCSSModules的polyfill，至少会造成重复工作，以及两种方案的变化带来的混乱（想想社区在从CJS到ES的过渡中遇到了多少问题模块）。此外，该方案可能对SSR不友好。而且，由于NativeCSSModules需要在所属的JS模块之后异步加载，因此可能会产生很多碎片化的CSS文件请求。面对如此多的潜在问题，“JustinFagnani”仍在积极推动标准的实施。或许这就是友达觉得对方“嚣张”的原因吧。从讨论1[2]和讨论2[3]中可以看到，双方对新标准进行了充分的讨论和总结，新标准需要在原有基础上有所突破，但受限于现状，不能大刀阔斧地改变。这种突破与取舍的博弈每时每刻都在开源世界上演。参考文献[1]可构造样式表：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
