大佬们，你们前端 css 这个东西效率问题怎么说

[WishMeLz]

我个人平时的命名规范是学习 elementui 的命名规范，可能学的不完善，尽量在学习 打个比方： .main .main-info .main-info_mini ...

像 scss lass 这种 效率问题可以提高多少

[WishMeLz]

是 less，说错了，不好意思

[Pastsong]

要学规范的话就学 BEM

[Sapp]

用 css in js
放弃 class 命名，彻底就没这个问题了
还可以用原子化的 css 组件（ tailwind ）和 css in js 结合，大方向用写好的 class，小的和复杂的自定义用 css in js，我觉得当前真的没必要再去纠结个 class 了

[bigggge]

我们现在要不 styled-component，要不就 atomic css

[erwin985211]

我是原子化信徒呀，效率提高不止一点

[namelosw]

以下是用了各种都用了很多年的主观感受:

用 Tailwind 效率提升 500%. 因为写代码的最高境界就是几乎不写代码.
如果倾向 CSS in JS 还有个 Twin, 跟 Tailwind 一样的.

这个东西看起来有点 low, 感觉十年前就很多类似的做法, 但大多都不好用. 但 Tailwind 实际上很好用, 和其他类似的方案都很微妙的, 魔鬼都在细节里.

---

用 Styled 类似的方式或者其他 CSS-in-JS 效率提升 50%.

因为写 CSS class 再在 HTML 用 class 本质上是一个 correlation 的过程, 但是现在都已经组件化了, 等于这种 correlation 的工作翻倍了, 在组件原地定义就消灭了这种工作. 而还比较鼓励你设计好组件.

缺点是和已有大量用选择器的项目放在一起的时候会互相打架, 用起来比较尴尬.

---

此外 BEM 还行, 效率不会提升因为比较繁琐, 但是正确应用可以避免很多坑.

类似 SASS 的预处理器的问题就是很多项目用了 SASS 嵌套会特别爽, 然后人们就会无脑嵌套. 最后发现不仅优先级很乱且没法覆盖, 而且你在嵌套的过程中其实已经重复了一遍 HTML 的嵌套逻辑, 那么当你移动 HTML 的结构的时候所有的样式都会失效.

相比之下 BEM 刻意总维持 2 层结构, 既解决了命名空间的问题, 又解决

感觉 SASS 之类唯一比较有价值的是类似 mixin 的功能, 这样可以把样式拆小复用. 纯 CSS 没有 @apply 的情况拆小就要在 HTML 上无限重复, 改动的时候很容易漏.

[darknoll]

css 才是前端的精华，没有 css 后端都能转前端

[rodrick]

用 react 的各位是用那种方式多？ css in js 还是都 import 或者其他的方式

[yaphets666]

@darknoll 前端还有 canvas 和 webGL 炫酷的都是这个做的 css 一般只处理小问题 布局问题 超级简单的动画 复杂的不用 css. 网上那些 什么 codepen 啊啥的 纯粹是大伙娱乐和炫技的

[Ixizi]

css module

[binaryify]

我用 less 和 scss 最大的目的就是解决嵌套,其次是变量

[GzhiYi]

tailwindcss 香炸

[zzzzzzggggggg]

@GzhiYi 最近看到很多人在讨论 tailwindcss，得去看看了

[a62527776a]

感觉花太多时间性价比太低啊

[codingguy]

感觉几个技术解决的痛点是这些：
scss，less => 让 css 有逻辑（变量、嵌套、循环、函数）
css in js => 不用纠结 id，class 命名
tailwindcss => 不需要写样式

[sjhhjx0122]

直接 tailwindcss 是最方便的了，搭配 vscode 的插件，可以直接不用去翻文档了

[dartabe]

sass + css module 有啥不好的

tailwind 到底是比上面这个优势在哪

[GzhiYi]

@dartabe 说一点是不需要翻到 css 的代码位置就可以将大部分的布局写完，用 tailwinds 和 sass + css module 不冲突，可以一起使用。

[dartabe]

@GzhiYi 感觉自己也可以定义原子类啊 不冲突

