Задать вопрос

Чем заменить JSF(primefaces)

Всем привет.
В трех своих последних проектах использовал primefaces, пришлось кастомизировать пару компонентов, но в целом все понравилось и писалось быстро и легко.
Хочется попробовать что нибудь новое, что бы на серверой стороне была java а на клиентской JS.
Но так что бы были как в JSF уже набор готовых компонентов.
  • Вопрос задан
  • 17399 просмотров
Подписаться 9 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 6
Просто не используйте JSF, JSP и прочие технологии рендеринга на стороне сервера. Это бесполезная трата времени.

Сейчас нет никаких проблем с реализацией всего, что нужно, на стороне клиента средствами одного из JS-фреймворков, таких как AngularJS например (см. single page web applications). В этом случае Java-backend превращается в RESTful-сервис.

Набор доступных компонентов в JavaScript заведомо богаче, а время на разработку экономится очень существенно.
Ответ написан
@bobzer
Java EE Developer
Работал с JSF пару лет на паре проектов, впечатления не из лучших. JSF красив только в примерах, типа написал десяток строчек — получил полнофункциональный интерфейс. Когда пишешь реальные приложения, вот так красиво можно разве что прототип накидать, когда же дело доходит до специфических рюшечек, да и просто сложной функциональности, все становится плохо. Код превращается в мешанину, в которой все спутано: логика размазана между страницами и серверными компонентами, на клиенте часть логики, на сервере — работа с интерфейсом. Сами страницы — гремучая смесь html/el/javascript и еще черт знает чего. Всегда надо помнить о цикле обработки JSF-страницы, чтобы, например, не читать из базы 7 раз одни и те же данные в момент обновления пары визуальных элементов на странице. Также надо держать в голове некие магические правила, при которых все работает, и не дай Бог применить неправильную комбинацию акшонов/онкликов/онкомплитов при которой все просто перестает работать, причем каких-либо возможностей нормального дебага не существует. Да, когда уже наработаны готовые рабочие решения, типа «если надо при закрытии диалога кроме выполнения акшона, еще обновить вон тот элемент, и сообщить тому бину что-то, то делается это ТАК», то основная часть работы делается без непонятных глюков. Но даже при этом, у меня лично, рисование каждой новой JSF-странички вызывает аллергию.

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

Насколько мне известно, Java в вебе в большинстве случаев применяется в корпоративных приложениях, имеющих ограниченное количество постоянных пользователей. Для таких случаев очень хорошо подходит GWT — писать на нем очень удобно, т.к. всё пишется на Java. Сгенерированный клиентский JavaScript весит обычно немало, но, загружается один раз, и лежит закешированный в браузере до следующего обновления вашего ПО. А все это время между клиентом и сервером ходят только чистые данные, и никаких html-оберток над ними. За счет такой экономии, за пару часов работы первоначальная загрузка большого JavaScript-а полностью компенсируется. GWT не очень подходит для обычных сайтов в Интернете, т.к. там пользователи обычно непостоянные (открыл страничку, посмотрел, ушел и не вернулся), и каждому загружать большой JavaScript затратно. В GWT есть готовый набор основных компонентов. Также есть фреймворки над GWT, предоставляющие более комплексные компоненты, но с ними вы опять вернетесь к истории с JSF — отлично работает и быстро разрабатывается только пока просто, потом начинается ступор, раскопки и научный тык.
Ответ написан
@Serious_Sem

Мы в текущем проекте используем Tapestry framework. Тоже компонентно-ориентированный, как и JSF. Имеет свою библиотеку tapestry-hibernate, так что можно работать прям из коробки. Своя реализация CDI. Поддержка JQuery: tapestry-Jquery-Components, Ajax и прочее. Очень хорошая документация, мгновенно-отвечающее комьюнити. Единственное, что после JSF может смущать - посроен tapestry не по jsr, так что аннотации не стандартные. Вобщем полистайте документацию, посмотрите пример, может и понравится.

Ответ написан
Losted
@Losted
Software Architect
Посмотрите wicket. Для внутренних проектов (а я подозреваю, что именно на таких вы и использовали JSF) подходит очень хорошо.
Ответ написан
Комментировать
Если обязательно нужен набор готовых компонентов - посмотрите в сторону ZK http://www.zkoss.org/zkdemo/getting_started?rfi=1 но учитывайте что его достаточно тяжело кастомизовать (привет jsf), однако обладает гибким механизмом байндингов и другими вкусными плюшками.
Ответ написан
Комментировать
@AlexSerov
В основе Wicket и Tapestry лежат очень здравые идеи компонентной ориентированности. Однако в HybridJava эти идеи реализованы гораздо чище.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы