关于Rails与Django的更新(当前)推荐？

Question

(免责声明:我昨天在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. 谷歌对语言本身的支持(见#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. 最大的谷歌群组成员: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应用程序的解决方法.但这是我认为根据他们的架构区分这两者的原因.因此,它也将定义它们有什么用处.随意不同意我:-)

干杯.