Github: https://github.com/nzbin/snack

Demo:  https://nzbin.github.io/snack/

 

前言

这篇文章我已经酝酿了半年之久，或者说拖沓了这么久吧。想说的东西很多，却又无从说起。如今轻量级框架如雨后春笋，层出不穷。我想每个人都应该归纳总结工作中的常见需求，编写一套适合自己的 CSS 框架。在之前的文章中，我提到了面向对象的 CSS（比如 BEM、OOCSS、SMACSS，详见 ）。这是一种思想，并不涉及具体的 CSS 问题，主要是类命名的策略！现在仍然有很多人对于前端框架的认识还停留在表面，认为 Bootstrap 是后端人员专用，前端没必要等等。我不知道这种说法从何而来，我最开始也不喜欢使用框架，或许和很多人的想法一样，畏惧新知识、害怕难以驾驭、遇到问题的时候无法解决等等。最关键的一点是很多人认为框架的样式是固定的，修改起来太麻烦，还不如自己根据设计图写起来方便。

为什么使用框架

为什么使用框架？答案显而易见，效率。除此之外，使用框架或者研究框架的意义还有很多，比如面向对象思想的具体实现。在上一家公司工作的时候，开始的几个项目我也是用最原始的方法书写 CSS 。项目之中最让我头疼的就是类的命名。我想大多数人都是根据功能去命名，这就造成了很多的冗余，相同的组件可能写很多次。简单举一个例子，如下图，个人中心的登录界面。

很多人包括我刚开始的时候可能会选择下面的类命名及布局方式，其通用性非常差

请点击登录

然而了解 Bootstrap 的人应该一眼就发现上图就是一个 media 对象，无非一些小细节需要调整一下

请点击登录

为了让文字与图片居中对齐，我们可以使用 Bootstrap 的 .media-middle 的辅助类。如果在工作中还要根据需求自定义一些辅助类调整细节，当然这是一个移动端的例子，可以选择移动端框架相关的 media 对象。

另外，在项目改版的时候，原始的方法的修改更是惨不忍睹，可以说是噩梦，冗长的 CSS 文件、混乱的功能划分、类名、色值等等。最后也只能硬着头皮一点一点修改。那一刻我才体会到框架的意义以及前端工具的重要性。我从工作中总结出，要么你可以熟练的使用某一个框架，要么就自己实现一个框架。

前端框架对比

目前市面上前端框架主要分重量级与轻量级。重量级主要有 Bootstrap、Semantic、UIkit、Foundation 等，轻量级有 Pure、Skeleton、Miligram 等。经常关注前端动态的工程师会发现轻量级框架每年都层出不穷。在我上面提到的主流轻量级框架之外还有很多类似的框架。我一直问自己，为什么要重复造轮子。经过研究，我发现这些轻量级框架其实大多都不能胜任工作需求，而且模仿的痕迹很重，基本上都或多或少的有 Bootstrap 的影子。那么这些轻量级框架有没有意义呢？当然有。但是就我个人观点，选择轻量级框架反倒不如自己实现一个框架。因为大多轻量级框架就像是工作总结，是根据自己的业务需求实现的。所以大多不具有通用性。

前端框架的对比主要以 Bootstrap、Semantic、UIkit 为主，因为我个人感觉这三个最具有代表性，而且设计风格各有特色。Foundation 也有很多大公司在用，但以我个人观点，无论是框架的易用性还是设计风格，相比其它几个框架稍逊一筹。

其中 Bootstrap 和 Semantic 是面向对象的最好体现。

我先说一下 Bootstrap 的优势，不是设计风格，不是模块，不是特效，而是栅格，响应式栅格。Bootstrap 的栅格在与其它框架对比中占有绝对优势，无论是栅格的划分还是类名的风格都堪称经典。如果读者有心看一下 Bootstrap 的 Less 源文件，就会感受到 Bootstrap 对于响应式栅格的独具匠心。其实在 Bootstrap 之前也有很多栅格方案，但是给人的感觉就是不够利索，类名繁琐不好记。而后来的很多框架，尤其轻量级的框架大多都有 Bootstrap 的影子。

下面我们通过对比几个框架的栅格和按钮来看一下类命名的策略。

Bootstrap

Button

Semantic

Primary

Foundation

Primary

UIkit

Primary

Pure

A Primary Button

通过上面的对比，大家应该已经发现了这些框架的命名策略的不同。不可否认，Bootstrap 的命名最经典。

之前在网上看到有人讨论关于框架的易用性，有人说 Bootstrap 的类名太长，然而通过上面几个框架的对比，Bootstrap 的类并不繁琐，而且用预处理器编写框架时嵌套会比较灵活。

Foundation 的栅格应该是最丰富的，策略上类似 Bootstrap，只是对公共属性进行了拆分，大家也可以看看其中的具体细节。

Semantic 的类名最简洁，通过多个定语的修饰组成一句话，确实很有意思。但是过多的修饰类在编写框架时会稍显凌乱，有利有弊，因人而异吧。

UIkit 和 Pure 的策略相同，都加了前缀以区分其它框架，但是很显然类名过于冗长了。我在编写框架时也这样想过，但是最终放弃了这种方式。

关于 CSS 预处理器

CSS 预处理器早已不是什么新鲜事，但是真正能够在工作中运用的人有多少呢？熟练使用预处理器特性的人又有多少呢？

我之前工作的时候也没有用预处理器，因为不用，所以也意识不到预处理器的好处。主要是觉得麻烦，因为要使用编译器编译一下，还不如直接写 CSS 方便。但是在项目维护的时候就意识到预处理器的好处。后来在几个项目中尝试了预处理器，但是对于模块化的写法不太明确。预处理器作为工具，可以实现模块化编写 CSS，那么应该如何划分模块？另外，预处理器有很多特性，但是大多数人刚开始只用到变量和嵌套，其它的特性几乎很少用到。我相信在自己动手实现一个轻量级框架的过程中，我们可以对预处理器有一个全面的了解。

目前流行的预处理器有 Less，Sass，Stylus 三个，选择哪个完全是看自己的习惯。我最开始因为 Bootstrap 了解的 Less，但是因为习惯选择了 Sass，其次 Sass 的功能要更全面一些。

无论是工作还是自己写项目，都要搭建一个项目环境，也就是安装一系列的 npm 包。相比刀耕火种的开发方式，使用工具开发的前期准备过程稍显麻烦，然而一旦环境建好，后期的开发将会游刃有余。