Які основні недоліки 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. Хоча це було відповідно до специфікації, це зазнало багато критики. Дивіться також ao JSF / Facelets: чому не годиться змішувати JSF / Facelets з тегами HTML?

JSF 1.2 (травень 2006 р.)

Це був перший випуск нової команди з розробки JSF під керівництвом Райана Любке. Нова команда зробила багато великої роботи. Були також зміни в специфікації. Основна зміна полягала в покращенні режиму подання поглядів. Це не тільки повністю відокремило JSF від JSP, тому можна було використовувати іншу технологію перегляду, ніж JSP, але це також дозволило розробникам вводити звичайний HTML ванілі на сторінку JSF без клопоту з <f:verbatim>тегами. Ще одним основним напрямком роботи нової команди було підвищення продуктивності. Протягом життя Sun JSF Reference Implementation 1.2 (кодований під кодовою назвою Mojarra з моменту створення 1.2_08, близько 2008 р.) Практично кожна збірка отримувала (основні) поліпшення продуктивності поруч із звичайними (незначними) помилками.

Єдиним серйозним недоліком JxF 1.x (включаючи 1.2) є відсутність області між запитом та областю сеансу , так званої області розмови . Це змусило розробників клопотатись із прихованими елементами введення, непотрібними запитами БД та / або зловживати областю сеансу, коли хочеться зберегти вихідні дані моделі в наступному запиті, щоб успішно обробляти перевірки, перетворення, зміни моделі та виклики дій. складні можливості застосування. Біль можна пом'якшити, прийнявши сторонню бібліотеку, яка зберігає необхідні дані в наступному запиті, як компонент MyFaces Tomahawk <t:saveState> , сфера розмови JBoss Seam та оркестр MyFaces рамки для розмови

Ще одним недоліком для пуристів 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 (так звані складові компоненти ). Дивіться також Чому фейлетки віддається перевазі JSP як мови визначення перегляду від JSF2.0 далі?

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

І останнє, але не менш важливе, було запроваджено нову сферу, область перегляду . Він усунув ще один головний недолік JSF 1.x, як описано раніше. Ви просто задекларуєте боб, @ViewScopedщоб увімкнути область розмови, не намагаючись зберегти всі дані в наступних (розмовних) запитах. @ViewScopedКвасоля буде жити до тих пір , поки ви згодом подачі і переміщення в ту ж точку зору (незалежно від відкритої вкладки браузера / вікна!), Або синхронно або асинхронно (Ajax). Дивіться також Різниця між переглядом та запитом в області керованої квасолі та Як вибрати правильну область бобів?

Хоча практично всі недоліки JSF 1.x були усунені, є специфічні помилки JSF 2.0, які можуть стати шоустоппером. @ViewScopedПровалюється в обробниках тегів з -за проблеми з курячим яйцем в стані часткового збереження. Це зафіксовано в JSF 2.2 та підтримується в Mojarra 2.1.18. Також не підтримуються власні атрибути, такі як HTML5data-xxx . Це зафіксовано в JSF 2.2 за допомогою нових функцій / атрибутів для найпростіших програм. Далі впровадження СФП у «Монарра» має власний набір питань . Відносно багато з них пов'язані з іноді неінтуїтивною поведінкою<ui:repeat> , новою частковою реалізацією збереження стану та погано реалізованою областю спалаху . Більшість із них зафіксовані у версії Mojarra 2.2.x.

Приблизно у часі JSF 2.0 було представлено PrimeFaces на основі інтерфейсу jQuery та jQuery. Він став найпопулярнішою бібліотекою компонентів 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- основі, що базується на запиті (дії) . Якщо високий ступінь контролю HTML / CSS / JS є вашою основною вимогою при розгляді MVC-рамки, тоді ви вже не повинні дивитися на компонентний MVC-фреймворк, а на базу MVC, який базується на запиті, як Spring MVC . Вам потрібно лише взяти до уваги, що вам доведеться самостійно писати всі ці кодові шаблони HTML / CSS / JS. Див. Також Різниця між запитом MVC та компонентним MVC .

Дивитися також:

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

Після 5 років роботи з JSF я думаю, що можу додати свої 2 центи.

Два основних недоліки JSF :

1. Велика крива навчання. JSF складний, це просто так.
2. Її складова природа. Компонентна основа намагається приховати справжню природу Інтернету, яка спричиняє величезну кількість ускладнень та катастроф (як, наприклад, не підтримка GET в JSF протягом майже 5 років).
   IMHO приховує запит / відповідь HTTP від ​​розробника - величезна помилка. З мого досвіду, кожен компонент, що базується на компонентах, додає абстрагуванню веб-розробці, і ця абстракція призводить до зайвих витрат і більшої складності.

І незначні недоліки, які мені спадають на думку:

1. За замовчуванням ідентифікатор об'єкта складається з ідентифікаторів його батьків, наприклад form1: button1.
2. Непростий спосіб коментувати неправильний фрагмент сторінки. Тегу <ui:remove>потрібен синтаксично правильний вміст, який так чи інакше розбирається.
3. Низькі якості сторонніх компонентів, які, наприклад, не перевіряють isRendered()всередині processXxx()методу, перш ніж продовжувати.
4. Включити МЕНШЕ та Сенчу важко.
5. Не грає добре з REST.
6. Для дизайнерів UX це не так просто, адже готові до використання компоненти мають свої стилі CSS, які потрібно перезаписати.

Не зрозумій мене неправильно. Як компонентний фреймворк JSF у версії 2 справді хороший, але він все ще базується на компонентах і завжди буде ...

