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

最新推荐文章于 2024-08-31 21:18:22 发布

码农巧克零

最新推荐文章于 2024-08-31 21:18:22 发布

阅读量837

点赞数 8

分类专栏：前端开发程序员编程文章标签：前端开发语言

本文链接：https://blog.csdn.net/weixin_47588164/article/details/141500653

版权

前端开发同时被 3 个专栏收录

149 篇文章 0 订阅

订阅专栏

程序员

149 篇文章 0 订阅

订阅专栏

编程

149 篇文章 0 订阅

订阅专栏

上图来源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: ...，那么你需要在每一个元素类名上书写所有这些前缀的样式

真的你会写疯掉，因为每增加一个主题，意味着你要在源码中所有元素身上加上新的主题和样式类名，想象一下如果有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插件强依赖、构建工具强依赖等等诸多缺点。