Каковы основные недостатки 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?
Источник

13 ответов

Решение

Недостатки 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) является отсутствие области между запросом и областью сеанса, так называемая область диалога. Это заставляло разработчиков беспокоиться о скрытых элементах ввода, ненужных запросах к БД и / или злоупотреблении областью сеанса всякий раз, когда кто-то хочет сохранить исходные данные модели в последующем запросе, чтобы успешно обрабатывать проверки, преобразования, изменения модели и вызовы действий в более сложные веб-приложения. Боль можно смягчить, приняв стороннюю библиотеку, которая сохраняет необходимые данные в последующем запросе, например, MyFaces Tomahawk <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 и далее?

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

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

Несмотря на то, что практически все недостатки JSF 1.x были устранены, есть ошибки, специфичные для JSF 2.0, которые могут стать пробой. @ViewScoped происходит сбой в обработчиках тегов из-за проблемы куриного яйца при частичном сохранении состояния. Это исправлено в JSF 2.2 и перенесено в Mojarra 2.1.18. Также передача пользовательских атрибутов, таких как HTML5 data-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, то вы уже должны смотреть не на инфраструктуру MVC на основе компонентов, а на инфраструктуру MVC на основе запросов, такую ​​как Spring MVC. Вам нужно только принять во внимание, что вам придется писать все эти шаблоны HTML / CSS / JS самостоятельно. Смотрите также Разница между запросом MVC и компонентом 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)
  • зимовать
  • сваривать

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

  • 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 (или мы не смогли заставить его работать!). Вместо этого мы пытаемся использовать компонент простого интерфейса, но проверка клиента, похоже, не поддерживается и означает, что это не было стандартным потоком стандарта JSF.
  3. При использовании некоторых компонентов jQuery, таких как jqGird, и вам необходимо загрузить результаты JSON, вам рекомендуется использовать чистый сервлет. JSF ничего не сделает для вас. Поэтому, если вы используете такие компоненты, ваш дизайн не будет соответствовать JSF.
  4. Мы пытаемся сделать некоторые клиентские скрипты, когда AJAX завершает ajaxComplete и мы обнаружили, что PF 4 реализовал свои собственные события AJAX. У нас было несколько компонентов jQuery, и нам нужно изменить их код.

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

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

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

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

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

Источник

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

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

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

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

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

Источник

Для меня самый большой недостаток 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 ситуация должна быть лучше, по крайней мере, если речь идет о спецификации.

Источник

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

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

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

  • У вас есть пропускная способность, чтобы приспособиться к начальной кривой обучения?

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

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

Источник

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

Источник

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

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

Источник
Другие вопросы по тегам