Погляньте, будь ласка, на низьку популярність гобелену, калитки та низький ентузіазм досвідчених розробників JSF (що ще більше значення). А на противагу, подивіться на успіх Rails, Grails, Django, Play! Рамка - всі вони засновані на дії та не намагаються сховатися від програміста справжній запит / відповідь та безмежжя в Інтернеті.

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

Сподіваюся, це допомагає комусь із його / її вибором, що стосується передового.

Кілька недоліків, які виникають на увазі:

1. JSF - це компонентна основа. Це має притаманні обмеження, пов'язані з дотриманням компонентної моделі.
2. AFAIK JSF підтримує лише POST, тому якщо ви хочете десь отримати, вам потрібно зробити звичайний сервлет / 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 - тема сама по собі.
• Архітектура стійкості Java (JPA), тобто якщо ви хочете, щоб ваша програма мала будь-яку базу даних.
• Сама Java.
• 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. Ще більше дратує, коли дізнаєшся, що проблема пов’язана не з відсутністю знань / помилок, а насправді з помилками. Mojarra була (є?) Досить гнучкою, а ще один шар компонентів додає ще більше проблем. Річфайти - це найбільша частина програмного забезпечення для лайна, що коли-небудь написана :) Не знаю, як це зараз у версії 4. У нас є Primefaces, що краще, але все ж ви зіткнетеся з помилками чи відсутністю функцій, особливо з більш екзотичними компонентами. А тепер вам потрібно буде заплатити за оновлення Primefaces. Тому я б сказав, що його баггі, але його покращення, особливо після версії 2.2, вирішив деякі проблеми з специфікацією. Рамка стає більш зрілою, але все ще далеко не ідеальною (можливо, мої інтерфейси краще?).
4. Я не вважаю це особливо гнучким. Часто, якщо вам потрібно щось дуже налаштоване, і немає компонентів, які це роблять - це буде трохи боляче. Знову я говорю з точки зору середнього розробника - того, у кого терміни, швидкі підручники з читання та пошук stackoverflow, коли застрягаєте, оскільки немає часу, щоб дізнатися, як це насправді працює :) Часто, здається, деякі компоненти мають "майже" те, що вам потрібно, але Не точно, а іноді ви можете витратити занадто багато часу, щоб змусити робити щось, що хочете :) Потрібно бути обережним в оцінці, чи краще створити свій власний компонент або катувати його. Насправді, якщо ви створюєте щось справді унікальне, я б не рекомендував JSF.

Тому коротко моїми недоліками були б: Складність, Не дуже плавний прогрес розвитку, глючно, негнучко.

Звичайно, є і переваги, але це не те, що ви просили. У будь-якому випадку, це мій досвід роботи з рамками інших, можливо, мають різні думки, тому найкращим способом є просто спробувати його на деякий час, щоб побачити, чи це для вас (просто щось складніше - не наївні приклади - JSF справді світить там :) IMHO найкраще використовувати для JSF - це бізнес-додатки, такі як CRM тощо.

"JSF виведе HTML та JavaScript на рівні перегляду, які ви не можете керувати чи змінювати, не входячи в код контролера."

Насправді JSF дає вам гнучкість, ви можете або використовувати стандартні / сторонні компоненти, або створити свій власний, який маєте повний контроль над тим, що надається. Це лише один xhtml, який вам потрібен для створення власних компонентів за допомогою JSF 2.0.

Я взагалі не фахівець з Java Server Faces. Але головним недоліком ІМХО є те, що це сторона сервера. Мені набридло навчатися та використовувати рамки шару веб-презентації на стороні сервера, такі як ASP.NET Web Forms, ASP.NET MVC, обличчя Java Server, сторкти, php фреймворки та рубін на рейкових рамах. Я попрощався з усіма ними, і я привітався з Angularjs і TypeScript. Мій шар презентації працює в браузері. Неважливо, чи обслуговується він Windows IIS під керуванням php або ASP.NET, чи він обслуговується веб-сервером Apache під управлінням Linux. Мені просто потрібно вивчити лише одну основу, яка працює всюди.

Всього два мої копійки.

Ми розробили зразок проекту з JSF (Це було тритижневе дослідження, тому ми, можливо, втратили щось!)

Ми намагаємось використовувати core jsf, якщо потрібен компонент, ми використовували PrimeFaces.

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

На сайті є два випадки використання:

1. Сторінка з сіткою. Сітка завантажується через ajax і повинна підтримувати сортування та пейджинг
2. Сторінка майстра три кроки. Кожна сторінка має перевірку на стороні клієнта (для простих перевірок) та перевірку базової версії ajax на стороні сервера (для складної перевірки). Будь-який виняток із сервера (із сервісного рівня) повинен відображатися на одній сторінці майстра, не переходячи до наступної сторінки.

Ми виявили, що:

1. Щоб виправити стан перегляду JSF, вам потрібно використовувати кілька хаків від omniFaces. Стан JSF буде пошкоджений, якщо ви додасте сторінки через ajax один в одного. Це здається помилкою в JSF і може бути виправлено в наступних випусках (не в 2.3).
2. JSF Flow не працює належним чином з ajax (або ми не можемо змусити його працювати!) Ми намагаємось замість цього використовувати компонент майстра прайм-версій, але перевірка клієнта, здається, не підтримується і означає, поки це не було стандартним стандартом потоку 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 трохи глибше, вони перестануть працювати, кидаючи деякі винятки.

Але, схоже, спільнота 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 та front-end архітектуру.

Нині "нові" рамки JavaScript просто намагаються скопіювати / вставити модель на базі компонентів "JSF".

Серед усіх "основних" каркасів, таких як Spring MVC, Wicket, Tapestry тощо., JSF Java EE з його складовими компонентами є найбільш розробленою технологією на рівні презентації та орієнтованою на компоненти. Це трохи громіздко і неповно в порівнянні з рішеннями, наданими HybridJava.