原文链接：The Case Against Drupal Base Themes

译者：晴空

当涉及到Drupal的基主题时，似乎谈话往往局限于你应该选择哪一个基主题，而不是讨论你是否应该使用它。在有些人大肆宣扬各种基主题好处的时候，我认为我应该分享一下自己与此相反的看法——我们是否应该使用那些drupal.org 上其他人贡献的主题来完成我们的项目。接下来，我将会分析免费基主题和你自己开发的主题之间有哪些差别，这一点对于这篇文章的主旨是很重要的。

这种讨论实际上是一个更大的话题的一部分：前端开发人员都在讨论是否应该使用CSS和网格框架。当讨论到Drupal基主题的时候，由于drupal主题模板机制的复杂性，导致相关的问题变得格外突出。

我们为什么要使用基主题

为什么我们自己有那么多的人要使用基主题？简而言之，它们能为我们节省时间并有可能使我们更加高效。有的时候，他们也可以成为各个开发团队间共同的平台。但是我认为一个更准确的原因是因为他们特别是对于刚刚学习Drupal主题制作或者响应式设计来说，是一种很有用的工具。

在某个时间点，我们必须建好我们的第一个Drupal网站或者我们的第一个响应式页面——也许就是在你的项目截止日期的那天——于是我们期望基主题或者前端框架能帮帮忙。它使得我们能够按时完成工作，并且不会超出预算，但是我们往往都不完全了解他们到底是怎么运作的。

随着时间的推移，我们一般能学会大部分的基主题并且对响应式设计有了深入的了解，框架也被我们运用得驾轻就熟，我们于是安于这种状态，并乐在其中，直到有一天。。。

当捷径变成歧途

如果你使用基主题已经有一段时间了，那么你终归会发现自己在与它战斗。基主题和其他的前端框架的设计理念是非常固执的——它们必须自己决定如何去解决某个类型的问题。这在大部分的时候是好事儿。它可以让我们更快的解决问题。但是当它不能很好的解决这个问题的时候，你的基主题就要开始拖你的后腿并给你找麻烦了。

其中一部分原因是因为开发者往往没有完全掌握基主题或者相关概念——所以他们其实也不清楚到底发生了什么事情。当使用Omega或者Zen主题的时候这样的事情经常发生，因为这两个主题很复杂而且有很多文件及文件夹，大量的“钩子”等。所以，当出了问题的时候，需要花一大把力气才能找到原因。

另一部分原因在于有些时候基主题解决问题的方式与实际项目需求不吻合。你发现你的想法和基主题的解决方案相冲突，有的时候甚至有可能需要解决基主题和你想使用的某个模块之间不兼容的问题。

然后你为了解决这些问题所写的代码会怎样呢？他们只会让苦逼的手机小水管用户变得更加苦逼。

能快速加载的网站才是胜利者

这是另一个你也许不想使用基主题的原因——跟一个为某个项目定制的主题相比，基主题有可能会拖慢你的网页加载速度。事实证明能快速加载的网页就是好的网页。在大多数情况下，基主题都会包含很多你的特定项目所不需要的东西。这些额外的东西将最终拖慢你的网站速度。

这么说并不是要给基主题一记响亮的耳光。它们大部分都像瑞士军刀一样可以适用于各种情况——他们非常的灵活。如果你是一个初学者，你会发现这样非常有帮助。但是如果你是一个具有丰富经验的前端开发者，并且项目需求对性能要求很高的话，你会如何选择？

基主题扮演的角色

有些人可能会反驳道，Mothership或者Tao或者他们喜欢的某个主题能解决我刚才提到的所有问题。如果你完全掌握了这几个主题并觉得他们非常有用的话，我当然是不会与你们争论的。同样的，Zen 或者 Omega主题也可以非常有用。这种事情取决于具体的项目。这个帖子的用意并不是想要抨击基主题。

但是我自己在这个问题上的观念，已经发生转变了。我已经决定，只要有可能就删除基主题。我这个决定源于我想写精炼的代码，它能让我建立快速的，对移动设备更友好的网站。这同时也让我这个写代码的人能更精确的了解代码层面到底发生了什么事情。最后，我认为这样的做法能让作为前端开发者的我提高自己的工作能力，并且，重要的是，我同时也为我的客户提供了更优秀的产品。我在这样做之前，我花了太多时间去修改基主题，把他们改得连他妈都不认识了。我认为，我有时间改基主题的话真的不如自己重新写一个新的主题！

当然，我并没有把工作效率丢到一边。为了让工作变得简单一些，我使用我自己的初始主题，如果有人在考虑选择一个基主题的话，我也会给出同样的建议：创建你自己的“技能经验包”。如果这里面的东西无法满足你现在有的 项目需求的话，你可以精确的知道哪些是你不需要并且可以轻松丢掉的。