运行像 CSS 状态 这样的开发者调查是一个多阶段的过程。首先，您需要收集数据。然后，您将其处理成可用的形状。最后，您想出一些巧妙的方法来可视化它并将其发布到世界。
但是，一旦尘埃落定，流量下降，我就会进入我最喜欢的部分：真正地思考这些数据。通过更深入地研究我们的数据，以及观察社区如何讨论我们的发现，三个意想不到的趋势最终浮出水面。
但首先，对于那些不熟悉该项目的人来说，这里有一些背景信息。
我于 2016 年开始首次进行 JavaScript 状态调查，旨在解答我对 Web 开发未来的一些不确定性。当时，JavaScript 疲劳泛滥，我认为一个全面的开发者调查可以成为其解药。
事实证明，我触及到了神经：第一次调查非常受欢迎，我们的受众自此每年都在增长，调查范围也在扩大。（我还与 Nivo.js 数据可视化库 的创建者 Raphael Benitte 合作，帮助我处理和可视化数据。）今年是我们首次进入一个新的维度，即并非那么简单的 CSS 世界。
预测 1：CSS 仍然有很多未开发的领域
我们希望通过调查量化的一件事是，CSS 还剩下多少“未开发”的领域。换句话说，开发者要么不熟悉，要么尚未使用的 CSS 功能是什么。为此，我们早早就决定将“功能”部分重点放在新的 CSS 属性上，例如形状、遮罩或 scroll-snap，而不是“无聊”的浮动或表格。
得到的结果数据描绘了一幅有趣的图景：事实证明，当你从这个角度来看，CSS 会从熟悉的景观转变为一片狂野、未开发的丛林。
比较 Flexbox 与 CSS Grid 可以很好地说明这种趋势。虽然几乎所有听说过 Flexbox 的人都使用过它，但只有 55% 了解 CSS Grid 的开发者实际尝试过它。这是一个巨大的差距，尤其是对于像 CSS Grid 这样重要的技术而言！
或者以 CSS 形状 为例：68% 的开发者知道它们，但只有 31% 的开发者实际使用过该功能。
所有这些都表明，我们集体想要学习的东西与我们实际知道的之间存在很大差距。正是这种成长的潜力使 CSS 在 2019 年如此令人兴奋。
预测 2：函数式 CSS 将持续崛起
如果你足够大，还记得 CSS Zen Garden（或者通过它学习 CSS，在这种情况下我知道你的感受，我早上起床时也会背痛）——那么下一个趋势可能看起来很奇怪，甚至完全错误。
函数式 CSS 拒绝了纯净、未污染的标记的柏拉图式理想，这种标记不受任何样式问题的困扰，并拥抱“函数式”（又称“原子”或“实用”）类。想想 <div class="text-red text-medium border-1">...</div>。
采用这种方法意味着您无法神奇地更新您的样式表，并在不修改任何标记的情况下更改整个设计。但老实说，这种情况发生的频率有多高？与 Zen Garden 哲学经常提到的理论优雅相比，像 Tailwind 和 Tachyons 这样的库提供了切实的、现实世界的好处，这解释了为什么它们受到如此高度评价。事实上，在 CSS 框架类别 中，它们分别占据了满意度排名中的第一位和第四位。
至少从 Twitter 上其社区对调查结果的互动来看，Tailwind 的发展似乎正在加速。它刚刚发布了 1.0 版本，绝对是一个值得关注的项目！
预测 3：CSS 之争才刚刚开始
查看我们的数据，我忍不住想知道“JavaScript 疲劳”是否很快会被“CSS 疲劳”取代。
在评估技术时，不仅要查看原始使用量，还要查看用户满意度。毕竟，你不想只是为了发现当前的使用者都迫不及待地想要跳出来而加入最新的潮流。
这个 散点图 被分成四个象限，非常适合这种分析。它将使用量与满意度绘制在一起，使您能够轻松地将流行的高满意度工具隔离到它们自己的象限中。
从这张图表中可以明显看出，人口最稠密的区域是“评估”象限。换句话说，使用量低、满意度高的技术仍在争夺主导地位。这正是 JavaScript 生态系统所处的状态。许多竞争者，但截至目前，还没有决定性的赢家。
这不是一件坏事：是的，在选择合适的工具时，它确实会让普通开发者的生活变得更加困难，但嘿，这就是我们做这些事情的原因！此外，竞争只会对整个生态系统有利。一旦尘埃落定，我们有望最终获得最好的选择！
2019 年的 CSS
总的来说，CSS 状态调查表明，这不再是您爷爷的 CSS。多年来，我们开发者一直喜欢抱怨 CSS 的不足和缺乏强大的功能。但在 2019 年，CSS 正在挑战我们，让我们说到做到：这就是你一直想要的所有功能。现在你打算怎么办？
我个人非常兴奋地深入研究这个新的样式世界。当然，我也会在 2020 年回来，看看我们那时候会发现什么新的趋势！
我个人不明白为什么“预测 2：函数式 CSS 将持续崛起”越来越受欢迎。
谁能解释一下，在每个 HTML 元素中编写一百万个不同的类名来表示每个可能的 CSS 属性/值对，比在网站上仅使用适当的元素选择器结合命名的类更有效？
如果以后我想让网站上的所有“h1”标签都有更大的顶部边距。这意味着我必须搜索和替换网站上的所有“h1”标签，并将“m-top-20”或任何其他类替换为“m-top-10”类或其他什么。我只是不明白...
我同意你的看法。我的一个同事一直试图说服我 Tailwind 到底有多棒。他最好的理由是，他团队中有些人不是真正的 Web 人员，这可以防止他们搞砸——对我来说，这并不是一个足够好的理由。函数式 CSS 让我想起了字体标签和 FrontPage 的糟糕时代。而且，在不得不修改网站并逐个删除所有字体标签和内联样式之后，我再也不想回到过去。
它可能唯一有效的场景是，如果一个网站是模板驱动的，并且你只需要修改几个模板。但这对我来说仍然不够充分的理由让我想要使用它。
在基于组件的网站上，它就像一个梦想，比如现代的 Javascript 项目或任何使用 Twig/Handlebars/Blade 等的项目。如果我想改变我的 H1，我编辑我的标题组件，它会改变网站上的每个标题，因为它们都引用了那个标题部分。如果你的网站不是这样构建的，那么它对你根本没有用，我理解你的怀疑。
https://frontstuff.io/in-defense-of-utility-first-css 是一篇关于这个主题的非常好的文章。
一旦你需要一个组件（这样你就可以改变它需要的无数个类）来输出标题，我认为你已经回到了原点。我预测表格和内联样式将回归。
这是基于组件的 UI 与现实世界场景相结合的结果。
在实践中，CSS 完全依赖于 DOM 结构。即使在使用内容管理系统时，你无法预测确切的标记，你也应该知道何时放置段落标签与表格标签等等。CSS Zen Garden 奏效是因为标记从未改变，这就是为什么它是一个展示 CSS 灵活性如此之好的测试场的原因。
这是一个主观的观察，但我从未见过设计师要求进行广泛的更改，而这些更改没有伴随着大量的更小的更改。（这在很大程度上是由于色调和明度在协同工作中的方式。）现实情况是你永远不想在没有检查你的工作的情况下对 CSS 进行广泛的更改。由于组件通常作为整体维护，使用描述性的标签名称使 DOM 与 CSS 之间的关联更加明显。
但是，如果你没有使用基于组件的方法，更通用的类名可能对你有利。
Tailwind 的拥护者令人费解。Tailwind 拒绝了数十年的行业最佳实践和架构和编程建议；它的存在是倒退的，与浏览器和设备技术相悖。
除了 Tailwind 拥护者的一个小圈子和一些误入歧途的博主之外，更广泛的行业都在回避它（如上面的“满意度与使用率”图表所示）。
“Tailwind 似乎正在加速发展，至少从其社区对调查结果的 Twitter 互动来看是这样的。”
好吧，当然，如果一个小社区声音更大，它就会显得更大。
这一切听起来都很好，但我们不使用网格和所有其他花哨东西的原因是......该死的 IE :/
忽视旧浏览器可能对“Codepen 开发者”（只为乐趣和自己编程的开发者）有用，但在我的工作中，我们还需要几年时间才能使用网格。
所以，我们不是懒惰或愚蠢，我们受合同约束。
你可以支持 IE 并且仍然使用 CSS Grid。你可以使用 CSS @supports。你为 IE 编写遗留代码（浮动或表格布局），并将你的现代 Grid 代码包装在
@supports(grid: auto){ ... }中。现代浏览器会获取 Grid，而 IE 会获取遗留布局。然后，在几年后，当 IE 最终因其缓慢而痛苦的死亡而消失时，你只需删除遗留代码。另外，我敢打赌，一旦微软在 2020 年 1 月结束 Windows 7 的生命周期，IT 部门将很快迁移到更现代的操作系统和 MS Edge。运行旧的、不受支持的操作系统以及旧的浏览器是一个安全噩梦。随着所有数据泄露和勒索软件的泛滥，所有企业都希望其计算机系统安全，否则可能会损失数百万美元。
“像 Tailwind 和 Tachyons 这样的库提供了切实可行的、现实世界的益处。”
比如什么呢？缺点解释得很清楚；你无法更新你的样式表。但这些切实可行的益处是什么呢？我读过几次，但我仍然不清楚为什么我应该考虑它。
如果你想了解更多信息，可以从这两篇几乎是经典的文章开始
https://mrmrs.cc/writing/scalable-css
https://www.smashingmagazine.com/2013/10/challenging-css-best-practices-atomic-approach
如果你仍然感兴趣，这里还有很多（更新的）文章链接：https://johnpolacek.github.io/the-case-for-atomic-css
我过去一年半一直在使用 Tailwind。我无法想象用其他方式编写 CSS。我一直致力于一个大型设计系统，大概有 100 个独特的组件。清除后的 CSS gzip 后只有 6kb......用 BEM 或任何其他非实用优先框架都无法实现这样的结果。而且它使用起来非常快......我不必考虑类名，也不必担心重复......
display: flex在我的整个网站中只定义了 3 次。每个断点一个......太棒了！有趣的文章。第一个预测谈到了 CSS 仍然是一个专业人士自己没有很好探索的领域，我对此感同身受，它反映了我的工作方式——我的瘾，我的执着。
当 Flexbox 出现时，它有效地解决了如此多的设计问题，以至于我变得依赖它。为了开始使用 CSS GRID，这是一个更简洁、更精致且更简单的解决方案——我需要在我的项目中进行有意的练习。我不得不处理很多错误、很少的成功和延迟。经常回到已经占主导地位的 Flexbox 的舒适区。
第二个关于函数式 CSS 的预测是我永远不会适应的。函数式 CSS 对我来说就像个笑话。这几乎就像用类来做内联 CSS。代码看起来很糟糕。我不知道是为了新鲜感还是纯粹的审美，但我支持并捍卫 HTML 文件和样式文件之间最大程度分离的柏拉图式理念。