关于Rails与Django的更新（当前）推荐？

Question

（免责声明：I asked this question yesterday on Hacker News。虽然答案很好，但显然缺乏技术讨论，更多的是“你应该使用rails，因为这就是你所知道的。”因为Joel和Jeff明确表示他们不介意从其他网站转发问题...而且因为我真的很喜欢我在这里找到的答案......这里去了）

大家好。

我意识到这篇文章是一个臭名昭着的“对抗”问题，毫无疑问，对于较旧的帖子而言是多余的。但是，我在Rails和Django上找到的大部分信息已经过时，基于很多旧版本的框架，所以请原谅我。

首先......我是一名Rails人。三年前我来到这里，非常享受它带来的很多东西。我不仅仅是一个Ruby人......我有大约11年的总经验，包括Java，C / C ++，Perl，Tcl，（某些）Python等等。

无论如何，我有一个想法，我相信将接管世界。我已经说服了一些人，并且有朋友和家人的资金来吸引一些离岸开发人员，并尽快让他们接受测试。

然而，现在，我仍然决定使用什么技术。虽然我真的很喜欢Ruby ......我已经厌倦了魔法和滥用开放课程。当你需要快速注入一些行为时，这是非常好的，但是当你必须维护你的项目或它所依赖的任何插件时，它会变得非常痛苦。我个人更喜欢Ruby而不是Python（主要是因为块），但我羡慕Python社区中的清晰度第一的态度。鉴于这种挫败感，我正在认真考虑深入研究Django并将其用于此项目。

我在Rails方面看到的优点是：

1. 社区规模（鉴于其中一些“社区”包括PHP难民，不一定是加分）
2. 我的熟悉和经验
3. 使用它的公司数量并努力改进它
4. 离岸资源的可用性

Rails的缺点包括：

1. 太多魔法
2. 文档在地方仍然很糟糕
3. API不一致
4. 我提到了魔法吗？

Django方面的（感知）优势：

1. 净度
2. 性能......我相信Unladen Swallow将真正改变Python格局并赋予其竞争优势
3. Google对语言本身的支持（参见＃2）

Django的缺点：

1. 学习曲线
2. 小社区
3. 项目本身的开发周期较慢？
4. （联合国）离岸资源的可用性

所以，到目前为止，这是我的思考过程。我很高兴我可以快速加速Django，我的Python基础知识仍在我的记忆中。但我想得到你的意见，因为我真的很尊重我在这里读到的很多人的愿景和经验。

感谢您的帮助。我真的认为这个想法会起飞，所以做​​出正确的技术决定对我来说非常重要。

并说选择Rails只是因为我有经验那里听起来不对。如果是这种情况，我仍然会使用Perl或C.

谢谢！

Answer 1

[从HN转发，与问题相同的链接，因为我希望听到您（您没有回复HN）和SO回复。]

我显然有偏见，因为我经营一家django开发公司。那就是说，我开始回答Django的缺点，

1. 学习曲线： 不超过任何其他框架。此外，文档是一流的。 （文档是我在评估时卖给我的。）

2. 较小的社区： 绝对是真的。但超出临界规模，社区规模无关紧要。 Django远远超过这个规模。 （Irc：任何给定时间~200 Devs.Google group：14000+ Users）

3. 项目本身的开发周期较慢？： 为什么？如果你提供更多细节，我可以回答。

4. （联合国）离岸资源的可用性： 绝对不及Rails，但仍然没有你想象的那么糟糕。一个非常小的列表，http://uswaretech.com/blog/2009/03/web-development-companies ...

多数民众赞成说，鉴于您的信息，我的情况下我会选择Rails。即使您希望离岸工作的大部分工作，您现有的Rails经验将是一个巨大的优势，帮助您评估供应商，跟踪。

在一个半相关的说明中，Django不太成熟/较小的社区被夸大了，一些数字，

1. 正在开发中。 ROR：5 / Django 5
2. 最大的Google群组成员：ROR 18000 + / Django 14000 +
3. 目前Irc的成员：Ror 436 / Django 401
4. 承诺回购：Ror？/ Django 11000 +

Answer 2

