这篇文章是对Twitter上这次对话中问题的详细解答。 原始作者Sunil Pye是相对流行的魅力库的作者，并在Facebook上担任开发人员。
Javascript比CSS更加方便吗？ 在JS中编写CSS如何使它得到更多支持？
我将很乐意谈论这个话题。 我必须马上说CSS-in-JS解决方案有开销，但是通常这个价格是由它们带来的优势来证明的。 有时它们可能有用，但这并不意味着CSS-in-JS应该始终在所有地方使用。
因此，CSS-in-JS（cij）中最重要的是CSS选择器。 cij的最大优点是计算机可以自动生成这些选择器。 诸如OOCSS之类的约定 从原则上讲，它们是好的，但是它们基于手写的选择器，很难确保公共名称空间中的唯一性，因为总会有交集的机会。 如果现在还没有发生，那么可能会在三年后发生，这时您的团队不断壮大并且情况发生了变化。 使用第三方库会加剧这种情况。 也可以使用CSS模块来限制CSS选择器的范围，而CSS模块正是为此机会而流行的。
尽管如此，使用所有这些方法，选择器很难静态分析并找到哪些被破坏（或包含错别字），这意味着必须在代码审查过程中手动检查选择器，这会降低命令的有效性。 我们必须借助计算机的帮助，而不要依靠人们的完整性和完美性（因为事实并非如此）。 CSS-in-JS使自动生成唯一选择器和标识符成为可能。
另外，对CSS选择器的增强控制开辟了以前不易访问的新可能性。 例如，我们可以通过将HTML块与所需的样式进行匹配来简单地执行关键的CSS提取，这样我们就可以在页面上仅加载1-2 Kb的CSS，这对于页面的初始显示是必需的。 没有任何运行时！ 像Gatsby和Next这样的框架积极地使用它来改善基于它们的项目中的绩效指标。 他们将重要的CSS直接嵌入可下载的HTML中，仅仅是因为它的重量如此之小，以至于比阻止页面加载的额外请求要好。 这大大减少了初始页面渲染时间。 而且，它也有助于解决可下载的Javascript大小的问题！ 好处来自应用关键的CSS，以及使用动态import() ， 代码拆分和删除未使用的代码。 （与不断增长的Legacy样式文件相反，在传统样式文件中，开发人员仅向其中添加新代码，而又怕碰到现有代码。 在此主题上有一些分析 。）
与主题的执行情况类似。 您是否知道CSS变量 （即使是一件非常有趣的事情）并没有达到它们原本打算的用例，而所有这些都是因为旧浏览器的后备方法非常复杂或劣等？ 这意味着它们通常用作全局常量，但很少用作其值在浏览器中动态确定的变量。 拥有CSS CSS运行时意味着您可以将JS中的值传递给样式，从而使之成为可能。
实际上，您会喜欢它：最终您可以诚实地在所有浏览器中使用CSS变量，也就是说，本机功能在支持它们的浏览器中没有运行时，并且为较旧的浏览器提供了特殊的运行时。 （我在这里写了更多有关此的内容，并且-如果我理解正确的话-这是唯一实现此目的的库）。
在具有大量组件和异步加载资源（例如脚本和样式）的复杂SPA情况下，您不能保证加载样式的确切顺序，因此您必须创建某种类型的运行时解决方案以保证样式的顺序，或者仅使用!important 如果您坚持使用某种CSS方法 。 例如，您有一个class=“ab”的元素，但是a和b类b在不同的样式文件b定义的，那么，如果您对样式文件没有明确的顺序，则无法确定块的最终形式。 Facebook代码库包含!important数千种用法，即使该代码是由合格的程序员使用SOLID原则并与设计团队进行良好交互而编写的。
这通常是指像对待Javascript一样处理CSS-鉴于10年前我们已经解决了JS的类似问题-库和模块在全局名称空间（ $等）中注册了自己，我们必须非常谨慎地对待连接顺序HTML中的脚本。 但是我们并没有永远停留在那儿-现在我们使用模块，组装系统以保证正确的顺序将它们缝在一起。 这对我们来说是简单透明的。
在观看实际项目时，我还注意到您仍然可以在CSS-in-JS世界中使用传统的架构方法（例如OOCSS或SMACSS等）-这些架构的元素在这里由JS对象表示，而不是+选择器块样式。 我采用这种方法，对我来说效果很好。 在这里您可以阅读更多有关它的信息。
我也很清楚CSS-in-JS的缺点。 实际上，这就是为什么没有一个代表CSS-in-JS的“规范”库的原因-它是一系列不同的解决方案，从一方面是静态静态CSS到另一方面是完全动态的库，例如样式组件 。 诸如SASS或LESS之类的预处理器似乎与该频谱垂直，因为从理论上讲，这些库中的任何一个都可以根据其作者的判断来使用它们。 这些库中的每一个都有其缺点-有些在组装阶段就参与样式的提取，因此在运行时不会产生任何成本，有些则专注于开发人员的正确性或便利性，有些则专注于复杂动画的有效实现等，依此类推。 在一个快速发展的行业中，这种多样性是对针对不同工作任务的不同解决方案需求的自然反应。 而且这不仅发生在库中-Web标准开发人员（ShadowDOM和其他人）也英勇地尝试解决这些问题，但是他们的解决方案也有缺点，至少其中一个缺点是它们尚未在所有地方都可用，这使其无法使用。在许多团队中。
我曾经对此有强烈的感觉，但是在过去的几个月中，我已经改变了看法。 事实证明，事实实际上在中间的某个地方-它取决于团队，需求，时间，文档和许多其他因素。 而且，我认为本文不代表该想法的“最终形式”。 我们应该鼓励在这一领域进行试验，以便找出其他可以做得更好的方法，甚至将其中一些内容嵌入浏览器中。
PS太晚了，我意识到我忘了选中“翻译”框，因此它是这样发布的。 链接到原始文件 。
哈伯，修复界面，发布后为什么不能添加翻译标记？