[GzhiYi]

@dartabe 如果自己开发当然可以定义原子类（我自己也会写一些），但我认为像 tailwind 这样是设立一个命名基准，不必需要在多人协作的时候考究个人所写的原子类命名。

[murmur]

@dartabe 标准化，可读性，但是这个标准化也是半标准，比如 tailwindcss 只能告诉你能用多大、多大、多大的组件，却没告诉你什么时候用多大的组件，写起来还是一人一个样

最多是比如规定我一个网站只能用 12 、14 、16 号字体，能拦住别人用 13 、15 、17 的，但是你拦不住别人在 btn-sm 里用 16 号字的

[dartabe]

@GzhiYi 好像有什么 BEM 命名法？ 所以到头来 tailwind 就是命了名。。。。。。

反正我是看不懂 我觉得确实可能都用最好

[dartabe]

而且很多框架都自带 帮助类 感觉基本就是一回事儿 不知道这 tailwind 是咋火的

[yaphets666]

@dartabe 正经写前端 以前端为职业的 用这种 tailwind 的极少 用这些东西的都是 其他方向 转前端 或者 不是以前端为职业的

[WishMeLz]

@yaphets666 我就是正经写前端的。我一直都用 bem 命名法写的。可以说一直都是 style 标签里面直接写

[yaphets666]

@WishMeLz tailwind 是在 class 里写类名 不是手写 css

[KuroNekoFan]

bem 应该不潮了，从 react 阵营来说，css-in-js 为代表的原子 css 在最近一年更火热

[JoStar]

BEM 对团队要求蛮高的，因为要命名足够规范而且不重复。

tailwind 颗粒度非常细，初次学习成本很大，过了这个阶段还是很不错的。

我自己选择的是沿用 tailwind 的思路，以 oocss 的方式去写，颗粒度会大一些，但是学习成本低一些。

less sass 最早是解决 css 无法设定变量、函数的问题，新的 css3 已经原生实现不少功能了，但我还是习惯 sass，毕竟组里的人都习惯它了，也没什么坏处。

总的来说，方案很多，要根据自身团队的情况选择一个平衡的方案。

[abelmakihara]

@dartabe 感觉和他们不是一个世界的..
看了下官网的例子又冗长又不优雅 这是怎么火起来的？
常用的字体大小什么原子类就得了 这不是走火入魔本末倒置了吗
复杂点的写那么多好用在哪了 有那么多冲突的机会吗？
我个人感觉 css module 还算是比较中庸好用的一个选择了

[mara1]

@namelosw tailwind 这么多类名看得头都大了， 怎么记啊
我从官网 copy 过来一段：

<div class="flex flex-col">
<div class="-my-2 overflow-x-auto sm:-mx-6 lg:-mx-8">
<div class="py-2 align-middle inline-block min-w-full sm:px-6 lg:px-8">
<div class="shadow overflow-hidden border-b border-gray-200 sm:rounded-lg">
<table class="min-w-full divide-y divide-gray-200">
<thead class="bg-gray-50">
<tr>
<th scope="col" class="px-6 py-3 text-left text-xs font-medium text-gray-500 uppercase tracking-wider">
Name
</th>

[codingguy]

@yaphets666 #24
用 tailwind 的专职前端确实很多，并不是极少，有相关的统计数据 https://2020.stateofcss.com/

[maomaomao001]

@namelosw
tailwindcss 有没有办法做到 从外面覆盖(修改一些样式),
举个例子 ,
A 页面 , 有两个组件 C1
C1 里面有个按钮 红色背景的 ,

然后现在来了个新需求, 需要 把组件 C1 放在 父组件 C2 , 需求是在 C2 里面的 C1 里的按钮需要表现出 蓝色背景 + 红色边框 ,
那么问题来了, 如何在不动 C1 和 按钮的源代码的情况下, 实现这个需求 ?

大概就是 开发者 d1 在第一天开发好了 C1 和 按钮

那么第二天 开发者 d2 在复用 C1 的同时 (而且也不修改 C1 的情况下), 让里面的按钮显示出不同的样式 ?

