Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Java: Groovy & Grails > Почему Grails невостребован


Автор: oson 27.8.2012, 12:19
Господа, не могу понять такой момент.
Если оценить возможности Grails с точки зрения ускорения работы, то тут просто гигантский потенциал.
То есть то что 5 человек в команде на Spring (или JSF) + Hibernate делают полгода, в случае Grails 2 человека делают намного быстрее например и при 
этом на выходе получают тот же war, ту же функциональность. При этом структура строго регламентирована,то есть можно легко
разобраться новому программисту, если старый уйдет, то есть проблемы с зависимостью от кадров должно быть меньше, чем на классическом Spring, JSF и тп.
Но при этом на freelance сайтах запросов на разработчиков Grails нет вообще. Изредка есть на сайтах по поиску работы. 
То есть вроде как никто особенно не использует эту технологию.
С чем это связано? Есть какие-то недостатки, которые всплывают по ходу работы?
Или какие-то жесткие ограничения, которые например не позволяют использовать просто JDBC вместо Hibernate?

Автор: oson 27.8.2012, 17:23
Чтото никто не отвечает.
То есть видимо просто невостребован и все.
На другом форуме ответил чел, что 
"Честно говоря, оно может быть и полезно вот так конструктивно обсудить, но я хочу забыть его, как страшный сон, в котором мы жили пол года"
Это про Grails.
Основные проблемы - "проблема с плагинами и их зависимостями, это не контролируется; трудно отлавливать ошибки; трудно контролировать то что генерируется на лету; Трудно интегрировать с другими технологиями"
То есть Grails не может заменить полноценный проект на Spring/Hibernate например.
Видимо Grails разработан для такого сектора, как несложные сайты и тп, но никак не ответственные банковские системы.
Типа Drupal для Java программиста?

Автор: AntonSaburov 27.8.2012, 18:48
Проблема в том, что более крутой технологический пакет при сложной задаче не сильно влияет на производительность. Тот же EJB, SpringBean, Web-Service создаются достаточно быстро - само время их создания измеряется минутами. Но практически всегда возникает две проблемы:
1. Понять, что хочет заказчик. Этот момент занимает от 30 до 40 процентов всей работы над проектом.
2. Ручная настройка из-за сложности задач. Никогда не видел, чтобы можно было просто взять и использовать пакет без всяких дополнительных телодвижений. 
Сгенерить тот же стандартный вариант редактирования списка сущностей из таблицы - визардов много для многих пакетов. Тот же JSF или GWT или Spring Roo. Но вот дальше начинается подстройки и в жестких и крутых генерилках типа Grails их сложнее (или как минимум не проще) делать, чем в более универсальных фреймворках.
Когда надо делать систему, которая данные получает из 15 мест разными технологиями и протоколами, когда таких вариантов получения несколько десятков или сотен и каждый уникален, а также нужны разные мордочки для сайта (мобильный, андроид, толстый, тонкий и т.д. и т.п) - в такой ситуации Grails уже технологически предоставляет весьма малый выигрыш, а иногда там и проигрыш получается.

Автор: oson 27.8.2012, 21:15
Спасибо.
А что скажете про Scala и Lift? Можно их использовать для J2EE проектов? 

Автор: oson 27.8.2012, 22:43
Ну совсем невеселые отзывы Java разработчики про Grails - какие то ошибки если валяться, то трудно понять где, приходится вручную тестировать, плагины тянут зависимости, которые друг другу мешают, подключить дополнительную нужную библиотеку сложно.
  При этом все таки его кто-то ж использует. Вероятно все же есть хоть какие-то плюсы? 
Какие то системы серьезные писали на нем - или только сайты-визитки? Тогда точно зачем отбирать хлеб у php-программистов?

