纠结多年终于决定彻底放弃Tailwindcss

上图来源Fireship

团队代价=深入成本

Tailwindcss很容易火，因为从看到它的的第一眼就会觉得超级直观、超级简单、超级方便，所以无论是写文章 出视频 都很容易吸引一波流量。

但是真要用在企业级应用我们需要考虑全部的复杂性，你至少要吃透官方文档的大部分内容，最好是写几个稍微复杂点的Demo，光是吃透文档就需要至少10小时以上的成本你才能彻底在企业级应用all in tailwind，如果你的团队有10名前端同学，你们将会付出100个小时的代价，这些代价不光是个人的，更是企业的损失，而花了这100小时掌握之后能够靠那一点点便捷提速弥补损失吗？不能。或许100小时早就用以前的方式写完了全部样式。团队还会扩大，新招进来的同学还得培训一下。

范式强偏好

Tailwindcss是非常opinionated强偏好的，他会鼓励一种他们特定的范式和规则，这种规则不是通用的，是tw创新的。那scss less是不是强偏好呢？不是，因为你还是以标准的css范式书写，只是scss less给你提供了额外的语法和工具方法 你的范式没有改变。

tw强偏好的范式包括不限于：

• 
  
• tailwindconfig 配置文件
  
• 默认主题、工具类
  
• 行内class书写规则
  
• IDE插件
  

强偏好本身没有对错之分，通常我们使用UI组件库就是强偏好的，但是对于样式的书写，这种强偏好会缺少一定的规范一致性，说白了就是潜规则太多了。

强IDE插件依赖

没有IDE的插件提示，tw基本不可用，因为你可用的类名强依赖与上面说的范式中的tailwindconfig配置文件。

但是这好像也没什么问题，装个插件也很轻松，事情没这么简单，你失去了静态类型检查 和可测试性。假设你写了个错误的类名shadows，tailwind插件可不会给你报红，而传统的css样式文件是会报红的。

既然静态阶段无法发现这个错误，那编译时能不能发现呢？也不能，tw会将主题中未定义的类名 当成你自己的类名，所以对tw来说不是错误。

单元测试？很遗憾，也不行，这个范式最大的好处也是最大的缺点，样式全部在类目中，你不可能去equal所有的类名 这样就没有用tw的意义了。

所以tw最方便的地方，也是最容易出错且难以被发现的地方。

完全错误的主题范式

