Каковы основные недостатки Java Server Faces 2.0?

Вчера я видел презентацию о Java Server Faces 2.0, которая выглядела действительно впечатляюще, хотя я в настоящее время являюсь счастливым разработчиком ASP.NET MVC / jQuery. Что мне больше всего понравилось в JSF, так это огромное количество компонентов пользовательского интерфейса с поддержкой AJAX, которые, кажется, делают разработку намного быстрее, чем с ASP.NET MVC, особенно на сайтах с интенсивным использованием AJAX. Интеграционное тестирование тоже выглядело очень хорошо.

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

Итак, мои вопросы:

• Каковы основные недостатки Java Server Faces 2.0?
• Что может заставить разработчика JSF подумать об использовании ASP.NET MVC вместо JSF?

Недостатки JSF 2.0? Честно говоря, кроме сравнительно крутой кривой обучения, когда у вас нет глубоких базовых знаний об основах веб-разработки (HTML / CSS / JS, на стороне сервера и на стороне клиента и т. Д.) И базовом API сервлетов Java (запрос / ответ / сессия) переадресация / перенаправление и т. д.), никаких серьезных недостатков не приходит на ум. JSF в своем текущем выпуске все еще нуждается в том, чтобы избавиться от негативного имиджа, который он получил в ранние века, во время которого было несколько серьезных недостатков.

JSF 1.0 (март 2004 г.)

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

JSF 1.1 (май 2004 г.)

Это был релиз исправления. Производительность по-прежнему не сильно улучшилась. Был также один существенный недостаток: вы не можете безупречно встроить HTML на странице JSF. Весь простой ванильный HTML отображается перед деревом компонентов JSF. Вам нужно обернуть все простые ванили в <f:verbatim>теги, чтобы они были включены в дерево компонентов JSF. Хотя это было в соответствии со спецификацией, это получило много критики. См. Также JSF / Facelets: почему не стоит смешивать JSF / Facelets с тегами HTML?

JSF 1.2 (май 2006 г.)

Это был первый выпуск новой команды разработчиков JSF под руководством Райана Любке. Новая команда проделала огромную работу. Были также изменения в спецификации. Основным изменением было улучшение обработки представления. Это не только полностью отделило JSF от JSP, поэтому можно было использовать технологию представления, отличную от JSP, но и позволило разработчикам встроить простой ванильный HTML-код в страницу JSF без использования <f:verbatim>тегов. Еще одним важным направлением деятельности новой команды было повышение производительности. Во время жизненного цикла эталонной реализации Sun JSF 1.2 (под кодовым названием Mojarra начиная со сборки 1.2_08, около 2008 г.), практически каждая сборка поставлялась с (существенными) улучшениями производительности рядом с обычными (незначительными) исправлениями ошибок.

Единственный серьезный недостаток JSF 1.x (включая 1.2) - это отсутствие области между запросом и областью сеанса , так называемая область диалога . Это вынудило разработчиков беспокоиться о скрытых элементах ввода, ненужных запросах БД и / или злоупотреблении областью сеанса всякий раз, когда кто-то хочет сохранить исходные данные модели в последующем запросе, чтобы успешно обрабатывать проверки, преобразования, изменения модели и вызовы действий в более сложные веб-приложения. Боль можно смягчить, приняв стороннюю библиотеку, которая сохраняет необходимые данные в последующем запросе, такие как компонент ToFhawk MyFaces <t:saveState> , область диалога JBoss Seam и MyFaces Orchestra рамки разговора.

Еще один недостаток для пуристов HTML / CSS заключается в том, что JSF использует двоеточие в :качестве символа разделителя идентификаторов, чтобы обеспечить уникальность элемента HTML idв сгенерированном выводе HTML, особенно когда компонент повторно используется в представлении более одного раза (шаблоны, итерации компонентов и т. Д.) , Поскольку это недопустимый символ в идентификаторах CSS, вам нужно будет использовать \для экранирования двоеточия в селекторах CSS, что приведет к появлению уродливых и странно выглядящих селекторов, таких как #formId\:fieldId {}или даже #formId\3A fieldId {}. См. Также Как использовать сгенерированный JSF идентификатор элемента HTML с двоеточием ":" в селекторах CSS? Однако, если вы не пурист, читайте также По умолчанию JSF генерирует непригодные идентификаторы, которые несовместимы с CSS-частью веб-стандартов .