您忘记了Rails的至少一个优势 - 通过RSpec / Cucumber增强可测试性。实际上，主要（附加）优势是敏捷测试社区对Ruby / Rails的关注。使用自然语言测试应该显着增强从测试推理和促进可理解性的能力。在某些方面，这将通过易于阅读的测试来记录您所厌恶的“魔力”。

除此之外，我建议你花费你朋友和家人的钱的新项目可能不是学习新语言/框架的理想情况。为什么要为已经冒险的企业增加额外的风险？

Answer 3

我只想与你的许多陈述争论：

• Django可能没有Rails那么神奇了，但还是有一些。虽然Python更清晰，但您将获得清晰度。
• Django因易学而闻名，所以我不认为Djangos的学习曲线是个问题。
• Unladen Swallow是迄今为止的蒸汽器皿。永远不要根据将来可以使用某些软件的承诺做出软件决策。

既然你已经知道Rails，你应该坚持下去，除非你知道它会很痛苦。另外，如果您对Rails不满意，我建议您浏览一些存在的其他Python框架的教程，如Turbogears 2，BFG和Grok。可能你更喜欢Rails / Django不那么单一或更完整的东西。

http://bfg.repoze.org/ http://grok.zope.org/ http://turbogears.org/

Answer 4

我对这两个框架的比较有不同的看法。我仍然是这两个人的菜鸟，因为我是一名Java开发人员，正在寻找一些在我的业余时间更令人兴奋的事情。我一直在密切观察这两个框架，并想出了这个：

滑轨

如您所知，Rails诞生于37signals制作的基于Web的应用程序，它影响了if的体系结构。虽然我还没有在实际应用程序中使用Rails，但我想我可能会将它用于我的下一个宠物项目。

1. 基本上我从Rails可以看到它是一个整体类型的框架（虽然这将在Rails 3中改变，因为它将采用Merb架构）。这个架构来自 我的观点也会影响您交付/打包项目的方式。如果您想将一个捆绑包中的所有应用程序交付给您的客户，我认为Monolith类型的项目很好。
2. 根据架构，如果您想扩展或添加其他功能，Rails会使用插件。我认为如果你想拥有一个基于社区的产品，用户可以添加插件，那就太好了。
3. 他们说Ruby很慢，但是如果你想把Rails应用程序打包成一个产品，那么将它打包为warub文件与JRuby和warble是相当麻烦的。例如：Thoughtwork的Mingle使用这种方法。
4. 考虑到这一点，恕我直言（DHH也在Ruby vs Snakes会议上也说过这一点）Rails适用于Web应用程序。
5. Rails有一个很好的内置ajax支持（rjs）。 Django人很容易在django上添加Ajax支持，但像Rails这样的抽象仍然让我觉得非常值得。

Django的

Django出生于一个报纸网站，所以在某种程度上也影响了django本身的架构。我只在我的沙箱网站上使用了django，到目前为止我真的很喜欢用它构建网站。

1. 大部分肮脏的工作已经完成（RSS Feed框架，通用视图，管理员，纪念框架等）
2. Django有一个'可插拔应用程序'的架构。如果您想插入由社区制作的已制作的django应用程序，或者在您的多个站点共享这些应用程序，那么这是很好的。
3. 正如我所说，如果这是一个内部/内部网站，我认为使用django真的很好，因为你可以在几个网站上重复使用这个应用程序。但是将它交付到一个捆绑类型的应用程序真的很难，因为通常（这是我所说的最佳实践）这个django应用程序存在于PYTHONPATH中，而不是在应用程序中将它们捆绑在一起。虽然Pinax将整个应用程序分发到一个软件包中，但我很好奇Ellington是如何做到的。
4. 由于当前的Python比当前的Ruby（1.8）更快，这使得django本身比Rails更快（在网上有很多基准测试）。有了这种表现，IMHO django非常适合高流量网站（想想像交通网站一样的推特）

有些人可能不同意我，因为他们可以找到使用Rails作为网站和django作为Web应用程序的解决方法。但这是我认为根据他们的架构区分这两者的原因。因此，它也将定义它们有什么用处。随意不同意我： - ）

干杯。