Обновленная (текущая) рекомендация на направляющих по сравнению с Django? [закрытый]

[Репост от HN, та же ссылка, что и вопрос, так как я хотел бы услышать ваш (вы не ответили на HN) и ответ ТАК.]

Я, очевидно, предвзято, поскольку я запустить компанию по разработке django. Тем не менее, я начну с ответа на недостатки Django,

1. Кривая обучения: Не больше, чем любой другой фреймворк. Плюс документация на высшем уровне. (Когда я проводил оценку, меня продала документация.)

2. Меньшее сообщество: Определенно верно. Но за пределами критического размера размер сообщества не имеет значения. Django намного превосходит этот размер. (Irc: в любой момент ~ 200 разработчиков. Группа Google: 14000+ пользователей)

3. Более медленный цикл разработки самого проекта ?: Почему? Если вы дадите более подробную информацию, я могу ответить на этот вопрос.

4. (un) Доступность оффшорных ресурсов: Определенно меньше, чем 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+

Вы забыли по крайней мере одно преимущество Rails - улучшенную тестируемость с помощью RSpec / Cucumber. Действительно, главное (дополнительное) преимущество - это внимание к Ruby / Rails со стороны сообщества agile-тестирования. Использование тестирования естественного языка должно значительно улучшить способность рассуждать на основе ваших тестов и способствовать пониманию. В некоторых отношениях это могло бы компенсировать «магию», которую вы ненавидите, документировав ее с помощью легко читаемых тестов.

Кроме того, я бы предположил, что новый проект, на который вы тратите деньги своих друзей и семьи, вероятно, не идеален ситуация, в которой нужно изучить новый язык / фреймворк. Зачем добавлять дополнительный риск к и без того рискованному предприятию?

Я просто собираюсь поспорить со многими из ваших утверждений:

• Django может иметь меньше волшебства, чем Rails, но кое-что еще есть. Python более понятен, поэтому вы получите ясность.
• Django известен тем, что его легко изучить, поэтому я не думаю, что кривая обучения Djangos является проблемой.
• Unladen Swallow пока что является парообразным продуктом. Никогда НИКОГДА не принимайте программные решения, основываясь на обещании, что какое-то программное обеспечение будет доступно в будущем.

Поскольку вы уже знаете Rails, вам следует придерживаться его, если вы не знаете, что это будет болезненно. Кроме того, если вас не устраивает Rails, я бы порекомендовал вам ознакомиться с руководствами для некоторых других существующих фреймворков Python, таких как Turbogears 2, BFG и Grok. Возможно, вы предпочтете что-то менее монолитное или более полное, чем Rails / Django.

http: //bfg.repoze.org/[1236 visiblehttp://grok.zope.org/[1237 impressionhttp://turbogears.org/

У меня разные взгляды на сравнение этих двух фреймворков. Я все еще новичок в этих двух, поскольку я разработчик Java и ищу что-то более увлекательное в свободное время. Я внимательно наблюдал за этими двумя фреймворками и пришел к следующему:

Rails

Как вы знаете, Rails родился из веб-приложения, созданного 37signals, которое влияет на архитектуру if. Я еще не использую Rails в реальном приложении, но думаю, что смогу использовать его в своем следующем домашнем проекте.

1. В основном то, что я вижу по Rails, - это то, что это монолитный тип фреймворка (хотя это изменится в Rails 3, поскольку он будет принимать архитектуру Merb). Эта архитектура от Моя точка зрения также повлияет на способ доставки / упаковки вашего проекта. Я считаю, что монолитный проект хорош, если вы хотите доставить все приложение в одном пакете для своего клиента.
2. Согласно архитектуре, Rails использует плагин, если вы хотите расширить или добавить другую функцию. Я считаю, что это хорошо, если вы хотите иметь продукт на основе сообщества, где пользователь может добавлять плагин.
3. Они сказали, что Ruby медленный, но тогда, если вы хотите упаковать приложения Rails как продукт, было бы довольно сложно упаковать его как файл войны с JRuby и warble. Например: Mingle от Thoughtwork использует этот подход.
4. Имея это в виду, IMHO (ну, DHH также сказал это на конференции Ruby vs Snakes) Rails подходит для веб-приложений.
5. Rails имеет хорошую встроенную поддержку ajax (rjs). Люди Django, легко добавить поддержку Ajax в django, но я считаю, что такая абстракция, как в Rails, того стоит.

Django

Django родился из газетного сайта, поэтому так или иначе, это также влияет на архитектуру самого django. Я использовал django только на своем веб-сайте с песочницей, и пока мне очень нравится создавать с его помощью веб-сайты.

1. Большая часть грязной работы была сделана за вас (фреймворк RSS-каналов, общий вид, администратор, фреймворк комментирования и т. Д.)
2. Django имеет архитектуру «подключаемого приложения». Это хорошо, если вы хотите подключить уже созданные приложения django, созданные сообществом, или поделиться этим приложением на нескольких своих сайтах.
3. Как я уже сказал, если это внутренние веб-сайты, я считаю, что использовать django действительно хорошо, потому что вы можете повторно использовать эти приложения на нескольких веб-сайтах. Но было бы действительно сложно доставить это в одно приложение типа пакета, потому что обычно (ну, лучшая практика, как я бы сказал) эти приложения django живут в PYTHONPATH вместо того, чтобы объединять все это вместе в вашем приложении. Хотя Pinax распространяет все приложения в одном пакете, и мне любопытно, как это делает Эллингтон.
4. Поскольку текущий Python быстрее, чем текущий Ruby (1.8), это делает сам django намного быстрее, чем Rails (есть много тестов об этом в сети). С такой производительностью IMHO django действительно подходит для веб-сайтов с высоким трафиком (подумайте о twitter, как о веб-сайтах с трафиком)

Некоторые люди могут не согласиться со мной, поскольку они могут найти обходной путь для использования Rails в качестве веб-сайтов и django в качестве веб-приложения. Но это то, что, как мне кажется, отличало эти двое по архитектуре. Таким образом, это также определит, для чего они нужны. Не стесняйтесь не соглашаться со мной: -)

Ура.