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

• 主 資深大佬 : 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 反复交流搞出来一套规则, 不能想哪出是哪出.