Кроме того, JSF 1.x не поставлялся с возможностями Ajax из коробки. На самом деле это не технический недостаток, но из-за шумихи над Web 2.0 в этот период он стал функциональным недостатком. Exadel рано представила Ajax4jsf, который был тщательно разработан в течение многих лет и стал основной частью библиотеки компонентов JBoss RichFaces . Другие библиотеки компонентов были также поставлены со встроенными возможностями Ajax, хорошо известной из которых является ICEfaces .

Примерно на полпути жизни JSF 1.2 была представлена ​​новая технология представления на основе XML: Facelets . Это дало огромные преимущества перед JSP, особенно в области шаблонов.

JSF 2.0 (июнь 2009 г.)

Это был второй основной релиз с Ajax в качестве модного слова. Было много технических и функциональных изменений. JSP заменена Facelets в качестве технологии представления по умолчанию, а Facelets была расширена за счет возможности создания пользовательских компонентов с использованием чистого XML (так называемые составные компоненты ). См. Также Почему Facelets предпочтительнее, чем JSP, как язык определения представления, начиная с JSF2.0 и далее?

Возможности Ajax были введены во вкус <f:ajax>компонента, который имеет много общего с Ajax4jsf. Аннотации и соглашения об изменении конфигурации были введены для максимально возможного уничтожения подробного faces-config.xmlфайла. Кроме того, символ разделителя идентификатора контейнера именования по умолчанию :стал настраиваемым, поэтому пуристы HTML / CSS могли дышать с облегчением. Все, что вам нужно сделать, это определить его init-paramв соответствии web.xmlс именем javax.faces.SEPARATOR_CHARи убедиться, что вы сами не используете этот символ в идентификаторах клиента, например -.

И последнее , но не в последнюю очередь, новая сфера была введена в вид рамки. Это устранило еще один существенный недостаток JSF 1.x, как описано выше. Вы просто объявляете bean-компонент @ViewScopedдля включения области диалога, не затрачивая все способы на сохранение данных в последующих (диалоговых) запросах. @ViewScopedФасоль будет жить до тех пор , пока вы впоследствии подачи и перемещения в ту же точку зрения (независимо от открытой вкладки браузера / окна!), Либо синхронно или асинхронно (Ajax). См. Также Разница между областью просмотра и запроса в управляемых bean-компонентах и Как правильно выбрать область действия bean-компонента?

Несмотря на то, что практически все недостатки JSF 1.x были устранены, есть ошибки, специфичные для JSF 2.0, которые могут стать пробоиной. @ViewScopedПроваливается в обработчиках тегов из -за проблемы с куриным яйцом в состоянии частичного сохранения. Это исправлено в JSF 2.2 и перенесено в Mojarra 2.1.18. Также передача пользовательских атрибутов, таких как HTML5data-xxx , не поддерживается. Это исправлено в JSF 2.2 с помощью новой функции прохождения элементов / атрибутов. В дальнейшем реализация JSF Mojarra имеет свой собственный набор проблем . Относительно многие из них связаны с иногда неинтуитивным поведением<ui:repeat> , новой реализацией частичного сохранения состояния и плохо реализованной областью флеш-памяти . Большинство из них исправлены в версии Mojarra 2.2.x.

Примерно во время JSF 2.0 была представлена PrimeFaces , основанная на jQuery и jQuery UI. Это стало самой популярной библиотекой компонентов JSF.

JSF 2.2 (май 2013 г.)

С введением JSF 2.2 HTML5 использовался в качестве модного слова, хотя технически это поддерживалось только во всех старых версиях JSF. См. Также JavaServer Faces 2.2 и поддержку HTML5, почему XHTML все еще используется . Наиболее важной новой функцией JSF 2.2 является поддержка пользовательских атрибутов компонентов, открывая тем самым целый мир возможностей, таких как настраиваемые группы таблиц без переключателей .

Помимо ошибок, связанных с реализацией, и некоторых «досадных мелочей», таких как невозможность внедрения EJB в валидатор / конвертер (уже исправленный в JSF 2.3), в спецификации JSF 2.2 нет серьезных недостатков.

MVC на основе компонентов и MVC на основе запросов

