Grails или Play! для бывшего разработчика RoR?

Ответ 1

Я бы предложил Grails. У этого сообщества больше сообщества, чем в игровой инфраструктуре (~ 350 плагинов, охватывающих почти все основные потребности). Кроме того, grails написана почти полностью на Java, она просто позволяет использовать Groovy для конкретной реализации вашего домена.

Если вы столкнулись с проблемой производительности, когда создаваемые страницы Groovy, которые вы создали, являются узким местом, вы всегда можете просто переключиться на реализацию Java. Тогда вы находитесь в той же лодке, что и в рамке Play. Вы оптимизировали время разработки, отменив кодирование вещей на Java, пока не знаете, что вам действительно нужно это делать (что по моему опыту очень редко).

Я также не уверен, где вы слышали, что вам нужно перезапустить сервер для каждой модификации, но это на самом деле не так. Grails поддерживает перезагрузку контроллеров/gsps/services/объектов домена и т.д. Без перезагрузки сервера.

Смешанные stacktraces могут немного затянуться, но поставщики инструментов (например, Intellij) сделали некоторые недавние улучшения, которые выделяют все части стека, которые вам не нужны.

Я использую grails с тех пор .5 дней и очень доволен платформой.

Ответ 2

Я переключился с Grails на Play, и я никогда не оглядывался назад. Моя самая большая проблема с Grails - полная надежность и удобство использования. Большую часть времени меня укусил тот факт, что Grails склеивает обычный стек Spring MVC и Hibernate, пытаясь скрыть этот факт и предоставив вам Rails-подобный API (личное мнение). Проблема в том, что когда-то что-то выходит за рамки тривиальных образцов, оно легко ломается и не работает для меня. Развитие с ним было похоже на хождение по яйцам (для меня). Всякий раз, когда я искал документацию о необходимой мне функции, я не перенаправлялся на образцы, учебные пособия, блоги, а на Grails JIRA объяснял мне, почему функция не работает для моего варианта использования, и что ошибка не была решена с двух версий до одной Я использовал.

Хотя это не может быть общим опытом для каждого разработчика (я не пишу это в bash Grails, но чтобы поделиться своим опытом с этим здесь), мне нужно было что-то, что помогло мне и не помешало бы мне или ломать меня, когда мне это нужно больше всего. Thats, когда я нашел Play, и я быстро перенес свое приложение к нему после того, как узнал об этом (около версии 1.0).

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

Если бы мне пришлось сблизиться с тем, что Play сделал лучше, чем Grails - по крайней мере, для меня - это будет тот факт, что Play построен с нуля с учетом удобства использования разработчика. Это не жертвует легкостью использования для корпоративных слов. У него есть смелость выбрасывать то, что не вписывается в эту парадигму (например, во время разработки на основе сервлетов во время разработки для более быстрого поворота). Он готов пойти на компромиссы, чтобы гарантировать удивительность. И это то, что я видел только в таких сообществах, как Rails или Django, прежде чем я нашел Play.

Ответ 3

Обратите внимание, что Play! framework теперь поддерживает использование Scala с 1.1

Ответ 4

Из моего опыта работы с Play - отличная рамка. Моими любимыми функциями являются классная система контроллера и система шаблонов - обе простые, но многофункциональные и мощные.

Однако самым важным преимуществом Play является, безусловно, быстрый цикл разработки, где практически не требуется перезагрузка при изменении кода. Но если вы не будете осторожны, это величие не будет продолжаться много, и медленность в конечном итоге проникнет в ваш код.

Почему? В Play часто используются некоторые плагины с довольно тяжелой инициализацией, особенно EJB (Hibernate) и Spring. Инициализация этих плагинов перезапускается при каждом изменении кода перед загрузкой нового кода. В результате этого, по мере роста вашей модели и конфигурации вашей системы, эта сильная инициализация начинает серьезно замедлять ваше развитие. В системе, которую я использовал, 20 секунд были типичным временем запуска на виртуальной машине, работающей на ноутбуке с ноутбуком.

Что вы можете сделать, чтобы избежать этого, зависит от вашего приложения, например. если вы создаете приложение NoSQL, тогда плагин EJB не должен беспокоить вас. Spring может быть заменен пользовательским жестко закодированным Java-плагином, который IMHO также проще поддерживать или запускать Groovy script, если это важна для сценариев. В любом случае, следите за этими проблемами и убивайте их, пока они молоды, и не забудьте запускать свои собственные громоздкие инициализации при каждом обновлении.

Ответ 5

Если вы раньше использовали Ruby и Python, вам, вероятно, понравится Grails лучше Play. Очень сложно вернуться к Java, как только вы привыкли к этим динамическим языкам.

Ответ 6

Существует также Lift на Scala.
Imho scala - лучший статичный язык, а лифтинг - довольно приятная структура (для статического типизированного языка).