在以前我们的博客文章中，我们讨论了在web设计和开发项目中使用Twitter Bootstrap的好处。Twitter Bootstrap也有很多的缺点。让我们看看这些主要的问题：
1，它不遵循最佳实践
我们在使用Twitter Bootstrap时遇到的最大问题之一是你的DOM元素上将拥挤大量的类。这打破了良好的web设计基本规则之一，HTML不再有语义，而且内容和表示 不再分离。前端纯粹主义者会觉得这相当令人讨厌，以为它使可扩展性、重用性和维护性遇到了更大的挑战。表示和交互不再独立于内容在Twitter Bootstrap中也被进一步的强化。
哦，如此多不必要的类！
如果你被空投到一个干了一半的大项目中，想要使用 Twitter Bootstrappy 享受其所有的好处会如何呢？糟糕的是，你会碰到一大堆的问题，冲突首先会从生成 HTML、CSS和JavaScript 开始。然后是它们的资源，你必须深入项目中那些阴暗的角落，搞清楚哪些脚本和样式需要删除或替换。Twitter Bootstrap 会潜在创建额外的工作，当你深入项目会不可避免地发现和修复奇怪的错误，你为自己辩护的理由将会击败你优先选用它的目的。
坦率的说，Twitter Bootstrap包括126kb的CSS和29kb的JavaScript。如果你想要使用Twitter Bootstap的所有功能，你应该好好考虑资源的加载时间。当然，对于一些地方这可能不是问题，但是在新西兰互联网不得不横跨太平洋，这时数据达到那儿 将是很缓慢的。因此考虑你的目标市场。Twitter Bootstrap将帮助你建立一个有吸引力的、响应式的网站，但是一些手机用户将因为缓慢的加载时间和消耗电量的脚本而别拒之门外。
可能是最大的争论之一，BootStrap使用Less构建，原生不支持Compass和SASS。现在请不要误会我的意思，Less是好的，我以前使用它，它肯定有它的优点。但是SASS是更好的，带有一个类似于Compass的框架，使用它好像完全不需要过多的考虑。一些人建立了Compass gem的Bootstrap，但是坦率的说，你将不得不使用Less。在将来的文章中，我将更多的讨论SASS和Less。与此同时，Chris Coyier已经写了一篇文章比较两者。
Twitter Bootstrap超级流行，流行到所有开发人员和他家的狗都去用的程度。你可能发觉由于时间限制，定制你的app或者网站时被迫使用了很多原生 Bootrasp风格。这会导致无意创建很多类似的，一般的和无眼缘的网站。在Twitter Bootstrap 实现起来既快速又容易的同时，创意往往是妥协的结果。在受限的时间里，在Bootstrap结构化的环境中，实现打破常规的创新设计是很难的。