Некоторые могут предпочесть, что основным недостатком JSF является то, что он позволяет очень мало детализированного контроля над сгенерированным HTML / CSS / JS. Это не принадлежит JSF, просто потому, что это основанная на компонентах инфраструктура MVC, а не основанная на запросах (действиях) инфраструктура MVC. Если при рассмотрении фреймворка MVC вашим основным требованием является высокая степень контроля над HTML / CSS / JS, то вы должны уже не смотреть на фреймворк на основе компонентов, а на фреймворк на основе запросов, такой как Spring MVC . Вам нужно только принять во внимание, что вам придется писать все эти шаблоны HTML / CSS / JS самостоятельно. См. Также Разница между запросом MVC и компонентом MVC .

Смотрите также:

• В чем разница между JSF, Servlet и JSP? (просто чтобы понять основы)
• Использование JSF для разработки макетов CSS без таблиц (еще один миф о JSF)
• JSF против простого HTML / CSS / JS / jQuery (когда JSF - неправильный выбор)
• Шаблоны проектирования в веб-приложениях (иллюстрирует идеологию MVC)

После 5 лет работы с JSF я думаю, что смогу добавить свои 2 цента.

Два основных недостатка JSF :

1. Большая кривая обучения. JSF сложен, это просто правда.
2. Его составная природа. Фреймворк на основе компонентов пытается скрыть истинную природу сети, которая сопровождается огромным количеством осложнений и катастроф (например, отсутствие поддержки GET в JSF в течение почти 5 лет).
   ИМХО скрывать HTTP-запрос / ответ от разработчика - огромная ошибка. Исходя из моего опыта, каждая основанная на компонентах инфраструктура добавляет абстракцию к веб-разработке, и эта абстракция приводит к ненужным накладным расходам и более высокой сложности.

И мелкие недочеты, которые приходят мне в голову:

1. По умолчанию идентификатор объекта состоит из идентификаторов его родителей, например form1: button1.
2. Нет простого способа закомментировать неправильный фрагмент страницы. Тэгу <ui:remove>нужен синтаксически правильный контент, который все равно анализируется.
3. Компоненты низкого качества сторонних производителей, которые, например, не проверяют isRendered()внутренний processXxx()метод, прежде чем продолжить.
4. Включить LESS & Sencha сложно.
5. Не очень хорошо с REST.
6. Не так просто для UX-дизайнеров, потому что готовые компоненты имеют свои собственные стили CSS, которые необходимо перезаписать.

Не пойми меня неправильно. Как фреймворк для компонентов JSF в версии 2 действительно хорош, но он все еще основан на компонентах и ​​всегда будет ...

Пожалуйста, обратите внимание на низкую популярность Tapestry, Wicket и низкий энтузиазм опытных разработчиков JSF (что еще более значимо). И для контраста взгляните на успех Rails, Grails, Django, Play! Фреймворк - все они основаны на действиях и не пытаются скрыть от программиста истинный запрос / ответ и не имеющую состояния сеть.

Для меня это главный недостаток JSF. IMHO JSF может подойти для некоторых типов приложений (интрасеть, интенсивные формы), но для реальных веб- приложений это не очень хороший способ.

Надеюсь, что это помогает кому-то с его / ее выбором, касающимся внешнего интерфейса.

Несколько недостатков, которые приходят на ум:

1. JSF - это компонентная структура. Это имеет внутренние ограничения, связанные с подчинением компонентной модели.
2. AFAIK JSF поддерживает только POST, поэтому, если вы хотите где-то получить GET, вам нужно сделать простой сервлет / JSP.
3. Большинство компонентов пытаются предоставить абстракции над доменами, такими как реляционные базы данных и интерфейсный JavaScript, и часто эти абстракции являются «утечками» и их очень сложно отлаживать.
4. Эти абстракции могут быть хорошей отправной точкой для начинающего разработчика или кого-то, кто не знаком с конкретным доменом (например, интерфейсный JavaScript), но его очень сложно оптимизировать для повышения производительности, так как задействовано несколько уровней, и большинство людей, которые их используют Я мало понимаю, что происходит под капотом.
5. Механизмы шаблонов, которые обычно используются с JSF, не имеют ничего общего с тем, как работают веб-дизайнеры. Редакторы WYSIWYG для JSF примитивны, и в любом случае ваш дизайнер предоставит вам HTML / CSS, который вам придется потратить на конвертацию целую вечность.
6. Такие вещи, как выражения EL, не проверяются статически, и компилятор, и IDE плохо справляются с поиском ошибок, так что вы получите ошибки, которые вам придется обнаруживать во время выполнения. Это может быть хорошо для динамически типизируемого языка, такого как Ruby или PHP, но если мне нужно противостоять явному раздутию экосистемы Java, я требую печатать для своих шаблонов.

