CSS-in-JS，让我们分道扬镳

与 CSS-in-JS 的甜蜜恋情

CSS-in-JS 框架的出现是为了解决困扰前端开发人员的长期问题：样式化和组件复用。这些框架通过将样式直接嵌入 JavaScript 组件中，消除了在外部样式表中管理样式的需要。

起初，我们被 CSS-in-JS 的便利性和灵活性所吸引。它使我们能够轻松地对组件进行样式化，并创建可轻松重用的样式化组件。然而，随着时间的推移，我们开始意识到 CSS-in-JS 并不像最初看起来的那么美好。

情投意合时的矛盾

我们与 CSS-in-JS 的关系开始出现裂痕，原因如下：

性能下降： CSS-in-JS 组件通常会产生比传统 CSS 更大的捆绑包大小，从而导致页面加载时间增加。此外，在运行时将样式内联到 DOM 中会导致额外的计算开销，从而降低性能。

可维护性差： CSS-in-JS 组件中的样式与组件逻辑混在一起，使得代码难以理解和维护。随着应用程序变得越来越复杂，这种混乱会加剧，从而增加调试和修复错误的难度。

代码拆分困难： CSS-in-JS 组件难以拆分成单独的块，这使得在不同的路由或页面之间加载样式变得很困难。这种代码拆分困难会导致更大的应用程序捆绑包大小和更长的加载时间。

捆绑包大小增加： CSS-in-JS 框架的代码库通常很大，这会增加应用程序的整体捆绑包大小。对于较小的应用程序来说，这种增加可能并不重要，但对于较大的应用程序来说，它会成为一个重大问题。

重燃旧爱：传统 CSS

经过深思熟虑，我们决定与 CSS-in-JS 分道扬镳，重新拥抱传统的 CSS 方法。虽然 CSS-in-JS 提供了一些便利性，但其缺点最终超出了其优点。

传统的 CSS 方法提供了一系列好处，包括：

更好的性能： 外部 CSS 文件不会增加 JavaScript 捆绑包的大小，并且它们可以在页面加载时并行下载。此外，使用媒体查询可以优化样式加载，从而进一步提高性能。

更高的可维护性： 外部 CSS 文件将样式与组件逻辑分开，从而使代码更容易理解和维护。样式集中在一个位置，使得对样式进行更改或更新变得更加容易。

更简单的代码拆分： 外部 CSS 文件可以轻松拆分成单独的块，这使得在不同的路由或页面之间加载样式变得更加容易。这种代码拆分有助于减少捆绑包大小和提高加载时间。

更小的捆绑包大小： 传统 CSS 方法不需要额外的 JavaScript 框架或库，从而减少了应用程序的整体捆绑包大小。这对于移动应用程序和带宽受限的设备尤为重要。

拥抱新旅程

放弃 CSS-in-JS 并不是一个容易的决定，但这是我们认为对应用程序的长期健康和可维护性至关重要的决定。虽然 CSS-in-JS 在某些情况下可能是一个不错的选择，但我们相信传统的 CSS 方法对于大多数应用程序来说是一个更可行、更高效的解决方案。

当我们拥抱传统 CSS 时，我们已经看到应用程序性能的显着提高、可维护性的改善，以及整体开发体验的增强。虽然我们可能会怀念 CSS-in-JS 提供的某些便利性，但我们相信好处远远大于代价。

结论

与 CSS-in-JS 的分手并不是一件容易的事，但我们相信这是我们应用程序的正确道路。传统的 CSS 方法为我们提供了更好的性能、更高的可维护性、更简单的代码拆分和更小的捆绑包大小。虽然 CSS-in-JS 仍然可能在某些情况下有用，但我们认为对于大多数应用程序来说，它并不是一种可持续的解决方案。