[吐槽]这个世界上为什么会有 Tailwind Css 这种东西？

看是不好看，但写的时候配合预览，就写得很爽。

我也觉得奇怪，这样写好丑啊，不知为什么流行起来了。

手写 style 的最大的不方便在于，如果你想重构这个组件，那么这个组件的 CSS 你也要重构，一次要同时给改两个文件，很多时候你自己也搞不清了最后就是重写一遍。
这种原子 css 看起来很繁琐，但实际上写起来无比顺手，想改哪里改哪里，结构和样式都在一个地方，不会出现不同步的问题

快速出原型

一切崇拜缩写的语言 /框架，我都不会学的...

@noe132 没明白，你说的组件是可复用的组件吗，为什么需要改两个文件。说到这里，我想说的问题是，例如我的项目，对于所有的按钮都有特定的样式，用这种方式要写很长一串，要是有变动，比如 border-radius 由 4 改成 5 ，那基本上每个按钮都要改，用 class 方式的话，我直接改 .button 的代码就可以了哇

tailwind 也可以复用，个人觉得 tailwind 主要解决了取 class 名的问题

主要是解决了部分组件类框架想做自定义修改很难下手的问题

确实太丑了，我要写内联风格的样式时，也是有格式的

原来写 css 要在 HTML 里面写 class 然后在 style 标签里面写样式，不管是一个文件还是两个文件都要翻来翻去，还要考虑 class 起什么名。现在直接在行内写就不用想 class 名和来回翻了。而且在 vue 和 react 里面行内样式要写成对象的形式，用 tailwind 就可以直接写类名改样式了。
至于你说的一个 class 可以用在多处和 tailwind 不冲突，如果有样式重复的地方同样可以单独拿出来。

tailwind css 可以认为主要是 规范（颜色、行高、边距....） + 响应式的 style ，不想写很长也可以，换成 @apply 也可以剩一个样式名。

就是有半天的上手学习成本，初期使用要常翻文档，vs code 装点插件会好点。熟悉了还是挺香的。

原子化 css 和组件化 css ，看你怎么取舍了，没有非此即彼

写起来很爽

风水轮流转
以前的非组件化开发
css 分离出来，可以使用 class 同时修改多个地方的样式

现在组件化开发

一个组件的 css 和结构放在一起，方便修改调整


瞎说的，不会前端.....哈哈哈哈哈哈

2012：页面结构与样式要分离，会更容易维护
2022：页面结构和样式本来就是耦合的，写在一起才更容易维护

@noe132 你是不是对 css 有所误解。。。

现代化 js 框架 + webpack 不应该有 scoped css 用吗？

比如 vue one file component

tailwind 要学一套 DSL 是有点麻烦，但是也不难上手，都是有规律可循的，多写几次再配合查文档就好了

更深层的好处在于样式变成了原子化的，减少了重复，也减少了冲突的概率

相信我，一旦你写习惯了就会真香的。别看着觉得难受就不上手试试。

少打些字不好？
绝大多数样式本来就没多少，两三个以内搞定舒服的很
太长了想抽一个名字也行

CSS 本来就有两种不同的应用场景：

- 一种是批量给文档设置样式，这种情况更符合 CSS 的最初用意，也推荐样式和内容分离；
- 另一种情况 HTML 没有自己的实际意义，比如你要画个蓝色方块，这个时候 HTML 节点有什么脱离样式的特别语义吗？所以这种情况下 HTML 和 CSS 就应该结合，这里的 HTML+CSS 就是种描述性绘图工具。现代的框架也都是这么干的，所以 Tailwind CSS 在这里就很舒服

很合适 short term 产出，但是 long term 的话很容易出现屎山堆积的情景，还是 styled-component 香。

你写前端不用组件不用库的吗？

出活速度快就是很大的优势，而且我也没觉得有啥不好的，反正每个组件都不大，看起来很清晰。

但如果你喜欢写大组件……这个习惯似乎更不好？

今年 google I/O 的官网就用了 tailwind.css 哦

@ipwx scoped css 是很好用，不过它解决的是 namespace 的问题。我之前写 React 也能通过 babel 实现像 vue 一样的 scoped css ，不过最后用上 tailwind 后，css 写的越来越少了，最主要的原因就是你想重构 / 修改某个组件，直接剪切复制粘贴 jsx 就达到了把结构样式逻辑一次性调整到位的目的，不需要再到 css 里去修改类名啥的了。

上生产了，，虽然是国外
大型政府项目，tailwind 一把梭

