Firefox.com 回到原生 CSS，没有预处理器不等于没有构建
设计师 Jo Sprague 在 Firefox.com 重建复盘中介绍，团队用现代原生 CSS 构建设计系统，没有使用 CSS 预处理器。文章也明确保留了一个脚注：生产流程仍用 PostCSS 展开导入，避免浏览器串行获取样式带来的性能问题。
作者：林岚｜OC 开发者生态编辑
设计师 Jo Sprague 在 Firefox.com 重建复盘中介绍，团队用现代原生 CSS 构建设计系统，没有使用 CSS 预处理器。文章也明确保留了一个脚注：生产流程仍用 PostCSS 展开导入，避免浏览器串行获取样式带来的性能问题。
一句话结论：原生 CSS 的成熟减少了语言转换，不意味着生产网站不再需要构建与交付优化。
源码是什么，和怎样发布，是两个问题
“没有预处理器”说的是作者直接编写浏览器能够理解的 CSS，而不是先写一种需要编译的方言。“没有构建步骤”则是对交付流程的另一种描述。
Firefox.com 的案例恰好把两者分开。源文件是有效 CSS，构建时仍可合并导入。这样的工具不会创造新的语言语义，主要改变资源交付方式。
这比追求绝对纯粹的口号更实用。团队需要减少不必要的复杂性，但没有理由为了一个标签保留已知的加载开销。
浏览器补齐的能力，改变了架构选择
变量、Grid 和 Flexbox 等能力让许多过去需要额外工具处理的需求，可以直接表达在平台标准里。
当浏览器理解变量与布局关系，调试时看到的对象也更接近开发者实际编写的内容。少一层转换，通常意味着少一组需要同步理解的规则。
但原生并不自动意味着简单。复杂的选择器、层叠关系与设计约束仍可能难以维护。决定代码质量的，依然包括命名、边界和组件约定。
设计系统的用户不只有工程师
作者称项目包含 70 多个组件、25 种页面模板，并支持 19 个语言区域。它们被接入内容管理系统，让内容团队能够组合页面。
这里真正改变效率的，不只是样式少装了一个依赖，而是设计决定能否稳定地进入内容工作流。编辑选择一个组件后，应当得到可预测的间距、排版和交互。
如果每次组合都需要工程师救场，再“现代”的 CSS 也没有完成设计系统的任务。复用价值来自约束清楚，而不是积累一大堆可选部件。
多语言会检验抽象是否真实
同一个按钮在不同语言里可能长短不同，标题会换行，页面结构也可能出现局部差异。只在一张英文设计稿上好看的组件，不足以支撑多语言生产。
这个案例提示团队，应把内容变化当成组件验收的一部分。长文本、缺失图片、小屏幕和不同阅读方向，都可能暴露隐藏的布局假设。
原生布局能力可以帮助解决这些问题，但不会自动替设计团队定义所有状态。平台能力成熟后，工作只是从兼容补丁转向更接近内容本身的设计判断。
旧浏览器不必复制全部体验
复盘提到，为较旧浏览器提供基础、可访问的品牌样式。这个做法体现的是分层支持：核心内容可读，不等于每一个视觉细节都必须一致。
采用者需要先明确自己支持的环境，再决定哪些特性可以渐进增强。不能因为一个大型网站能够使用原生 CSS，就断言所有已有项目都应立即删掉预处理工具。
对老项目而言，迁移成本、团队熟悉度和现有组件库同样重要。更合理的结论是：新的默认选项变多了，平台本身已经能够承担过去外包给工具的一部分职责。
关键事实
案例使用原生 CSS、无预处理器；生产中仍用 PostCSS 合并导入；组件与多语言规模来自作者复盘；不是所有网站都应立即迁移的对照实验。
OC 判断
值得学习的是把源码语义和交付优化分开，而不是把“零构建”当成架构优越性的证明。
为什么重要
前端团队可以重新评估哪些依赖仍有价值。减少转换层的收益，应体现在调试、协作和长期维护，而不只是配置文件变少。
评论
围绕这篇文章补充信息、提出问题或分享观察。