Подводя итог: время, которое вы сэкономите с помощью JSF, не тратя времени на написание шаблонного кода JSP / servlet / bean, вы потратите на это x10, чтобы его масштабировать и делать именно то, что вы хотите.

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

• HTML в разных воплощениях. Не притворяйся, что тебе не нужно это знать.
• HTTP - когда вы не можете понять, что происходит, вы должны открыть Firebug и посмотреть. Для этого вам нужно знать это.
• CSS - нравится это или нет. Это не так уж и плохо, и есть, по крайней мере, несколько хороших инструментов.
• XML - JSF, вероятно, будет первым местом, где вы будете использовать пространства имен до такой степени.
• Сервлет Технические характеристики. Рано или поздно вы попадете в методы вызова в этом пакете. Кроме того, вы должны знать, как ваши Facelets превращаются в XHTML или что-то еще.
• JSP (в основном, чтобы вы знали, почему он вам не нужен в JSF)
• JSTL (опять же, в основном, чтобы справиться с устаревшей структурой)
• Язык выражения (EL) в его различных формах.
• ECMAScript, JavaScript, или как вы еще хотите это называть.
• JSON - вы должны знать это, даже если вы не используете его.
• AJAX. Я бы сказал, что JSF 2.0 неплохо скрывает это от вас, но вам все равно нужно знать, что происходит.
• ДОМ. И как браузер использует это. Смотрите ECMAScript.
• DOM Events - тема сама по себе.
• Java Persistence Architecture (JPA), то есть если вы хотите, чтобы ваше приложение имело какую-либо внутреннюю базу данных.
• Сама Ява.
• JSEE, пока вы на это.
• Спецификация внедрения зависимостей контекста (CDI) и ее конфликты с JSF 2.0 и его использование
• JQuery - я бы хотел, чтобы вы обходились без этого.

Теперь, как только вы закончите с этим, вы можете приступить к проприетарным спецификациям, а именно к библиотекам компонентов и библиотекам провайдеров, которые вы подберете по пути:

• PrimeFaces (моя библиотека компонентов по выбору)
• RichFaces
• MyFaces
• ICEfaces
• EclipseLink (мой поставщик JPA)
• Hibernate
• сваривать

И не забудь контейнер! И все эти файлы конфигурации:

• GlassFish (2, 3 и т. Д.)
• JBoss
• Кот

Так что - ЭТО ЛЕГКО? Несомненно, JSF 2.0 «прост», если все, что вам нужно, это самые простые веб-страницы с простейшими взаимодействиями.

Проще говоря, JSF 2.0 - это самая сложная и громоздкая путаница склеенных технологий, которая существует сегодня во вселенной программного обеспечения. И я не могу придумать ничего, что я бы предпочел использовать.

1. Неопытные разработчики обычно создают приложения, которые мучительно медленны, а код будет очень уродливым и сложным в обслуживании. Его обманчиво просто начать, но на самом деле он требует определенных вложений в обучение, если вы хотите писать хорошие программы.
2. По крайней мере, на старте вы часто «застреваете» на какой-то проблеме и тратите больше времени на чтение сообщений в интернете, чем на работу :) Через какое-то время это будет все меньше и меньше, но все равно может раздражать.
3. Еще больше раздражает, когда вы обнаруживаете, что проблема не в том, что у вас нет знаний / ошибок, а на самом деле ошибка. Мохарра была (есть?) Довольно глючной, а другой слой компонентов добавляет еще больше проблем. Richfaces был самой большой частью программного обеспечения для дерьма, когда-либо написанного :) Не знаю, как сейчас на версии 4. У нас есть Primefaces, который лучше, но все же вы столкнетесь с ошибками или отсутствием функций, особенно с более экзотическими компонентами. И теперь вам нужно будет оплатить обновления Primefaces. Так что я бы сказал, что он глючит, но становится лучше, особенно после того, как версия 2.2 исправила некоторые проблемы со спецификацией. Фреймворк становится более зрелым, но все еще далеким от совершенства (может быть, мои лица лучше?).
4. Я не нахожу это особенно гибким. Часто, если вам нужно что-то очень индивидуальное и нет компонентов, которые это делают, это будет немного болезненно. Опять же, я говорю со средней точки зрения разработчика - с крайними сроками, краткими учебными пособиями и поиском стекового потока, когда застряли, потому что нет времени, чтобы узнать, как это работает на самом деле :) Часто некоторые компоненты, кажется, "почти" то, что вам нужно, но не совсем, и иногда вы можете потратить слишком много времени, чтобы заставить его делать то, что вы хотите :) Нужно быть осторожным в оценке, лучше ли создать свой собственный или мучить существующий компонент. На самом деле, если вы создаете что-то действительно уникальное, я бы не рекомендовал JSF.