Хоть бы кто-то сказал что-то хорошее про Grails :(

Автор: Vasay 28.8.2012, 01:52
Цитата(oson @  27.8.2012,  17:23 Найти цитируемый пост)
но никак не ответственные банковские системы.


Кстати, там он применяется. 


Цитата(oson @  27.8.2012,  17:23 Найти цитируемый пост)
То есть видимо просто невостребован и все.

У нас.

Вцелом - проект развивается (и гораздо быстрее чем многие другие Java фреймворки). Как я понимаю, основные разработчики использующие Grails - Индусы и Китайцы.

Цитата(oson @  27.8.2012,  17:23 Найти цитируемый пост)
проблема с плагинами и их зависимостями

Есть такое. 

Цитата(oson @  27.8.2012,  17:23 Найти цитируемый пост)
трудно отлавливать ошибки

Плата за динамическую типизацию. Согласен, что порой 10 строками кода на Groovy можно заменить 100 на Java, а потом долго отлавливать непонятную ошибку в этих 10 строках, которую на Java подчеркнул бы редактор кода.
Но постепенно, с опытом, начинаешь меньше делать таких ошибок и гораздо быстрее их отлавливать. 


Цитата(oson @  27.8.2012,  17:23 Найти цитируемый пост)
трудно контролировать то что генерируется на лету

А что там контролировать, когда знаешь что должно быть сгенерировано?


Цитата(oson @  27.8.2012,  17:23 Найти цитируемый пост)
 Трудно интегрировать с другими технологиями

Хм... Вот это с какой стороны посмотреть. На мой взгляд простая интеграция с Java технологиями и фреймворками и есть основное преимущество Grails над RoR, Django и темболее PHP-фреймворками. 

Автор: vogdb 19.9.2012, 18:26
Цитата(AntonSaburov @  27.8.2012,  18:48 Найти цитируемый пост)
Когда надо делать систему, которая данные получает из 15 мест разными технологиями и протоколами, когда таких вариантов также нужны разные мордочки для сайта (мобильный, андроид, толстый, тонкий и т.д. и т.п) - в такой ситуации Grails уже технологически предоставляет весьма малый выигрыш, а иногда там и проигрыш получается.

Разные мордочки для разных форматов запросов решаются очень просто за счет http://www.grails.org/doc/latest/guide/theWebLayer.html#contentNegotiation. Когда же нужно сделать что-то специальное, скажем для андроида, это тоже делается несложно. Вот http://fbflex.wordpress.com/2012/02/11/adding-mobile-views-to-your-grails-applications-with-jquery-mobile-a-real-life-example/.

Цитата(oson @  27.8.2012,  17:23 Найти цитируемый пост)
проблема с плагинами и их зависимостями, это не контролируется; 

Еще до 2.0 grails предлагал довольно приемлемую работу с зависимостями, в том числе с использованием maven. Начиная с 2.0 работа улучшилась на порядок, смотри http://www.grails.org/doc/latest/guide/conf.html#ivy. 

Цитата(oson @  27.8.2012,  17:23 Найти цитируемый пост)
 трудно отлавливать ошибки;

Проблема решается использованием Intellij Idea. Если ее нет, то да, дела с проверкой синтаксиса и ошибок компиляции плохи.

Цитата(oson @  27.8.2012,  17:23 Найти цитируемый пост)
трудно контролировать то что генерируется на лету;

Эм? То что кодируется руками? Честно говоря не уловил, что хотели сказать.

Цитата(oson @  27.8.2012,  17:23 Найти цитируемый пост)
Трудно интегрировать с другими технологиями

Как раз таки очень легко, так как встроена интеграция с ivy и maven репозиториями. Единственная опасность китайские и индусские плагины! Обычно здесь стараюсь брать готовые jar'ники и их использовать либо самому заниматься оборачиванием их в плагины.


Цитата(oson @  27.8.2012,  22:43 Найти цитируемый пост)
Какие то системы серьезные писали на нем - или только сайты-визитки?

Вот для стайтов-визиток как раз не советую его использовать. В целом, для сайтов не советую использовать, из-за того что сайт должен мало есть по месту, памяти и процессорному времени, что не относится к grails. Порталы - другое дело, а для сайтов оставайтесь на php, учитывая то, как он продвинулся в ООП, перейти на него с java будет несложно.

Из плюсов grails:
  •  Готовая инфраструктура для работы с web.
  •  Минимум синтаксического сахара для подключения и использования баз, библиотек, фильтров и много другого.
  •  Огромное количество готовых решений для работы с web. Кэш, обработка статики и много другое. Для примеру взять обработку статики. Java решения wro4j или jawr с их xml конфигами проигрывают по простоте и удобству resources плагину(Если надо могу расписать в деталях).
  •  Очень дружелюбное http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html
У меня очень хорошие впечатления от Grails. Все проблемы решались чтением документации/вопросами в сообществе. По мне так единственно нормальный java-based web framework для малых команд разработчиков.

Автор: fedotxxl 7.11.2012, 20:16
Напишу парочку своих мыслей по поводу Grails

Цитата

Проблема в том, что более крутой технологический пакет при сложной задаче не сильно влияет на производительность. Тот же EJB, SpringBean, Web-Service создаются достаточно быстро - само время их создания измеряется минутами. Но практически всегда возникает две проблемы:


В этом вы правы. Проблема совсем в другом - чистая Java/Spring создают слишком много "шумов" - вы открываете проект и видите аннотации, классы, анонимные классы, applicationContext.xml + все это чем-то собирается (maven? ant? а как подставлются настройки конфигурации? maven'ом? spring'ом?)...

Что дает Grails (в частности благодаря Groovy):
1. Меньше boilerplate кода. Меньше кода -> проще понимать (как правило)
2. Все проекты имеют общую структуру. Открываете новый проект и вы уже знаете: как запустить / где сервисы, домены, представления / где настроечные данные... 

Теперь о других преимуществах:
1. Обновление кода "на лету". Это killer feature. Обновили сервис/представление - посмотрели. Не надо пересобирать/перезапускать контейнер. Достигается кучей ухищрений, не всегда работает нормально, но работает. Это, конечно, не php, но и не java
2. Плагины. Когда мне что-то надо и я понимаю, что это достаточно популярная задача, я сначала ищу плагин. Конечно, некоторые из них шлак (например,  плагин scss), но это лучше чем ничего. + те плагины, которые пишутся самими разработчиками Grails просто супер (resources, например)
3. Groovy. Потратьте на этот язык один день... вы все поймете

Из недостатков:
1. Глюки при обновлении плагинов. Как что-то меняется в проекте (обновлются/добавлются/удаляются плагины) велика вероятность, что нужно будет чистить кеш и пересобирать заново... 
2. Документация для написания плагинов. Обычной документации хватает за глаза. Но вот если я хочу написать качественный плагин, мне нужно знать гораздо глубже как работает Grails. Здесь приходится копать самому
3. Hibernate. Grails построен на базе Spring и (в основном) Hibernate. Хотя GORM упрощает некоторые вещи, все при работе с БД постоянно возникают непонятки. Если мне нужно что-то более менее сложное от БД я сразу готовлюсь лезть в документацию по GORM / Hibernate
4. Интеграция с Maven'ом. Возможно, мне не повезло, но мне эта интеграция показалась сущим кошмаром (должны были поправить с 2.+ версии). Очень надеюсь на следующие версии + gradle

Если подводить итог: я люблю Grails и перебравшись на него со JAVA + Spring MVC стал намного счастливее  smile . По недостаткам - большая часть из них не существенна, 3 пункт - проблема не в Grails, а в Hibernate. 

Автор: zergi 10.11.2012, 13:05
fedotxxl, а я вот сделал несколько проектов на Grails, теперь вернулся на Spring MVC,  и снова счастлив )))

