CSS样式开发未来的三项技术——SASS、CSS-in-JS和TailwindCSS

现在（2022）的Web开发 在工具选择上 真是太多了，就「前端样式」^注 一项任务就有很多技术供选择，本文说说CSS三项主流技术的特点和区别。

本文在此文（SASS vs CSS-in-JS vs TailwindCSS）基础之上改写而成，加入自己的见解。

SASS

作为对「原生CSS」的功能扩展，预处理技术（preprocessor），像SASS，相信是很多人一直以来的 CSS 开发技术方案。「原生CSS」本身是很容易学，但写出来的“程序”很难维护。「难维护」的意思是，当项目增大时（包手增加人手），添加新功能和修改原来功能 都很费劲。

提高「可维护性」的一点，是项目的「样式功能」 必须有一种客观的结构，团队一致认同的 「样式结构」，这样可以降低编程维护时的推理成本。BEM (Block Element Modifiers)  就是这样的一种总结客观样式结构的尝试。

预处理技术 再加上 BEM 能提高 「样式开发和维护」体验，但是它们并不完美。还有一些需求是它们不能很好解决的。例如，随着 代码库（codebase）的增长和演化——新功能的添加和旧模块的重构，你常常要考虑 一项「特定的样式定义」 应该放在哪个文件上最好；你可能还要考虑「某个旧样式定义」还有没有被用，可不可删除；或者，你还得考虑 性能问题，因为你肯定会质疑 在 首页就加载 所有样式定义，而大部分的样式定义 都在其它页面才用。

CSS in JavaScript 就是针对 预处理技术 不能很好解决的这些问题。

CSS-in-JS

「用JS来写样式」 是一种思想（就像用JS来写HTML结构定义），目前主要有几种实现： Styled-Components， Emotion和Styled-JSX 。

将 页面分割成为不同的 UI组件，每个组件都有自己独立的JS，CSS和HTML，这种思想的确很有新意，很吸引，因为 独立封装的组件在开发、维护，和复用上会非常的容易。

将样式集成入 UI组件，再也不用考虑 名字冲突 ，和全局结构（BEM）的问题，不用再考虑如何存放CSS定义的问题了。

另外，也不用考虑 页面会有多余的样式定义而造成 性能问题，因为只有组件被渲染页面时，样式定义才会被用。

CSS-in-JS技术 的学习和使用 看起来 要比 SASS技术 要复杂一些，因为学习曲线是有的。不过，如果你的项目 非常适用 组件化开发，那学习和使用 CSS-in-JS 是很值得的。

TailwindCSS

TailwindCSS 是比较新的一支 ==CSS框架==，说是==框架==， 但和传统的 组件式 框架，像Bootstrap ，Antd 等很不同。传统的 组件式框架 会为用户提供大量常用 的 UI组件，像buttons，cards和 alerts，TailwindCSS 只有 很底层原始的 “utility” ，并且 宣称 使用 “utility”不用离开HTML，效率更好。这就是 时髦的原子式 CSS。

使用 传统的 组件式 框架 有一个最大的问题，就是现成的组件半成品很难改，并且会附加很多你不需要东西，灵活和性能都不好。相反，使用 Tailwind，这些问题都不存在。你可以自由组织 想要的设计。

另外，Tailwind 还支持 in-line 开发 交互样式（像 click hover），和响应式样式。

Tailwind 最多被吐槽的点是，如果组件 非常特殊， “utility”的声明会很长，阅读性很不好。

我看Tailwind

1 如果tw算框架（有半成品的），那也是非常的薄；daisyui这样才是传统 观念的web UI框架

2 tw最大意义是，以一定的效率牺牲（我指工程效率） 换来 灵活性，但也不至于非常的原始，它提供大量基础设计和u类（调值板），还有inline postcss语法糖（如 hover:）

3 规模应用 有工程性，任务量大，代码复杂，它需要工作效率，需要样式有精致的可维护架构，复用机制。传统css框架（像 bulma bootstrap）有效率，但是一定会带来不适用于你的项目的多余代码，和设计，灵活性下降。

小结

当你的 web应用的规模不断增长 ，样式 任务是个问题，需要专业技术，和半成品，帮助快速有效的开发。专业技术包括 样式定义方式，组建复合样式方式，管理复用方式等。

参考

• 《Tailwind CSS Tutorial for Beginners: A Guide to Get Started》