[Jirajine]

@mara1 不需要你记，这些类名都是缩写，并且描述了它的作用。你需要啥效果就敲啥，再配合补全和预览，写起来很快。
当然 tailwind 用的爽的前提是本身对 css 非常熟练，门槛比较高。业余前端项目弄个组件库或者 bootstrap 这样的一把梭就是了。

[maomaomao001]

@maomaomao001 一个组件 C1

[wlchn]

CSS Modules，用过 SCSS, CSS in JS，最终更喜欢 CSS Modules 的方式，大概有以下一些优点:
1.避免了复杂项目 css class 重名问题。
2.避免了只用 scss 可能会嵌套很多层的问题。
3.可以根据 dev，prod 不同环境编译成不同形式，比如 .main 在 dev 编译成.main-xxxx,在 prod 编译成 .xxxx 兼顾可调试性与体积。
4.与 css in js 相比，保持了 css 单独文件的写法，与写 css 方式差别不大，更顺手，这个看人喜好。

[codingguy]

@mara1 #30
效果是啥，类名就是啥。
比如横向滚动，对应的 css 就是 overflow-x: auto，类名就是 overflow-x-auto，不是见名知意吗。

[namelosw]

@mara1 https://tailwindcomponents.com/cheatsheet/

[charlie21]

如果把 CSS 当作一个 SDK，把 tailwind 当作一个 wrapper，那么它的问题在于：
1 它是一个 css 的 wrapper，但 css 这种技术根本不需要 wrapper
2 它作为一个 wrapper，学习成本已经超过了 原始 SDK 的成本

tailwind 之于 CSS，等于 GTK# 之于 GTK，完全是 porting 过去的。是激进做法。激进的意思就是时刻处于被淘汰边缘，而且一旦维护团队放弃维护它，它会是无人接手的那种

github.com/troxler/awesome-css-frameworks 这里把 Tailwind 放在 Specialized 就是这个意思

[charlie21]

要用就用 General Purpose 的东西

[namelosw]

@maomaomao001
一个办法是写 CSS, 然后用 selector + @apply. Tailwind 并不会阻止你一行 CSS 不写.

另外一个办法是不改源码只能组件靠 JS 搞一个 Lambda 进去当 prop 拼类名. 但是这样做并不好. 你也可以试想把问题从 CSS 换成 JS, 不修改源码, 怎么让组件支持新功能? 你还是可以传 Lambda 进去, 但是绝大部分时候你不用每个组件都写得这么灵活, 不然代码就没法读了.

--

如果你横向看一下这些解决方案, 就会发现越现代的 CSS 方案越不好实现你说的这种需求. 比如 Styled 是基于组件的, 虽然也不能覆盖但是至少还能用选择器. 到了 Tailwind 就更不好覆盖了. 这是因为开发和设计都在逐渐推行组件化和 atomic 设计. 有了这些基础才能真正高效的开发.

回到说的问题, 如果你想有不同的行为和样式, 应该重新思考组件怎么设计和组合.

[namelosw]

@charlie21 我理解你说的意思, 但是在这个具体 case 上不太赞同

> 但 css 这种技术根本不需要 wrapper
CSS 很多东西是比较底层的, 有没有 wrapper 效率会差 N 倍, 我 Tailwind 写一会够别人吭哧一上午的.

> 要用就用 General Purpose 的东西
CSS 也不是 General purpose 的, 很多东西 CSS 根本写不出来, 还得 JS 实现. 因为这个就不用 CSS 就很怪了.

[yazoox]

@Sapp 兄弟，你这里说的 css in js 是什么意思？类似于用 styled module 在 reactjs 里面？

[JerryCha]

.have-no-idea-name

[jin5354]

大厂里写原子类信不信会挨打

[Shook]

我用 tailwind，然后搭配组件内的 scoped 以保持样式的独立。
在每个组件内想怎么命名都可以，用 tailwind 规范 spacing 、colors，写样式就会很快很方便。
当然，一些比较通用的样式，还是需要用 @layer 来写的。

