最近Tailwindcss频繁出现在我的视野里，从单词拼写中看，多多少少与css有点关系。近几年是JS框架大行其道，CSS方面少有新的框架出现。
昨天突然看到尤大神在Github上的动态，fork了该项目，看来马上要火的节奏啊！
我们来看下这个tailwindcss究竟是个什么东西，有什么独特的功能和优势，最重要的是能否给我们开发者带来显而易见的效率的提升。
首先看官网对它的定义
Rapidly build modern websites without ever leaving your HTML.
tailwindcss 基于比组件更小、更灵活的工具类思想的 CSS 框架。这个思想简单来说就是用 class 保证灵活、便于自定义组件，而不是在组件基础上实现个性化。
可以看到代码的特点是一个Html标签伴随着一堆的CSS类，这种写法好像也不陌生。就是将样式封装的粒度更细。所以很多人看到就说“这不就是原子类吗？”。
我们先来看看Tailwindcss作者所谈到的开发初衷，将CSS开发经历分为几个不同的阶段来讲：
第一阶段：语义化CSS
以 CSS 在 HTML 中的语义来命名 CSS 类名
缺点：HTML 达到了「分离关注」的目的，无需关心 CSS 了，但是 CSS 的结构与 HTML 的结构强耦合，几乎就是 HTML 结构的复刻。
第二阶段：将「样式（CSS）」与「结构（HTML）」解耦
典型代表：BEM 方法论
实际工作中，面临的两难境地：语义化 CSS，
在内容中立（content-agnostic）组件中，HTML 是独立的，CSS 依赖 HTML，导致的结果：HTML 可以方便地调整样式，CSS 不能方便地重用。
每个项目负责人都要意识到，「分离关注」并非是一个非黑即白的选择，而是一个权衡（tradeoff），一边是方便地调整样式，一边是方便地复用样式。
考虑到：
HTML 是结构化的信息，具有明显的约束（如：标签种类等）
CSS 是创造性灵感类信息，有极大的发散空间，达成相同效果有多种方式，无约束且易被滥用，被滥用后容易导致 UI 的不一致性
作者坚定的选择
「方便地复用 CSS」，为 CSS 增加约束，提升 UI 一致性。
第三阶段：内容中立组件
一个组件做得越多，或者一个组件越具体，越难以复用
第四阶段：内容中立组件 + 功能类（utility classes）
通过细粒度的功能类的组合，可以有效去除 CSS 中的重复
第五阶段：功能类优先（Utility-first）CSS
将所有的 CSS 均由功能类组合而成，这样做的好处是：对 CSS 的使用施加约束，有利于产生更一致的 UI，但是如果一个组件被多次使用，却每次都要用功能类组合而成么？
原则是：
以功能类组合成组件
避免过早抽象
注：这里有个很好用的规则：直到一个模式出现 3 次的时候，再考虑抽象成组件，而非像 BEM 等方法论所做的那样，一开始就提供组件。
其实从我自己的开发经历来讲，主要分为两个时代，在这之前，编写 CSS 被认为是在为 HTML 文档进行排版。因此，“内容（HTML）、样式（CSS）、行为（JS）需要分离”这句话，连同着“CSS 代码应当体现 HTML 文档结构/语义”的观念深入人心。因此大家一直习惯于：
为 HTML 文档里的一些元素起一些所谓“能反映它在文档里的角色/语义”的类名 / ID（例如 header、sidebar、menu、navbar 等等，甚至发明出 BEM 之类的“命名规范”），然后用类选择器或 ID 选择器来选中它们
偶尔搭配使用那些依赖于文档结构的 CSS 选择器（后代选择器、子选择器、兄弟选择器等等）
但是，在 近几 年，没有人还会认为自己在编写 HTML 文档，或者说，认为自己的 HTML 是所谓的“内容”。HTML 实际上是类似于 GUI 像素 / 控件一类的东西，是组件的渲染产物。对于这种“渲染产物”，大家需要的是能够方便地指定其外观的方案，而不愿意再走“ 纵览文档结构 -> 为元素起名字 -> 用选择器选中 -> 写 CSS 语句”这套传统流程：
由于组件化开发模式的推行，已经不存在一个所谓的“文档结构”了（现在只有组件树结构，而且你通常不会在乎它），也就是传统流程的第一步早已不复存在
为了消灭第二、三步， CSS-in-JS 开始流行起来
而 tailwind 这种原子类方案就更激进了，它不但跳过了传统流程的前三步，连第四步都帮你简化了（用一个简短的单词，也就是一个原子类，来代替一个 CSS 语句）
看了网上的开发者的评论，有人唱衰有人叫好，本人看来，一个东西的流行短时间可能是玄学，但是长时间流行的东西肯定是真的具有不可替代的优势。Tailwindcss也是如此，不要过早的判定一个东西的好坏吧，要结合时代趋势来看。既然大神都fork了，还是先用用看吧。
