为什么中后台业务不适宜采用Tailwind CSS呢？
- 内容介绍
- 文章标签
- 相关推荐
翻车了。 最近刷技术社区总觉得有点魔幻——打开推送十篇有八篇在吹Tailwind CSS多好用,“写完JSX直接跑,omg太香了!”“告别CSS文件!效率翻倍!”搞得我这个做了五年中后台开发的老腊肉都忍不住怀疑:难道现在前端圈都飘了?连中后台这种重型项目都敢往上套Tailwind?
别杠!先听哥唠唠上个月刚踩过的坑——接手一个所谓“全链路Tailwind化”的中后台系统重构任务,交接时对方拍胸脯说“效率提升50%”,后来啊我打开代码那一刻差点背过气:一行Table组件上挂了二十多个className,像极了菜市场阿姨捆白菜时乱缠的绳子,“bg-blue-50 :py-2 text-sm ml-”挤在一起连换行都没有…当时我就想说:兄弟,you是不是对“维护性”这三个字有什么误解?，摆烂。
你以为省了CSS文件,其实是把屎堆进了JSX
先说说Tailwind最引以为傲的“实用优先”:不用写独立CSS文件,直接在HTML/JSX里怼类名。听起来很爽对吧?但哥想问一句——当你的组件里既要处理用户权限判断、 又要渲染动态数据、还要兼容不同设备时,“flex p-4 mb-2 text-gray-600”这种字符真的不会干扰你看业务逻辑吗?，啥玩意儿？
尊嘟假嘟？ 举个真实到扎心的例子:之前有个同事写发票卡片组件,Tailwind版本长这样: {data.serialNo} {data.label}
看着好像没问题?但当产品说“管理员权限下要展开卡片显示详情”时,you猜怎么着?这位兄弟直接在JSX里加了个三目运算符:className={isAdmin ? "flex justify-娱乐ween ... expan 这是可以说的吗？ ded-style" : "flex ..."} —— expanded-style又是一串新类名!等半个月后我接手改bug时,光看这串className就得花十分钟猜:到底哪个类控制了展开后的高度?哪个又影响了字体颜色?
一言难尽。 再对比一下用Less Modules写的版本: less .invoice-card { display: flex; justify-content: space-娱乐ween; padding: 16px; margin-bottom: 8px; // ...其他基础样式 } .invoice-card--admin-expanded { height: auto; // ...展开后的专属样式 } JSX里直接,是不是瞬间清净多了?业务逻辑归业务逻辑,样式归样式——这不是什么老掉牙的教条,是咱做中后台开发保命用的底线啊!
团队协作不是个人秀场,Tailwind会变成“风格屠宰场”
中后台项目从来不是一个人在战斗——十几号人摸同一个代码库,you能保证每个人对Tailwind类名的理解都一致吗?
哥见过更魔幻的事:前端组三个小朋友改同一个按钮样式,A喜欢用mt-2,B偏要用py-1 px-2代替p-2,C甚至发明了w-这种任意值写法…表面上看效果都差不多,“按钮居中对齐了”,但三个月后新人入职一看代码:哇塞?为什么有的地方用text-sm有的用font-?为什么同样是红色背景有的写bg-red-500有的写bg-?，在理。
更要命的是没有注释空间!传统CSS里还能写/* fix ie11兼容问题 */,Tailwind类名堆在一起连插个注释位都没有——等半年后产品说“这个按钮颜色要改深一点”,你敢删任何一个类吗?万一删错了负边距导致布局崩掉,who背锅?，求锤得锤。
和组件库对着干,Tailwind就是在自讨苦吃
咱做中后台谁不用Ant Design/Element Plus这种重型组件库?这些库之所以牛叉,是主要原因是它 靠谱。 们封装了一整套稳定且规范的DOM结构和样式体系——但Tailwind偏要跟它们唱反调:“我要覆盖你的默认样式!”
事实上... 就拿Table组件举例子:Ant Design默认表格 header 背景色是#fafafa行高48px.产品说要改成浅蓝背景+行高40px.正常做法是什么?找Ant Design文档查classname穿透),然后在Less文件里覆盖:background-color:#e6f7ff;padding-top:8px;padding-bottom:8px;` ——简单直接还不影响其他组件.
但偏有人要用Tailwind式写法:…Excuse me?这是什么阴间操作?!等下次Ant Design升级版本内部classname变了,你这串 className不就成了摆设?到时候要么硬着头皮改所有表单项,要么留着过时代码.，你看啊...
哥奉劝一句:Tailwind可以用来微调小元素,但想覆盖重型组件库样式?还是老老实实回去写CSS穿透吧!
长期项目不是快餐,Tailwind的补丁会变成屎山
中后台系统生命周期有多长?短则两年长则五年甚至十年!在这么长时间里需求会变、人员会流动、浏览器版本会更新——而Tailwind最容易滋生一种毒瘤:为修复问题而不断加补丁.，PPT你。
举个经典案例:A同学做登录页输入框对齐时发现有点歪,“随手”加了个ml-;B同学两个月后改密码强度提示,“哦这个提示框有点挤再加个mt-”;C同学半年后适配移动端,“这个输入框在iPhone14上有点错位 反正吧… 再加个pb-…” ——等一年后新人看这个输入框组件时,:className= "w-full p-3 border ml- mt- pb-" ——谁能告诉我这些前缀到底啥意思?!删哪个会崩UI?谁知道啊!
反观传统CSS写法:就算改十次对齐问题也不过是在LESS文件里加几行新选择器注释清楚原因 ——至少后人能顺着注释找到源头!
Tailwind不是敌人,只是选错了战场
别误会哥不是 Tailwind黑啊!它在该发力的场景里真特么香:比如独立开发者快速搭官网,H5活动页赶工期,SaaS产品原型验证…那种不需要长期维护、不需要团队协作、不需要兼容复杂组件库场景,Tailwind简直就是哆啦A梦口袋里の时光机——分分钟搞定UI还不用管后续扯皮.
动手。 但中后台不一样啊!它像是一家开了十年の老饭馆:T ail wind像那种网红速食店装修得花里胡哨却只火三个月;而传统CSS+模块化像是老馆子の秘方菜单——虽然不够时髦却能稳定出品十年二十年客人来了闭着眼点单都不会踩雷.
再说说想说…
技术选型从来不是越流行越好而是要看「能不能扛事」.中后台要の是什么?is稳定性?is可维护性?is业务逻辑清晰可见?如果答案都是yes那麻烦对T ail wind温柔 say no好吗，摸个底。？
毕竟我们写代码不是为了当一时の酷guy而是为了当那个能让项目活过三年五年还能笑着交接给下一届の负责人呀～，正宗。
翻车了。 最近刷技术社区总觉得有点魔幻——打开推送十篇有八篇在吹Tailwind CSS多好用,“写完JSX直接跑,omg太香了!”“告别CSS文件!效率翻倍!”搞得我这个做了五年中后台开发的老腊肉都忍不住怀疑:难道现在前端圈都飘了?连中后台这种重型项目都敢往上套Tailwind?
别杠!先听哥唠唠上个月刚踩过的坑——接手一个所谓“全链路Tailwind化”的中后台系统重构任务,交接时对方拍胸脯说“效率提升50%”,后来啊我打开代码那一刻差点背过气:一行Table组件上挂了二十多个className,像极了菜市场阿姨捆白菜时乱缠的绳子,“bg-blue-50 :py-2 text-sm ml-”挤在一起连换行都没有…当时我就想说:兄弟,you是不是对“维护性”这三个字有什么误解?，摆烂。
你以为省了CSS文件,其实是把屎堆进了JSX
先说说Tailwind最引以为傲的“实用优先”:不用写独立CSS文件,直接在HTML/JSX里怼类名。听起来很爽对吧?但哥想问一句——当你的组件里既要处理用户权限判断、 又要渲染动态数据、还要兼容不同设备时,“flex p-4 mb-2 text-gray-600”这种字符真的不会干扰你看业务逻辑吗?，啥玩意儿？
尊嘟假嘟？ 举个真实到扎心的例子:之前有个同事写发票卡片组件,Tailwind版本长这样: {data.serialNo} {data.label}
看着好像没问题?但当产品说“管理员权限下要展开卡片显示详情”时,you猜怎么着?这位兄弟直接在JSX里加了个三目运算符:className={isAdmin ? "flex justify-娱乐ween ... expan 这是可以说的吗？ ded-style" : "flex ..."} —— expanded-style又是一串新类名!等半个月后我接手改bug时,光看这串className就得花十分钟猜:到底哪个类控制了展开后的高度?哪个又影响了字体颜色?
一言难尽。 再对比一下用Less Modules写的版本: less .invoice-card { display: flex; justify-content: space-娱乐ween; padding: 16px; margin-bottom: 8px; // ...其他基础样式 } .invoice-card--admin-expanded { height: auto; // ...展开后的专属样式 } JSX里直接,是不是瞬间清净多了?业务逻辑归业务逻辑,样式归样式——这不是什么老掉牙的教条,是咱做中后台开发保命用的底线啊!
团队协作不是个人秀场,Tailwind会变成“风格屠宰场”
中后台项目从来不是一个人在战斗——十几号人摸同一个代码库,you能保证每个人对Tailwind类名的理解都一致吗?
哥见过更魔幻的事:前端组三个小朋友改同一个按钮样式,A喜欢用mt-2,B偏要用py-1 px-2代替p-2,C甚至发明了w-这种任意值写法…表面上看效果都差不多,“按钮居中对齐了”,但三个月后新人入职一看代码:哇塞?为什么有的地方用text-sm有的用font-?为什么同样是红色背景有的写bg-red-500有的写bg-?，在理。
更要命的是没有注释空间!传统CSS里还能写/* fix ie11兼容问题 */,Tailwind类名堆在一起连插个注释位都没有——等半年后产品说“这个按钮颜色要改深一点”,你敢删任何一个类吗?万一删错了负边距导致布局崩掉,who背锅?，求锤得锤。
和组件库对着干,Tailwind就是在自讨苦吃
咱做中后台谁不用Ant Design/Element Plus这种重型组件库?这些库之所以牛叉,是主要原因是它 靠谱。 们封装了一整套稳定且规范的DOM结构和样式体系——但Tailwind偏要跟它们唱反调:“我要覆盖你的默认样式!”
事实上... 就拿Table组件举例子:Ant Design默认表格 header 背景色是#fafafa行高48px.产品说要改成浅蓝背景+行高40px.正常做法是什么?找Ant Design文档查classname穿透),然后在Less文件里覆盖:background-color:#e6f7ff;padding-top:8px;padding-bottom:8px;` ——简单直接还不影响其他组件.
但偏有人要用Tailwind式写法:…Excuse me?这是什么阴间操作?!等下次Ant Design升级版本内部classname变了,你这串 className不就成了摆设?到时候要么硬着头皮改所有表单项,要么留着过时代码.，你看啊...
哥奉劝一句:Tailwind可以用来微调小元素,但想覆盖重型组件库样式?还是老老实实回去写CSS穿透吧!
长期项目不是快餐,Tailwind的补丁会变成屎山
中后台系统生命周期有多长?短则两年长则五年甚至十年!在这么长时间里需求会变、人员会流动、浏览器版本会更新——而Tailwind最容易滋生一种毒瘤:为修复问题而不断加补丁.，PPT你。
举个经典案例:A同学做登录页输入框对齐时发现有点歪,“随手”加了个ml-;B同学两个月后改密码强度提示,“哦这个提示框有点挤再加个mt-”;C同学半年后适配移动端,“这个输入框在iPhone14上有点错位 反正吧… 再加个pb-…” ——等一年后新人看这个输入框组件时,:className= "w-full p-3 border ml- mt- pb-" ——谁能告诉我这些前缀到底啥意思?!删哪个会崩UI?谁知道啊!
反观传统CSS写法:就算改十次对齐问题也不过是在LESS文件里加几行新选择器注释清楚原因 ——至少后人能顺着注释找到源头!
Tailwind不是敌人,只是选错了战场
别误会哥不是 Tailwind黑啊!它在该发力的场景里真特么香:比如独立开发者快速搭官网,H5活动页赶工期,SaaS产品原型验证…那种不需要长期维护、不需要团队协作、不需要兼容复杂组件库场景,Tailwind简直就是哆啦A梦口袋里の时光机——分分钟搞定UI还不用管后续扯皮.
动手。 但中后台不一样啊!它像是一家开了十年の老饭馆:T ail wind像那种网红速食店装修得花里胡哨却只火三个月;而传统CSS+模块化像是老馆子の秘方菜单——虽然不够时髦却能稳定出品十年二十年客人来了闭着眼点单都不会踩雷.
再说说想说…
技术选型从来不是越流行越好而是要看「能不能扛事」.中后台要の是什么?is稳定性?is可维护性?is业务逻辑清晰可见?如果答案都是yes那麻烦对T ail wind温柔 say no好吗，摸个底。？
毕竟我们写代码不是为了当一时の酷guy而是为了当那个能让项目活过三年五年还能笑着交接给下一届の负责人呀～，正宗。