在我看来就是把 css 写在标签上，然后语法简化了一下。

op 这么说, 一定是没有维护过老项目. 特别是别人写的老项目.

比如, 某个页面的某个 DOM 要改样式. 我打赌你肯定不敢直接改 DOM 对应的 css 内容. 因为你不知道改掉后, 其他页面会不会崩掉.

觉得直接写到 class 里面太碍眼，也可以这样写：

```css
.select2-dropdown {
@apply rounded-b-lg shadow-md;
}
.select2-search {
@apply border border-gray-300 rounded;
}
.select2-results__group {
@apply text-lg font-bold text-gray-900;
}
```

你也可用单独用 @apply 写入一个 css 文件里

程序员也追星，就跟出来个新电视剧一样，大家都去追。

我觉得最重要的一个特点就是可以直接写伪类伪元素，这样的话应该只有很少的情况下需要单独写个 css/less/scss 文件了，配合一些 IDE 插件，体验很好啊，就在 JS 代码里搞定一切它不香吗。最后，我主要用的 windicss [doge]

我觉得可以借鉴它的核心思路，有的时候写起来还是挺香的。
自己日常不会直接引用它的库，但会写很多通用的基础样式就是参考着 tailwind 来的。

@HackerJax 虽然我还没用这个，但你说的 Button 问题，现在用的前端框架如 React 本身就可以抽象出组件，一组 class 在 Button 组件里写一次就行了不用到处写，都不用折腾什么 css in js 之类的了。

要不直接看官方的说明吧，https://tailwindcss.com/docs/utility-first ，刚开始看着是不容易接受，但是用起来真香。
>>> This approach allows us to implement a completely custom component design without writing a single line of custom CSS.

Now I know what you’re thinking, “this is an atrocity, what a horrible mess!” and you’re right, it’s kind of ugly. In fact it’s just about impossible to think this is a good idea the first time you see it **you have to actually try it**.

But once you’ve actually built something this way, you’ll quickly notice some really important benefits:

- You aren’t wasting energy inventing class names. No more adding silly class names like sidebar-inner-wrapper just to be able to style something, and no more agonizing over the perfect abstract name for something that’s really just a flex container.
- Your CSS stops growing. Using a traditional approach, your CSS files get bigger every time you add a new feature. With utilities, everything is reusable so you rarely need to write new CSS.
- Making changes feels safer. CSS is global and you never know what you’re breaking when you make a change. Classes in your HTML are local, so you can change them without worrying about something else breaking.

当然是为了解决问题，不要评价你不熟悉的事情

你以为传统的 class 把结构和样式分离了吗？
以 BEM 为例，你没发现它把 html 结构在类名里又维护了一份吗？
结构和样式从来就没有真正解耦过，不管是 2012 还是 2022 。
转变只在于传统写法样式依附于结构，改样式容易改结构麻烦，原子类写法结构依附于样式，改结构容易改样式麻烦。

首先明确一点，class 和 style 是补充关系，不是替代关系。class 是全局控制样式，style 是局部控制样式。

既然无法相互替代，那么把 style 完善一下，弄个预编译，就是 tailwind css 干的事了。

tailwindcss 用的都是缩写，而原生 style 都是又丑又长的关键词。把代码变少，就意味着能变相提升代码的可维护性。

直接用更粗暴的 CSS in JS 吧

const styleTitle: React.CSSProperties = {
...templateTitle,
marginTop: 20,
marginBottom: 12,
textAlign: 'center',
};

const styleDesc: React.CSSProperties = {
...templateDesc,
paddingLeft: 5,
paddingRight: 5,
};

<>
<div style={styleTitle}>{title}</div>
<div style={styleDesc}>{desc}</div>
</>

tailwindcss 我一开始用的时候也有点反感
后来用着用着越用越香 简直就是香饽饽

没法忍受把 class 写的老长一串，太丑了我拒绝，遇到 UI 复杂一点的需求直接寄了

和 JSX 是一个道理，有些人喜欢、有些人讨厌。
根据应用场景和自己的喜好，选择适合的方案就好，没必要争论，都有各自的道理。

借楼问下大佬们，tailwindcss 的优先级太低，怎么优雅地去覆盖其他 ui 库的样式

github 虽然不是用的 tailwindcss 但也是种风格的

@yl20181003 有个选项，可以给所有的都加上 !important

tailwindcss 正确打开方式----》加一层 component
比如官方的 tailwindui ，以及第三方的 daisyUI
这样实现了设计系统，到组件的高速开发。

