#ruby-on-rails #django #hosting
#ruby-on-rails #django #хостинг
Вопрос:
Я знаю, что существует множество существующих вопросов по хостингу Django и т.д., Но мой вопрос заключается в том, есть ли техническая причина, по которой хосты RoR проще использовать, чем хосты Django. Есть ли что-то в самой технологии или архитектуре, что затрудняет размещение и обслуживание провайдеров?
Казалось бы, проще найти лучшие бесплатные хосты для RoR, чем для Django (10 мб из alwaysdata на самом деле многого не позволяют, а App Engine — это не ванильный Django), и легче найти приличные RoR-хосты за 2 доллара в месяц, оснащенные функциями, чем для Django.
Причина техническая или просто из-за доли рынка / сроков?
Спасибо, Сяо
Ответ №1:
Давайте посмотрим правде в глаза, бесплатные хостинги далеко не хороши и не очень дешевы. Если вы хотите приличный хост, вам придется заплатить приличную сумму.
С другой стороны, rails почти на 1 год старше django и начал популяризироваться намного раньше, чем django. Кроме того, php старше и популяризировался раньше, и это кажется веской причиной для того, чтобы rails был более популярен среди хостингов, чем django.
Комментарии:
1. Heroku бесплатен (если вам просто нужно тестовое развертывание), и в настоящее время для django нет чего-то подобного (по крайней мере, пока)
2. Существует Djangy , который фактически является клоном Heroku, который включает в себя первый экземпляр бесплатно. Однако я думаю, что они все еще находятся в закрытой бета-версии.
3. @theTRON Djangy мертв, и подобные проекты (например. Gondor, ep.io , dotcloud.com …) не предлагает бесплатные экземпляры для разработчиков или все еще находится в бета-версии. Heroku находится в производстве уже много лет 🙂
Ответ №2:
Django не сложнее для хостинга, чем RoR.
ИМХО, это предложение delta существует в основном из-за доли рынка, которую RoR имеет по сравнению с Django.
Если верно, что rails старше Django, также верно, что Python старше (и используется большим количеством людей), чем Ruby.
Кроме того, технология, подобная WSGI, которая упрощает работу с веб-приложениями, уже существовала, когда нечто подобное появилось для Ruby (Rack).
Ответ №3:
Лично я думаю, что это требует меньше времени и больше поддержки сообщества. За Rails стоит чрезвычайно активное и вокальное сообщество. Просто зайдите в свой местный книжный магазин и взгляните на книги там. Вероятно, вы найдете в 5 раз больше книг по Rails, чем по Django. Как говорится, скрипучее колесо смазывается. Пользователей Rails сильно меньшинство, и это означает, что люди будут обслуживать их на общих хостингах, потому что в противном случае им придется выслушивать множество запросов, которые продолжают запрашивать это.
Не хочу сказать, что время выхода на рынок не имеет к этому никакого отношения, я просто нахожу, что сообщество, стоящее за любой данной технологией, имеет много общего с уровнем ее внедрения в различных бизнес-моделях.
Кроме того, любой хост, на котором размещены приложения Ruby, может размещать практически любую из основных платформ, если они совместимы со стойкой. Поэтому, чтобы иметь дело с Rails, они обычно получают поддержку Sinatra, Ramaze и т.д. бесплатно. Вместо того, чтобы просто поддерживать Django.
Комментарии:
1. Поскольку Ruby использует Rack, Python использует WSGI (который также старше), поэтому я не вижу никакой разницы между ними.
2. @Tommaso Barbugli- Единственная причина, по которой я считаю это причиной, заключается в том, что у Rack есть активное сообщество. Да, вы правы. И на самом деле это работает (в некоторой степени) с Passenger. Я не проводил с ним большого тестирования, но я знаю, что это работает таким образом на одном из хостов, которые у меня есть.