官方文档提供了Dark Mode暗色主题切换的方式，但是如果现在客户提个需求，需要增加4套颜色主题 和亮暗色无关 就是额外的主题，你会发现tw根本没有考虑到这点(或者说很难实现，网上几乎没有解决方案，我有但我不说😝(下面补充解释了）

tw是通过类名中以dark:前缀开头来表示暗色下的样式，默认不加就是亮色， 所以你根本无法增加这两种主题以外的更多主题，你只能在亮色暗色这两之间切换，这就是tw官方强偏好导致的弊端。

我们假设，即使tw实现了可以增加主题前缀比如 onedark: monokai: ...，那么你需要在每一个元素类名上 书写所有这些前缀的样式

<div

  className="

  bg-blue-500 //亮色

  dark:bg-blue-700 //暗色

  onedark:bg-black-900 //onedark主题

  monokai:bg-gold-600 //monokai主题

  kanagawa:bg-green-200 //kanagawa主题

"

></div>

真的你会写疯掉，因为每增加一个主题，意味着你要在源码中所有元素身上加上新的主题和样式类名，想象一下如果有20个主题，你一个标签的类名可能就占了100行。

并且你无法动态增加主题，因为tw是编译时的，生产环境下，你无法实现让用户自己任意配置主题、持久、载入这样的功能。

总结

文章还会更新，想当什么补充什么。以上几个最大的痛点是导致我对这个库关注多年，尝试多次，却迟迟没有投入使用，最终决定放弃的原因。我相信肯定很多同学会有同感，也会有很多持反对意见，非常欢迎评论区讨论，如果真能解决这几个大痛点，我会毅然决然All in tw。

↓↓↓↓🆕 以下为更新内容 时间升序↓↓↓↓

2024-08-22 17:45:21

难以调试

实现复杂UI会让类名又臭又长，无法根据类名理解样式，影响对html结构的浏览

来对比看一下传统类名的可读性，这是MDN网站的类名，干净整洁，一眼就知道每一个标签块代表什么内容

类名即样式导致dev tool中无法通过style面板根据特定一类元素修改样式，因为你改的是工具类名 而不是一类元素的类名，例如修改.text-left {text-align: right} 会将所有元素的样式修改完全不符合预期

菜就多练？

好吧我猜到评论区会有此类不和谐的声音，怪我没有事先叠甲，但是文章的开始其实已经说的很清楚了，个人能力再强是没用的，开发从来不是一个人的事，在公司需要跟同事配合，在开源社区需要和世界各地的开源爱好者协作。

如果你是组长、技术经理、CTO甚至老板，你一定要站在团队的角度对新兴技术栈评估收益比，因为对于企业来说商业价值永远是第一位的，所以你不能只考虑自己的效率，还要考虑团队整体的效率和质量。

如果你是开源作者，你也要为贡献者的参与门槛考虑，如果你的技术栈不是主流 只是一小挫人会用 甚至难度极高，那么你很难收获世界各地的爱心，只能自己一个人默默发电。你甚至要考虑技术栈的可替换性，因为我们大部分的依赖库都是开源的，人家也是为爱发电，意味着人家很有可能哪天累了不再维护了，你要留足能够用其他库或框架平滑替换的可能，否则为了某个库的废弃你可能需要做大量的重构工作甚至Breaking Change破坏性升级，再甚至你也没办法坚持下去了，因为你花了大量的时间在填坑而不是专注于自己项目的开发。

复杂性守恒原理

泰斯勒定律 复杂性守恒，临界复杂性不能凭空消失 只能被转移。我经常用这个原理审视各种新兴技术栈的两面性，因为你们懂得-前端娱乐圈，经常会出现很多让你快乐的新东西，而往往容易忽视背后的代价。当我们收获巨大的简化后，一定要思考 曾经的复杂性被转移到哪里去了呢？如果你能搞清楚两面性，仔细评估后再做决定，会走的更顺。

就如上面所述，tw在简化的背后，牺牲了静态类型检查、单元测试、调试、运行时动态主题载入、文档强依赖、IDE插件强依赖、构建工具强依赖等等诸多缺点。

2024-08-23 17:53:51

关于tw错误主题范式的补充

掘友还是很多大佬的，评论区发表了很多关于解决主题受限于默认和dark这两种的局限，这里补充一下我自己的方式

tw配置文件 theme中不配置darkMode，将所有主题值绑定css变量如 colors: {primary: 'var(--primary)'}，然后依然是动态控制css变量来切换主题。

坏处很多: classname不再允许使用dark变量；tw配置麻烦，变量套变量需要两边维护，css变量文件 和tw配置要保持同步；

我为什么前面不把解决办法说出来？因为不重要。

tw是范式强偏好的，首先理解什么是范式？我的理解是很有fan的方式就是范式，有fan的前提是流行、统一。

所以我们在使用强偏好的库时，一定要在范式之内，不要自己创新方式，否则你会脱离流行、统一、一致性，并且会因为库的迭代升级导致适配问题，并且会与其他人无法达成共识 你们之间的技术经验产生越来越大的偏差 为合作带来困扰。

如果我遵循tw范式不魔改，与别人协作只需要告诉别人“看tw文档就行了”；但如果我不遵循，魔改了主题范式，我需要格外提醒别人“注意! 我们的主题不是按tw用的 请不要写dark:xxx”

这还只是一例，如果项目中有10例你自己创新的范式别人就很难快速上手了

2024-08-24 00:36:52

与tw同样方便的CSS in JS用法

上图是react中使用styled-component(后面简称sc)结合style工具写的一段样式，它既能拥有sc组件即样式的好处 又能拥有类似vue中样式分离且scoped的方便。

还能倒过来，jsx在上面，style在下面

通用组件通常用sc组件即样式来定义

const Button = styled.button`...`

view组件(业务域)通常结合sc组件和style来灵活使用

...
return style`font-size: 12px;`(
<div>...</div>

)

我们还能将常用样式抽离出来，达到如同tw的方便程度

return style`
${[button.md, bg.200, text.color.primary]}

`(<Button>...</Button>)

如果样式很长，你可以抽离，也可以直接折叠，完全不需要像tw那样还需要vscode插件

篇幅关系，只是简单介绍，后续可能单独出个文章细讲css in js

2024-08-27 12:52:07

@apply解决类名过多的问题？

评论区出现多个建议用@apply在css复用类名的样式来减少class中书写类名，因此觉得有必要单独拿出来讲一下给大家避坑。

结论是千万万万不要这么用！这就是文档没看完，上手就用犯的错误，10小时的学习成本你是逃不掉的，不然以后麻烦就会找上你。

在tw官方文档中明确强调不要以减少类名为目的使用@apply，鼓励你就把所有类名写在class中。

上图来源 tailwindcss.com/docs/reusin…

除此之外，@apply语法其实是一个被废弃的css标准语法，曾经在chromium内核中被短暂实现过，后来废弃掉了，废弃的原因也是因为会破坏常规书写类名+样式的范式，会导致用户无节制的重用类名样式，最终无法溯源，修改困难。