tailwindcss 是基于熟练上的。

tailwindcss 现阶段我觉得更舒服的点是，在需要写内联样式的地方，可以用 className 来写，而且还不用单独命名，总觉得前端应该是尽量避免写内联样式的。

要说组件化和做原型，bootstrap 不香吗？设计工具也有，bootstrap studio ，所见即所得，我就不信还有比这个做原型更快的，做原型就不应该太在意样式。

以前选框架的时候看了下不懂这些样式怎么复用，而且相较于要我写这么多样式感觉还是 bootstrap 之类的拿来就用，所以 pass

1. 类名即样式，使用者无需定义类名，大大降低了编程复杂度。
2. 内置了系统值，减少了 Magic number ，有利于设计的统一性。
3. 系统值、样式可以非常简单的实现扩展。

tailwindcss 忠实粉丝在此，帮程序员解决了著名的世界级起名难问题，生产力提升是指数级的

后端就别来瞎搅和了，纯浪费时间

引用一下 material ui 的文档说明 tailwindcss 解决的问题
https://mui.com/system/basics/#problem-solved

1. Switching context wastes time.

There's no need to constantly jump between the usage of the styled components and where they are defined. With the system, those descriptions are right where you need them.

2. Naming things is hard.

Have you ever found yourself struggling to find a good name for a styled component? The system maps the styles directly to the element. All you have to do is worry about actual style properties.

3. Enforcing consistency in UIs is hard.

This is especially true when more than one person is building the application, as there has to be some coordination amongst members of the team regarding the choice of design tokens and how they are used, what parts of the theme structure should be used with what CSS properties, and so on.

不要把社区 /其他开发当傻子。tailwindcss 可以流行肯定是有原因的。

@snoopyhai 说的很对
> op 这么说, 一定是没有维护过老项目. 特别是别人写的老项目.

我在生产环境用了 2 年了, 没有人盯着 css 代码看,要看界面

@HackerJax 没太懂 button 这个是什么场景？我 button 内部使用 tailwind 封装好，不是一样可以方便维护吗？

用过之后就会觉得好用了，这跟写 style 完全不是一个概念

有没有体验过为了改一个 TAG 在一堆 CSS 文件中找样式的感觉?
有没有体验过用 BEM 取名又臭又长，划分层级取名时把头抠秃的感觉?
tailwind 就是 class 多点，完美规避了上述问题，吹爆

难以置信，前端逆淘汰竟达到如此地步，简直大逆不道，

何不切除睾丸体外培养以提升工作效率

用过都说好

https://windicss.org/posts/v30.html#attributify-mode

用 Attributify Mode 很清晰啊

初期难以接受，习惯以后越来越香

越讨厌越好，这说明门槛高了，你们进不来了，你们哪凉快哪呆着去

已经用在生产环境了，确实好用，就像榴莲，有的人喜欢有的人不喜欢。没必要吐槽

tailwind 和传统的 css 又不是非此即彼的关系，在项目里共同使用才是常见情况，如果是项目里的通用样式就用 css 。如果是某个只会用到一两次的样式那用 tailwind 不管是开发还是维护都更方便。

我觉得 tailwind 就应该是主流，用习惯后真的香。

讲真 tailwindcss 和 vite 是明确可以大幅提升 react 开发体验的东西
其意义远大于那一万个状态管理库

哈哈哈哈，历史螺旋上升，我刚接触 WEB 开发觉得 semantic ui 这东西真好。后来就被教育内联样式是邪教，应该分离。
现在这种东西又回来了

总的来说：性能、bundle 、跨平台、一致性 都是我目前感觉到的优势。

我能说我一个后端在几年前就自己设计了这种模式么..只不过只用了一些我常用的 css

虽然我不写 Tailwind ，我发现它有一种 bundle 的模式，可以用一个名字包一群名字，这样就看起来简洁，但是同时也失去了语义...好吧，不想用

@DrakeXiang #23 多谢分享，话说第一次看到 google 设计这样的页面，还以为进了山寨网站~

我到是觉得写着还挺爽...

@dicc atomic css 很早大家都在使用，定义一些通用样式之类的，Tailwind 是 atomic css 集大成者，把这个模式规范统一化了

你知道吗 这是臭豆腐，闻着臭，吃着香

想当初我也是疯狂吐槽这玩意儿，但是后来尝试了一下，没两天就变的真香，我现在是 less 和 sass 都不想用了，新项目都是 少量 css in js 搭配 tailwindcss

@zthxxx 真就啥图都有 2333

