Росток или капучино для рубинов на рельсах? - PullRequest
18 голосов
/ 16 сентября 2010

Rails - это очень хороший бэкэнд-фреймворк, поддерживающий все в чистоте и структурированности.

Полагаю, вы все думали о том же самом для внешнего интерфейса.

  • Sproutcore
  • Cappuccino

Используете ли вы одну из этих инфраструктур MVC javascript для интерфейса с Rails?

В случае, если вы это делаете, вы довольны ею?

Как вы кодировали раньше и как он изменился?

Разве Sproutcore больше не подходит для Rails, потому что он использует js + css + html, что также делает Rails.В Cappuccino вы не используете ни один из них.

Поделитесь своими мыслями и опытом, потому что я полностью знаком с этим полем и не знаю, какой из них мне следует использовать с Rails.

Я просто знаю, что мне лучше иметь MVC-фреймворк, чтобы получить DRY-структуру и лучшие практики.

Ответы [ 3 ]

17 голосов
/ 21 сентября 2010

При рассмотрении фреймворков MVC на работе мы рассмотрели SproutCore и Cappuccino. Они оба черпают огромное количество вдохновения из концепции Apple Cocoa и Objective C.

Мы решили использовать SproutCore, потому что:

  • Он использует JavaScript таким образом, который соответствует взгляду Дугласа Крокфорда на JavaScript, как описано в JavaScript: хорошие части .
  • Хороший MVC-фреймворк, создающий быстрые приложения.
  • Хорошее сообщество, поддерживающее проект. Чарльз Джолли, папа SproutCore, до недавнего времени работал в Apple, а сейчас работает на SproutCore. Apple вносит большой объем кода в базу SproutCore и эффективно ее использует, о чем свидетельствует тот факт, что iWork.com был создан с использованием SproutCore.
  • SproutCore был разработан для очень тяжелых приложений, содержащих тысячи элементов, с использованием оптимизированных методов, таких как переработка элементов списка в больших списках, таких как Google Wave или Google Maps.

Мы не выбрали капучино, потому что:

  • Он создает другой язык, на котором вы запускаете свое приложение. Это не интуитивно понятно, заставляет вас думать в Objective J, что дает преимущества в том факте, что вы не привносите вредных привычек в JavaScript, но игнорируете Дело в том, что JavaScript красивый, расширяемый и мощный. (Я ни в коем случае не «хлопаю» целью J, просто предоставив информацию о том факте, что вы запускаете JavaScript в браузере, а не о цели J. Если вы запускаете другой язык в браузере, это может привести к путанице, поскольку вы устный перевод с использованием устного перевода.)
  • Однако Objective J и Cappuccino создают прекрасные приложения и используют языковую архитектуру Objective C, которая является хорошей моделью для рассмотрения в мире MVC.

(Имейте в виду, у меня нет большого опыта в Cappuccino и Objective J, поэтому, если я сделаю широкие и наивные заявления, скажите мне!)

Вам нужно больше смотреть на то, что вы хотите в качестве среды интерфейса, а не на то, что «лучше всего работает» с Rails. Обе рамки хороши. Мы выбрали SproutCore, потому что он больше соответствует нашим потребностям, которые у нас были для нашего приложения, и соответствует нашей идеологии.

По опыту работы с источником SproutCore я могу сказать, что он довольно независим от используемой вами реализации сервера. Мы используем Prosody, сервер BOSH, написанный на Lua. Вы хотите использовать Rails. SproutCore предлагает это из коробки:

  • Развертывание источников данных для Rails. FYI- DataStores - это нижний уровень модели SproutCore для подключения к веб-сервисам. Скорее всего, это место встречи между вашим приложением SproutCore и приложением Rails. SproutCore не предназначен для работы в Rails, но вы, безусловно, можете это сделать!
  • DataStore для служб RESTful Rails. Или любой REST API по этому вопросу. Он также позволяет использовать push-запросы на стороне сервера, если вам это необходимо.

Что касается ваших требований СУХОГО - это все на ваше усмотрение! Вы можете использовать платформу, чтобы сделать ваш код независимым и сухим, или иметь жесткие зависимости и повторяться. Любая структура хороша, это зависит только от ваших потребностей. Не нервничайте и узнайте сообщества и что происходит в каждом из них! Мы не кусаем ... слишком много.

3 голосов
/ 19 сентября 2010

Я уже сказал это в комментарии, но вы попросили меня опубликовать его как ответ, так что вот оно.:)

Rails мало что даст, если вы создаете клиентское приложение с расширенными возможностями.Платформы веб-разработки на стороне клиента обычно возлагают большую часть тяжелой работы на клиента и используют сервер только для хранения и, возможно, для некоторых сложных вычислений (при необходимости).Так что я бы лично сказал, что вам даже не нужны Rails - вы можете пойти с чем-то намного более простым, таким как Sinatra .Поскольку клиент является «мясом» вашего приложения, вы будете выполнять большую часть своей разработки там, поэтому сначала сконцентрируйтесь на поиске хорошей клиентской библиотеки / фреймворка, а затем заботьтесь о стороне сервера.

Тем не менее, я бы попробовал оба и посмотреть, что вам нравится больше.Капучино очень ... отличается, и многие люди откладывают его (в основном из-за Objective-J, я думаю).В моем ограниченном тестировании он также загружался гораздо медленнее, чем другие используемые мной фреймворки.Я рекомендую вам попробовать написать в нем небольшое приложение, и если вы чувствуете, что оно не для вас, вычеркните его из своего списка.

Лично Я бы выбрал SproutCore .Во-первых, потому что вы уже знаете JavaScript (я предполагаю?), и стиль разработки будет вам более знаком.Это также позволит вам использовать любой серверный фреймворк по вашему желанию.

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

В конце я бы порекомендовал вам просто попробовать их .Я не могу сказать вам, подойдет ли вам фреймворк.


Отказ от ответственности: я никогда серьезно не использовал SproutCore или Cappuccino для чего-либо, кроме тестирования, поэтому принимайте все, что я говорюзерно соли.

2 голосов
/ 16 сентября 2010

Я использовал Rails с капучино, и это было для меня очень больно, хотя это мнение имеет сильный личный уклон. Прежде всего, я просто не чувствую себя комфортно с объективом-j; У меня не было цели c предыдущего опыта, и мне просто не нравилась вся эта штуковина по отправке сообщений в виде маленьких разговоров (я скорее программист с функциональной ориентацией).

Более того, если вы хотите интегрировать Rails и Cappuccino, вы вынуждены везде использовать JSON, поэтому будьте готовы реорганизовать практически все для ответов на многие форматы (вы можете захотеть отвечать и на обычный HTML, если браузер пользователя это делает не работает с капучино - или JS в целом).

Кроме того, вы будете застревать на проблемах в течение более длительного времени, чем обычно, потому что не так много приложений и разработчиков Rails + Cappuccino (afaik) и все плохо документировано в Интернете.

И последнее, но не менее важное: вы потратите огромное количество времени на создание каждого элемента интерфейса в target-j; как и следовало ожидать, это гораздо больше похоже на написание какао-интерфейса, чем на веб (для меня это недостаток !), и я не знаю ни одного программного обеспечения / идеала, который бы помог вам в этом процессе (280atlas был анонсирован пару лет назад, но никогда не был открыт для публичного использования).

В целом, я бы не рекомендовал Rails + Cappuccino на этом этапе, если вы не используете его просто для развлечения и / или для изучения чего-то нового в веб-программировании.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...