[PainAndLove]

可以看看 tailwindcss

[Lemeng]

跟着大佬们一起进步

[yaphets666]

@codingguy 不是极少也是少数 统计数据还是 less sass 大幅度领先

[ccraohng]

非组件库用 css module .
要写 css 的时候，
要么就是后台魔改一些布局功能，
要么就是 ui 出了设计稿，我本来就会 css，还去记些？用了我还要去找差哪些样式。
可以翻翻上面某些人的记录。。。

[godgc]

tailwindcss 可以的 推荐

[maomaomao001]

@namelosw 关键就在于 , 写 C1 组件 和 按钮组件的开发人员 d1 并不可能会写上一个 selector (比如给他写好一个 class 叫 btn-common 之类的), 而是 d2 开发的时候,已经完全是只包含 bg-red 等之类的原子类型了 , 也就是 别人使用这个组件的时候,根本不可能(也没有办法用正确的选择器选到这个组件(如果真的只有一个按钮,也许可以用 button 这样的 tag 选择器来选择,然后附加上 d2 想要的样式)

至于你说的第二个方案, 通过 prop 拼类名 (那么就得修改 按钮组件,让它支持通过 props 传入 class), 这个还是违反了我想说的完全不去修改任何已有的代码的情况了 ...

大概就是,总的来说,有个组件开发好了 (这个时候并不知道 会被用到其他 20 个场景下, 样式完全不一样 , 有的甚至布局都变了) , 那么开发这 20 场景下的开发人员,不修改 这个组件,通过外部修改样式的唯一方案,我实践过的就只有类似 BEM 的 方案了 , Tailwind 看了几次, 还是感觉没法复用 (不是 css 没法复用, 是用 Tailwind css 写的组件没法复用 , 要不就要到处通过 props 传 class) ,做一些特定修改 .
如果有 Tailwind 这个方面的实践相关的, 可以推荐一下

[youla]

CSS 需要一个超级英雄来拯救 https://stylus.bootcss.com/

[karnaugh]

个人理解
[BEM]
命名规范，是为了解决很多 class 在同一层时互相起名困难，是名字语义化，但是写起来类名实在太长了。。。

[scss,less,postcss]
进化版 css，可以搞变量、加函数，最主要的是写 css 时可以嵌套了，直接就降维解决了 BEM 要解决的问题。
但是注意千万不要用 css 嵌套写法拼接 class 去写 BEM，别人接手代码去修改时简直就是灾难！

[tailwindcss 及其他原子类]
这东西应该是混合上述两个使用的，不应该单独拿出来用，而且十分不建议用原子类写具体样式

个人倾向于跟布局大方向有关的使用原子类，比如常见的左右浮动和清除浮动「 fl,fr,clearfix 」，比如 flex 布局，我将 flex 布局整个抽成原子类在使用「 https://github.com/KarnaughK/FastFlex 」

其他类似于长宽、padding/margin 、文字样式、以及绝对布局相关等、颜色阴影边框等等，都是写在 css 里，这样的好处是 html 具有一定的可读性，单看 class 就能知道这个布局是横着还是竖着，是居中还是靠左，css 里只需要关注具体的样式，每一个 class 只对应精确的元素的样式，减少与其他元素的样式关联

[namelosw]

@maomaomao001 感觉你这个方向就不太好... 组件就是组件, 要是什么都能任意改就不是组件了, 像 ng1 继承 scope 的 controller 一样到处侧漏……

外部能修改, 其实就跟动态作用域一样, 像 JS 的 this 和 shell 的变量都是那种动态作用域. 但是一个正规的语言都是文法作用域, 定义的时候定死而不是动态靠外部覆盖, 不然软件的行为没法预测, 很难维护.

[namelosw]

@karnaugh 我就是能用 Tailwind 原子类就只用它, Tailwind 的官网上明确写了你应该靠组件抽象而不是 CSS 类.

仅当写比较诡异项目需要改来改去的才会 selector. 这样其实挺好的, 关键是主动出击, 和 designer 反复交流搞出来一套规则, 不能想哪出是哪出.