HE Shi-Jun

@ImJoeHs 仔细读原文，就知道意思是原本如果chunk已经加载，则调用require.ensure是同步的。

貌似是故意这样改的，因为 CommonMark（Markdown 的标准化）目前是这样的。不过我只是看到其实现是这样的，你也可以给他们开个issue讨论下 :)

写成一行还使得源码管理比较麻烦。比如diff，比如更大概率产生conflict。

@cssmagic 吐槽文不错，有翻译的价值（尽管已经一年半，某些情况已经发生变化），而且应该没有人翻译过。 我只讲一下该文接近结论的部分： > After five years of community experimentation I’m pretty convinced this problem won’t go away until we all start using the same module format for both authoring...

先说我一贯的观点：所谓css框架中的class命名问题，在没有css预处理时是无解的。原因很简单，离开html只靠css来谈class本身必然无解，因为css自己没有抽象复用机制，拿class来做这个事情只是一种hack，必然不靠谱。 如果你看原本的success和btn/alert，其实它们是本质不同的。success是组件的状态（某种程度上更接近“语义”），而btn/alert是组件的。所谓组件的，其实就是样式类（即用于样式钩子的class）。注意，这里是大体而言，具体案例中边界可能是模糊的。 在没有额外信息的情况下，使用者无法清楚某个class表示组件还是组件状态。这即所谓“What's that base class stand for”问题。而btn-success/alert-success通过固化组件和状态的组合及其在命名中的位置（以组件为前缀）弥补了这额外的信息。 --- 不懂OO的不要看这段，防止脑子浆糊 --- 如以OO为参照，btn/alert是klass（我以klass表示OO中的class，避免跟html中的class混淆），而success是这些类共同实现的interface或混入的trait。 .btn.success的方式像是klass+trait。但是因为使用者无法区分何为klass何为trait，结果看上去更像是多个trait的组合。 .btn-success的方式则像是klass+interface。从概念清晰的角度说肯定比多个trait要清晰啦。但是实现上存在不便，因为要把success共性部分复制来复制去。 需要注意的是，html并不是oo语言，你可以任意附加class，所以本质上说，所有的class都是trait。但是这里的问题是概念模型是怎样的。.btn-success所代表的klass+interface概念模型更一目了然。 --- 本段完 --- 所有他操心的其实是使用者如何能清晰快速的在html上挂样式类而不挂错。想明白这点，就会发现所谓前缀式其实并没有什么神秘的力量。假设我们为所谓chained方式引入额外的命名规约，其实也能解决问题。比如所有组件名首字母大写（就好像OO中的klass那样）。 .Btn.success .Alert.success 看上去是不是就突然清晰了？ BTW，注意“What if one instance of .success uses green...

再说一下其他问题。 写成.Alert.success的好处其实只对于开发者或扩展者而言是如此。对于那些纯粹的使用者来说其实没啥好处，反而会造成同志们所提到的误用问题（有.large.Button但没有.large.List）还有替换问题（我是要替换.large.Button还是.Button.large？）。 所以变成alert-success避免了所有这些问题。 当然如果我们想穿一点，为啥要写"alert alert-success"？直接写单个alert-success不就完了？这对于支持class自动完成的IDE来说写UI简直就是太easy了。 不过这样会导致css里更多重复。而且alert alert-success其实是个固定展开，还是比较容易记住的，我甚至觉得早晚会有IDE的自动完成会自动扩展成这样（说不定现在就有了）。 从这样的角度看，bootstrap的选择倒也是合情合理了。

当然，我肯定是不喜欢这种命名法的，包括更离谱的BEM之类的。 在有CSS预处理时，我们可以有更简单的做法。比如： ``` css enum ButtonStatus { normal, success } trait Button(status:ButtonStatus = normal) & ...some style declarations &:hover ...some styles for hovering button if status == success & ......

其实我的观点并不新鲜。 参考这2009年的文章（那时候还没有bootstrap！）： http://www.sitepoint.com/css-frameworks-semantic-class-names/ 稍微晚近的（2012年）： http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html

在第一篇文章里，可以看到css framework的鼻祖blueprint的compress.rb就是一个预处理程序，只是非常局限，从使用者的角度看还是有些问题的，不过至少绝对是可行的。 第二篇文章则示例了如何直接利用LESS的特性来使用Bootstrap的，类似的还有 http://www.hongkiat.com/blog/bootstrap-and-sass/ 中“Utilizing Sass Functions”这节。 所以可行与否？答案是肯定的，从前Bootstrap时代到Bootstrap自己都是可行的。 那么问题是为什么它不流行？你都很少见过？说实话，我也很少见到，虽然我早就知道是可行的。 我的想法：抽象不可能是没有代价的。这也恰恰是当初CSS为啥没有抽象机制的原因，因为CSS的创造者不想承担这样的代价。 而能理解这种抽象且愿意承担其成本的人，其实很可能有足够的能力和动力和资源去从头建造自己的framework，因此也没有足够动力去普及“你应该这样那样用bootstrap，而不是那样这样……”。当然其实这样的文章老早就有，但是并不广为人知，而是淹没在大量入门级的bootstrap示例文章里了。

还有使用者的问题。 比如我很晚才了解bootstrap，并直到现在都没有正儿八经在项目里用过bootstrap。因为具体的样式问题在我眼里不是问题。我的意思并不是那不重要，但是我不认为那是个大问题。 但是对于大多数普通开发者来说，有个开箱即用的方案是最重要的。可定制、可维护性、代码干净、语义等问题都是其次的，甚至许多人根本不明白这些东西是什么，有什么重要的。 有些人说，这种做法那种做法都一样，没有对错之分，只有适不适合。 我讨厌这种论调，不过某种程度上他们是对的。但更合理的讲法是，并非没有对错之分，而是某些问题的对错对于许多人和许多case来说，不重要。 所以剩下的问题是，我们自己怎么选择。