Автор: Akonkagva 12.3.2013, 00:46
Поменяли OSGi Felix на OSGi Grails и очень рады.

Автор: Vasay 15.3.2013, 00:19
На сайте Grails есть список сайтов сделаных с использованием Grails. 

Там есть проекты таких компаний, как Vodafone, Sky, Nokia, LinkedIn:
http://grails.org/websites?offset=0&max=12

Автор: Andrey1 18.3.2013, 14:24
На мой субъективный вкус использования Grails в течении месяца (и при двух решенных задачах на Grails), у Grails есть следующие минусы:
1) Groovy. Так как язык так и не стал самостоятельным, то отладка программ на groovy - дело не самое приятное.
2) Слишком сложная архитектура. Да, в теории все выглядит действительно красиво. А побеждает всегда, как правило, автомат калашникова: как только что-то идет не так, уже становится совсем не понятно, что делать с этой кучей мусора. smile
3) Низкая производительность и тяжесть фреймворка в итоге.
Все плюсы и плюшки тоже понятны:
1) Можно быстро
2) ... просто
3)... весело
4)...накидать простую систему управления данными в базе
5)...и допилить ее под свои требования.


Автор: Vasay 19.3.2013, 01:40
Andrey1


Цитата(Andrey1 @  18.3.2013,  14:24 Найти цитируемый пост)
1) Groovy. Так как язык так и не стал самостоятельным, то отладка программ на groovy - дело не самое приятное.


Это особенность всех динамических языков. Grails отличается от других web-фреймворков на динамических ЯП тем что написан по большей части на статической Java и позволяет использовать ее в проектах. В итоге мы можем использовать преимущества динамического ЯП там где это оправдано и избегать его там где он не нужен.



Цитата(Andrey1 @  18.3.2013,  14:24 Найти цитируемый пост)
Слишком сложная архитектура. Да, в теории все выглядит действительно красиво. А побеждает всегда, как правило, автомат калашникова: как только что-то идет не так, уже становится совсем не понятно, что делать с этой кучей мусора. 


Знание Java, Spring, Hibernate очень сильно помогают понимать "эту кучу мусора". Без опыта с Java в Grаils можно и утонуть...

Цитата(Andrey1 @  18.3.2013,  14:24 Найти цитируемый пост)
Низкая производительность и тяжесть фреймворка в итоге.

Это да... :-(

Автор: kkorsakoff 25.6.2013, 17:19
А производительность на чем конкретно проседает? Или в целом размазанно? groovy 2.0 на jdk7 чем-то помогает?
Тяжесть тоже в каком смысле имеется ввиду?

Автор: Vasay 28.6.2013, 17:49
Цитата(kkorsakoff @  25.6.2013,  17:19 Найти цитируемый пост)
Тяжесть тоже в каком смысле имеется ввиду?



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

Хотя, тут смотря с чем сравнивать...

Автор: MasterZiv 16.3.2014, 17:01
Цитата(oson @ 27.8.2012,  12:19)
Господа, не могу понять такой момент.
Если оценить возможности Grails с точки зрения ускорения работы, то тут просто гигантский потенциал.
...
С чем это связано? Есть какие-то недостатки, которые всплывают по ходу работы?

Дорогой oson, это всё связано с одним простым фактом, что 95% людей вокруг тебя -- идиоты.

И ситуация с Grails -- далеко не самая большая проблема, вызванная этим печальным фактом.

Автор: Сюзипуси 14.11.2015, 05:10
Я думаю много чего можно использовать эти программы

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)