Подтвердить что ты не робот

Sproutcore или Cappuccino для Ruby-on-rails?

Rails - очень отличная бэкэнд-платформа, которая сохраняет все чистое и структурированное.

Я предполагаю, что вы все подумали о том, чтобы сделать то же самое для frontend.

  • SproutCore
  • Капучино

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

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

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

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

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

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

4b9b3361

Ответ 1

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Лично, я выбрал бы SproutCore для этого, потому что вы уже знаете JavaScript (я предполагаю?), и стиль разработки будет более знаком вам. Он также позволит вам использовать любые серверные рамки, которые вы хотите.

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

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


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

Ответ 3

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

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

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

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

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