像需要团队协作的vue3项目用这个框架怎么样呢？想问问思否大佬们的意见。
这怎么能算旁门左道？tailwind只是css的一种工程思路，或者方式，他相当于对基本css的属性进行了一次语义化的包装和统一，你有css的管理能力，你可以用.main .container .info .article 等等这样的类名对项目的所有css统一管理一下，没有问题。你也可以用tailwind这种css，大脑里想到什么样的效果，就在css里写什么样的效果，不用再去写css。看你的项目性质和你们团队的人员搭配等等多种情况。
个人认为不属于，使用这个的基础就是你要会用 CSS，并不会降低对你 CSS 能力的要求。
相对来说，这只是一个效率工具。
不少人嘴上拒绝着……，实际上自己却又封装了不少，重复造轮子。 🥲
在html中写密密麻麻的一片，确实看着难受
这个可以用 @apply 指令，不知道新版有没有改动。
国内基本上没公司用
这类工具有个名字 “原子化 CSS”，实际上不少网站都有自己封装一些原子化 CSS，用的还是蛮多的。
个人觉得这东西的好处就是适合 C/V ，别人的代码直接 Copy & Paste 就可以达到效果，几乎不用考虑再去写(拷贝) CSS 样式。
先说结论，我个人以及团队是不会用类似这种css框架的（更适合后端搭建简单页面使用）。
这个框架当然也有有点：方便开发人员，优化项目体积！
维护过别人写的项目，标签没有具名class，一堆类似这样的代码：
极客观点
项目管理
HarmonyOS
<div class="w-40 h-3 bg-gradient-to-br from-fuchsia-500 to-purple-600"></div>相似度极高，想要维护的话，不知道从哪儿入手，本来改代码只需要一分钟，找代码可能要用2小时（夸张了点，但这种项目维护起来就是不爽）
如果class如果是各种变量拼凑出来，更加难维护，html看起来也乱。相当于行类样式的封装吧。
用时一时爽，维护火葬场！
如果这个项目团队成员都能熟练驾驭的话，那么用起来还是蛮爽的，但是有不会的，那么当你维护的时候真的痛苦的要死，tailwind的代码和成员封装的css傻傻分不清楚，真的痛苦极了。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
不属于旁门左道吧，其实之前就有原子类的用法，比方说一个css文件里面定义很多个原子类，如.fontSize14,.fontSize18这样的，如果一个Dom元素需要设置字号，直接加原子类就行。TailwindCSS也是这个用法。
不好维护CSS的点主要是在于，渲染后的页面，找不到对应的Class，不知道是在哪一行加的行内class，调试确实麻烦。
但如果你能快速定位到某个文件某一行，这个问题在一定程度上也是可以避免的。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
我刚了解的时候也觉得是旁门左道，因为和平时开发流程和自己的习惯非常不符合。之后的偶然一天看到之前用sass封装的布局和设计相关的边距、圆角等，突然发现我做的和它反而是一致的。
后来了解一下同事，不用无非是不想一上来就记这么多class。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
2015年前就接触前端的同学对 bootstrap 一定不默认，好多项目 jquery/bootstrap.js/bootstrap.css 再结合各种的插件一把梭。
tailwindcss 更像是 bootstrap.css 的增强版，而且很多团队在这之前，使用 mr-5 / border-5 这种css风格。
好多人称 tailwind 是css原子库，因为class比较细，一般项目中使用还需要再进一步封装，或者基于上层css库（比如：daisyUI）。可见 tailwindcss 并不是什么银弹，项目中是否使用还是主要看目前的UI库、css处理、浏览器兼容要求来决定，一定不是因为新鲜或热度高而用。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
只是一种解决方案而已，你觉得不适合自己可以不使用。关于CSS已经出现过很多方案了，就拿css in js来说，也是很多争议，但实际很多大型项目都在使用，但很多项目根本用不上这玩意，不需要也没必要。
往往一个新的技术方案出现，是为了解决一些具体问题的，而不是说来代替现有的方式。比如less和scss，其实在现阶段已经是一种比较完美和普适的解决方案了，几乎所有项目都能胜任，并且解决了CSS的根本问题。但是他依然是为了解决具体问题而出现的，那就是写原生CSS太麻烦和浪费时间了。
你觉得不行，可能只是你现在觉得用不上，说不定未来某天会用上。你觉得完美的，说不定未来某天会被淘汰。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
tailwindcss我刚刚晚上试了一把，还是挺好用的，像我之前经常用bootstrap的，上手还是非常快的，对我们这些不会前端的开发来说还是非常方便的，因此我觉得不属于旁门歪道，不过后期维护起来好像会不太方便的样子，
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
只能说是另外一条路，但是这条路并不一定适合大部分的研发团队。特别是在境内特有的一些UI设计师手下。tailwind大部分的预设并不能满足你日常的开发需求，还是需要大量的手写css才能满足。
tailwind在国外比较流行有很大一部分原因就是这个。
当然也有一些厂对于设计有一套完整的规范的，那么在项目伊始配置好主题就可以了，中途很少会出现每一块UI细节都不一样的情况（但是我见过的很多UI都是喜欢各个地方都做一些差异来凸显“设计感”）。
使用tailwind的好处肯定是有的，可以减少相当一部分的工作量，其实大部分人在项目中也会预设一些公共的原子类来使用。只不过不能接受class写一堆的情况而已，就很很多人讨厌同事写行内样式一样。想要模板/样式/业务代码分离开来。
另外一个就是学习成本，需要记很多样式的简写。虽然挺好记的，而且比原先的CSS属性短多了，但一开始不熟悉的时候还是需要去对照文档来查询对应的简写是什么。
我个人的想法是不一定非要完全都按照原子类的方式来写项目，可以适当的穿插着使用，起到便利的作用。而不是为了写tailwind而去按照他的规则来写样式。
也不能说一定就不可以用原子类的方式来实现公共样式，然后舍近求远的使用预处理器的继承和mixins来实现。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
class 太长可以自定义 class，或者 css in js，把 js 和 css 分开，避免看着乱。
tail 写起来很快，跟 boostrap 类似，对后端开发人员很友好。好的东西，肯定有他存在的理由。
让时间来证明吧。
个人感觉不是，我觉得它真正强大的地方在于，对UI场景迭代频繁的项目来说。有利于将UI规范和前端流程整合，使用它的开发效率会成倍提升，很多场景下并不多见。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
3 回答4.3k 阅读✓ 已解决
6 回答1.9k 阅读✓ 已解决
3 回答1.4k 阅读✓ 已解决
3 回答1.6k 阅读✓ 已解决
2 回答2.5k 阅读✓ 已解决
2 回答1.8k 阅读✓ 已解决
2 回答1.7k 阅读✓ 已解决
别的不说，旁门左道这个词有点过分了。
很多同学对待技术有一种非黑即白的态度，这是个很差的习惯。技术都有优势，也有劣势；有适用的场合，也有不适用的场合。适合用我们就用，不适合用我们就不用。
拿 TailwindCSS 来说，没有规定我们必须用且全用且只用 TailwindCSS，我们完全可以把它当成一个现有前端框架的补充。比如我厂的产品，原本用了 element-ui，现在写页面的时候，两个组件之间需要有一些间隔，以前可能是写一个
<style scoped> .xxxx { margin-top: 10px } </style>，现在直接一个.mt-2就搞定了，方便得多。我认为完全用 TailwindCSS 写项目会比较累，有不小的学习成本，也影响代码阅读。但是配合其它整套的组件库就很合适。而且 TailwindCSS 写出来的 HTML 迁移成本很低，复用方便，推荐大家学习。