在之前两篇文章中我们已经讨论过如何使用BEM和Namespace来编写模块化的CSS。这篇文章中，我想避开把CSS选择器作为CSS文件结构和组织的依据的方法。如果你思考过关于什么是文件组织的最佳实践，或者怎样能够在项目目录中更容易的找到你要找的CSS文件，或者一个文件应该是多大或者多小合理等问题，那么这篇文章就是为你写的。让我们先看下你一般组织资源的两种方法。

上周，我分享了如何使用BEM创建一个合理的CSS架构。 虽然BEM很棒，但它只是解决方案的一部分。 还有另一部分我还没有提到 —— 命名空间。在今天的这篇文章中，我想与大家分享一下为什么只用BEM还是不够的，以及如何使用命名空间来弥补一些不足。

你是否做过多页面的大型网站或者其中一部分？如果你做过，你可能会意识到 CSS 架构不够强大所带来的恐惧。你可能还会研究如何编写可维护的 CSS。由于我们的行业很棒，我们有很多推荐的解决方案。因为专家们的纷纷加入，于是我们有 BEM，OOCSS，SMACSS，Atomic Design 等许多选择。现在，问题不是痛苦 “我不知道该怎么办”，而是： “有这么多的方法，我应该尝试哪个？”我是不是应该把所有的都用一遍，是不是只有一种方法才适合我，或者我是不是应该参考它们做一个自己的架构？。我开始只用一种方法。然后，当我尝试不同的方法时，我开始把我认为有意义的东西包含在我的探索过程中。 在这篇文章中，我想和大家分享一下我如何构建 CSS 以及为什么我这样做。 希望它可以帮助你找到你喜欢的方法。

想像一下，一个Web组件都在一个.js文件中，这个文件包含了一切：HTML结构、CSS样式和一些逻辑。仍然会有基本的样式表，但动态的CSS将使用JavaScript来处理。现在这样做是能做的，并实现它的一个方法称为CSSX。CSSX是我用了近一个月的业余时间写的一个项目，它是具有挑战性的、有趣的，而且在这个项目中我学到很多新东西。它的最终结果就是变成一个工具，允许你在JavaScript中写CSS。

CSS 是前端领域中进化最慢的一块。由于 ES2015/2016 的快速普及和 Babel/Webpack 等工具的迅猛发展，CSS 被远远甩在了后面，逐渐成为大型项目工程化的痛点。也变成了前端走向彻底模块化前必须解决的难题。