Короче говоря, мои недостатки: сложность, не очень плавный прогресс в разработке, глючность, негибкость.

Конечно, есть и преимущества, но это не то, что вы просили. В любом случае, это мой опыт работы с фреймворком. У других могут быть разные мнения, так что лучше всего на некоторое время попробовать его, чтобы увидеть, подходит ли он вам (просто что-то более сложное - не наивные примеры - JSF действительно блестит там :) ИМХО лучший вариант использования для JSF - это бизнес-приложения, такие как CRM и т. Д.

«JSF будет выводить HTML и JavaScript уровня представления, которые вы не можете контролировать или изменять, не вдаваясь в код контроллера».

На самом деле JSF дает вам гибкость, вы можете использовать стандартные / сторонние компоненты или создавать свои собственные, которые вы имеете полный контроль над тем, что отображается. Это всего лишь один HTML-файл, необходимый для создания пользовательских компонентов в JSF 2.0.

Я вообще не эксперт по Java Server Faces. Но ИМХО главный недостаток в том, что это серверная сторона. Я устал от изучения и использования серверных фреймворков уровня веб-презентации, таких как ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, php-фреймворки и ruby-on-rails. Я попрощался со всеми из них и поздоровался с Angularjs и TypeScript. Мой уровень презентации работает в браузере. Мне не важно, обслуживается ли он Windows IIS под управлением php или ASP.NET или веб-сервер Apache под управлением Linux. Мне просто нужно изучить только одну структуру, которая работает везде.

Просто мои два цента.

Мы разработали пример проекта с JSF (это было трехнедельное исследование, поэтому мы могли потерять некоторые вещи!)

Мы пытаемся использовать ядро ​​jsf, если нужен компонент, мы использовали PrimeFaces.

Проект представлял собой веб-сайт с навигацией. Каждая страница должна быть загружена через ajax при нажатии на меню.

На сайте есть два варианта использования:

1. Страница с сеткой. Сетка загружается через ajax и должна поддерживать сортировку и подкачку
2. Трехшаговая страница мастера. Каждая страница имеет проверку на стороне клиента (для простых проверок) и проверку базы ajax на стороне сервера (для сложных проверок). Любое исключение сервера (из сервисного уровня) должно отображаться на той же странице мастера, без перехода на следующую страницу.

Мы нашли это:

1. Вам нужно использовать некоторые хаки из omniFaces, чтобы исправить состояние представления JSF. Состояние JSF будет повреждено, если вы включите страницы через ajax друг в друга. Это кажется ошибкой в ​​JSF и может быть исправлено в следующих выпусках (не в 2.3).
2. Поток JSF некорректно работает с ajax (или мы не смогли заставить его работать!). Вместо этого мы пытаемся использовать простой компонент wizard, но проверка клиента, похоже, не поддерживается и означает, что он не был стандартным стандартом потока JSF.
3. При использовании некоторых компонентов jQuery, таких как jqGird, и вам необходимо загрузить результаты JSON, вам рекомендуется использовать чистый сервлет. JSF ничего не сделает для вас. Поэтому, если вы используете такие компоненты, ваш дизайн не будет соответствовать JSF.
4. Мы пытаемся выполнить некоторые клиентские сценарии, когда ajax завершается, ajaxCompleteи мы обнаружили, что PF 4 реализовал свои собственные события ajax. У нас было несколько компонентов jQuery, и нам нужно изменить их код.