@zthxxx 尝试把 button 封成一个 Component ？

过两天 LZ 发另外一个帖子
“这个世界上为什么会有 Tailwind Css 这么香的东西？”

在使用 UI 框架的时候，预先定义好统一风格后，对于页面样式控制很多时候本来就不需要太多的 css ，但是直接用 style 属性写 css 很麻烦，创建 css 文件又感觉没必要，所以如果使用 tailwindcss 就不用考虑这些，并且还不用想类名，并且还能配置自己的 tailwindcss 样式。而且没有说用了 tailwindcss 就不能用 css 文件了，如果样式很多，很复杂还是可以用 css 文件来写。并且你看到的这个是从原始样式写出来的，除非练习 tailwindcss ，不然生产上没人这么做吧。嫌多了可以用在 css 文件中用 @apply

第一次看到我是拒绝的，各种开嘲讽，用了一阵子后啪啪打脸，tailwind 是真的香，尤其有了 JIT 后那更是香疯了，喷 tailwind 的人大部分都没有实际用过一段时间吧

1. 我推荐用 tailwindcss 配合其它框架来用。比如我厂用了 element ui ，这时候我需要一个横向布局，间隔约 1 个汉字，那么直接 `flex ml-4` 就很方便，不需要跑到样式里定义一个样式，然后在模板里引用
2. 一些出场频率不高的样式，比如 gri ，用 tailwindcss 会容易很多
3. 分享 HTML 的时候，简单很多

建议面对任何流行技术，都抱着取其精华、弃其糟粕的心态，看看怎么能改进自己的工作。吐槽和挑战其实不难。

其实这东西七八年前就有类似的了，比如网易的 NEC ，写起来真的觉得很痛苦
但是现在好像和 TypeScript 一样很政治正确

比起手写 style ，tailwindcss 少写了很多字，要达到无障碍使用的程度只需要付出十分钟的学习成本以及在 vscode 装一个插件

赞同 @snoopyhai 说的，我自己写烦了 flex 的那些了，直接定义了一个自用的，然后必须说：特别香，无敌香。

萝卜青菜，各有所爱；

如果业务内有可以复用的 css ，说明可以归纳出自己的原子化 css ，没必要非得用框架定义的

写起来是很长，看着满屏幕的样式 code ， 但是写多了就体会到好处了，样式原子性（好像是这么介绍的），不存在父级影响子级的污染问题，很顺溜

顺便多一嘴，不喜欢这样可以用 apply 代替

这跟 bootstrap 的写法有啥区别

@anguiao 非常感谢 我又去看了下文档 貌似前面加个!就可以

刚学 WindCSS 写个项目，刚开始还要翻文档看 Api 。找到一点规律就直接写了（配合 VSCode 插件），用来写组件还是很适合的。

对我来说，不想起类名，xxx-wrap 、xxx-content 、xxx ，烦死了，而且 tailwindcss 这样复用性也强啊

体会就是最开始撸的时候只需要想 dom 结构后然后直接撸样式，而不用撸完 dom 先一个个想 class 名，对于前后端没分离或长期维护来说，还是可以逐步把 class 补上去然后 @apply 去重构。

刚接触 Tailwind, 发现他的好处是很容易从别人那里偷师... 做法都直观写在 class 里，而不是一会在 style="..." 一会分散在不同 css 文件,一会在<style>... 基本上直接复制粘贴过来效果也是保持一致的

@DrakeXiang 就每年简单用一下，静态展示一些内容，不怎么需要维护的页面，就随便吧

@lqs

> 2012：页面结构与样式要分离，会更容易维护
> 2022：页面结构和样式本来就是耦合的，写在一起才更容易维护

中间少了许多:

1. 页面结构与样式要分离.
2. 页面结构 -> 组件, 分离的样式.
3. 页面结构 -> 业务组件 -> 通用组件, 分离的样式.
4. 页面结构 -> 业务组件(自带样式) -> 通用组件(自带样式).

样式和页面结构还是分离的, 不过和组件耦合了.

前端都被人耍，其实就左右两个基本点，记住左右两个手要张开握住。1 个是拿来一套 UI 库，1 个是拿来一套前端框架/库 jquery/vue/react 。其他都是假的，服务端又不干客户端事。

前端被人耍也是好的呀，要不然前端为什么工资比后端高呢。

前端普遍走广度路线，用了发现了一个库，就碾压其他自己创库的同学。

后端普遍 CRUD ，比前端广度不足，深度差不多，能工资不少吗