Если вы измените приведенный выше пример на не Ajax проект (или, по крайней мере, на меньший Ajax-проект), вы не столкнетесь с множеством вышеуказанных проблем.

Мы суммируем наше исследование как:

JSF плохо работает на полностью базовом веб-сайте ajax.

Конечно, в JSF есть много полезных функций, которые могут быть очень полезны в некоторых проектах, поэтому примите во внимание потребности вашего проекта.

Пожалуйста, обратитесь к технической документации JSF для ознакомления с преимуществами JSF, и, на мой взгляд, самое большое преимущество JSF - это полная и огромная поддержка @BalusC ;-)

Для меня самый большой недостаток JSF - плохая поддержка программно (динамически) сгенерированных страниц.
Если вы хотите построить свою страницу (создать компонентную модель страницы) динамически из Java-кода. Например, если вы работаете над конструктором веб-страниц WYSIWYG. Адекватная документация по этому варианту использования не всегда доступна. Есть много моментов, когда вы должны экспериментировать, и разработка идет медленно. Многие вещи не работают так, как вы ожидаете. Но, как правило, его можно как-то взломать.
Хорошо, что это не проблема философии или архитектуры JSF. Это просто недостаточно проработано (насколько я знаю).

JSF 2 предоставил составные компоненты, которые должны упростить разработку компонентов, но их поддержка динамического (программного) построения очень плохая. Если вы преодолеете сложный и почти недокументированный процесс создания динамического Composite Component, вы обнаружите, что если вы вложите несколько Composite компонентов немного глубже, они перестанут работать, что вызовет некоторые исключения.

Но похоже, что сообщество JSF знает об этих недостатках. Они работают над этим, как вы можете видеть из этих двух ошибок
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

С JSF 2.2 ситуация должна быть лучше, по крайней мере, если речь идет о спецификации.

Комментируя мои последние несколько месяцев опыта работы с Primefaces / JSF:

• Если вы можете использовать компоненты "с полки", я думаю, это не страшно.
• Тем не менее, он не играет хорошо, как только вы выходите на улицу и нуждаетесь в пользовательских интерфейсах. - Например, нам нужно было использовать загрузчик Twitter для нашего проекта. (Не простые начальные загрузки).
  • Теперь наши страницы работают следующим образом:
    • Страница загружается.
    • Пользователь взаимодействует с Primefaces, который имеет функциональность ajax
    • Разрывы привязок javascript в Bootstrap
    • Мы запускаем дополнительный JavaScript, чтобы перепривязать все

Обещание JSF избежать написания javascript превратилось в написание большего количества javascript, чем было бы, если бы мы не использовали Primefaces - и этот javascript должен исправить то, что ломается Primefaces.

Это временная трата - если только вы снова не используете "готовые" вещи. Также очень некрасиво (Primefaces), когда приходится работать с Selenium. Все это может быть сделано - но опять же - есть только так много времени.

Определенно избегайте этого, если вы работаете с UX / командой разработчиков и вам нужно быстро итерировать интерфейс - вы можете сэкономить время, изучая jquery / писать прямой HTML - или рассматривая реакцию / угловатый.

У JSF есть много преимуществ, а вопрос в невыгодном положении, позвольте мне добавить пару моментов.

В практическом сценарии реализации веб-проекта с указанием временных рамок необходимо следить за следующими факторами.

• Достаточно ли в вашей команде старших членов, которые могут предложить лучшие средства управления, подходящие для каждого сценария?

• Есть ли у вас пропускная способность для размещения начальной кривой обучения?

• Достаточно ли у вас опыта в вашей команде, которая может анализировать
  материалы JSF , разработанные разработчиками?

Если вы ответили «Нет» на вопросы, вы можете оказаться в не поддерживаемой кодовой базе.

У JSF есть только один недостаток: перед началом разработки "JSF" вы должны четко понимать веб-разработку, ядро ​​Java и интерфейсную архитектуру.

В настоящее время "новые" JavaScript-фреймворки просто пытаются скопировать / вставить модель на основе компонентов JSF.

Среди всех «основных» сред, таких как Spring MVC, Wicket, Tapestry и т. Д., JSF Java EE с его составными компонентами является наиболее сложной из представленных на уровне представления и ориентированной на компоненты технологий. Это немного громоздко и неполно по сравнению с решениями, предоставляемыми HybridJava.