web-dev-qa-db-ja.com

Java Server Faces 2.0の主な欠点は何ですか？

昨日、Java Server Faces 2.0のプレゼンテーションを見ましたが、私は現在幸せなASP.NET MVC/jQuery開発者ですが、本当に印象的でした。 JSFで最も気に入ったのは、AJAX対応のUIコンポーネントが大量にあることで、特にAJAXが多いサイトでは、ASP.NET MVCを使用するよりもはるかに高速に開発できるようです。統合テストも非常に良さそうでした。

プレゼンテーションではJSFの利点のみを強調したため、反対側についても聞きたいと思います。

だから私の質問は：

  • Java Server Faces 2.0の主な欠点は何ですか？
  • JSF開発者がJSFの代わりにASP.NET MVCを使用することを検討する理由は何ですか？
asp.net-mvcjsfjsf-2
230
Adrian Grigore

JSF 2.0の欠点は？正直なところ、 基本的なWeb開発 （HTML/CSS/JS、サーバー側とクライアント側など）に関する強固な背景知識がない場合の比較的急な学習曲線は別として、 basic Java Servlet API （要求/応答/セッション、転送/リダイレクトなど）、深刻な欠点はありません。現在のリリースのJSFは、いくつかの重大な欠点があった初期の時代に得たネガティブなイメージを取り除く必要があります。

JSF 1.0（2004年3月）

これが最初のリリースです。知りたくないコア領域とパフォーマンス領域の両方にバグが散らばっていました。あなたのウェブアプリケーションは、あなたが直感的に期待するように常に機能しませんでした。開発者としてのあなたは泣き叫びます。

JSF 1.1（2004年5月）

これはバグ修正リリースでした。パフォーマンスはまだあまり改善されていません。また、大きな欠点が1つありました。JSFページにHTMLを完璧にインライン化できないことです。すべての単純なVanilla HTMLがレンダリングされますbefore JSFコンポーネントツリー。すべてのプレーンバニラを<f:verbatim>タグでラップして、JSFコンポーネントツリーに含まれるようにする必要があります。これは仕様どおりでしたが、多くの批判を受けています。 a.oも参照してください。 JSF/Facelets：なぜJSF/FaceletsとHTMLタグを混在させるのが良い考えではないのですか？

JSF 1.2（2006年5月）

これは、Ryan Lubke率いる新しいJSF開発チームの最初のリリースでした。新しいチームは多くのすばらしい仕事をしました。仕様にも変更がありました。主な変更点は、ビューの処理の改善です。これは、JSFからJSFを完全に切り離すだけでなく、JSPとは異なるビューテクノロジーを使用できるだけでなく、開発者が<f:verbatim>タグを使用せずにJSFページにプレーンなVanilla HTMLをインライン化できるようにします。新しいチームのもう1つの主な焦点は、パフォーマンスの改善でした。 Sun JSF Reference Implementation 1.2（コード名Mojarraビルド1.2_08以降、2008年頃）の存続期間中、実質的にすべてのビルドに、通常の（マイナーな）バグ修正の次に（主要な）パフォーマンスの改善が加えられました。 。

JSF 1.x（1.2を含む）の唯一の重大な欠点は、requestとsessionスコープの間にスコープがないことです。いわゆる会話スコープ。これにより、開発者は、検証、変換、モデルの変更、アクションの呼び出しを正常に処理するために、後続のリクエストで初期モデルデータを保持したい場合に、非表示の入力要素、不要なDBクエリ、セッションスコープの悪用を余儀なくされました複雑なWebアプリケーション。 MyFaces Tomahawk<t:saveState> component、 JBoss Seam のような後続のリクエストで必要なデータを保持するサードパーティライブラリを採用することで、痛みを和らげることができます。会話スコープと MyFaces Orchestra 会話フレームワーク。

HTML/CSS純粋主義者のもう1つの欠点は、JSFがID区切り文字としてコロン:を使用して、生成されたHTML出力でHTML要素idの一意性を確保することです。特に、ビューでコンポーネントが複数回再利用される場合（テンプレート、等）。これはCSS識別子では不正な文字であるため、\を使用してCSSセレクターでコロンをエスケープする必要があり、その結果、#formId\:fieldId {}や#formId\3A fieldId {}のような見苦しくて奇妙なセレクターになります。 CSSセレクタでコロン「：」を含むJSF生成HTML要素IDを使用する方法も参照してください。 ただし、純粋主義者でない場合は、デフォルトで も参照してください、JSFは使用できないIDを生成しますが、これはWeb標準 のCSS部分とは互換性がありません。

また、JSF 1.xにはAjax機能がすぐに搭載されていませんでした。技術的には不利ではありませんが、その期間中にWeb 2.0が誇大宣伝されたため、機能的に不利になりました。 Exadel は、長年にわたって徹底的に開発され、 JBoss RichFaces コンポーネントライブラリの中核部分となったAjax4jsfを導入する初期段階でした。別のコンポーネントライブラリもビルトインAjaxパワーとともに出荷されました。よく知られているものは ICEfaces です。

JSF 1.2のライフタイムのほぼ半分で、新しいXMLベースのビューテクノロジー Facelets が導入されました。これにより、特にテンプレートの分野で、JSPよりも大きな利点が得られました。

JSF 2.0（2009年6月）

これは2番目のメジャーリリースで、Ajaxを流行語として使用しました。多くの技術的および機能的な変更がありました。 JSPはデフォルトのビューテクノロジーとしてFaceletsに置き換えられ、Faceletsは純粋なXMLを使用してカスタムコンポーネントを作成する機能（いわゆる composite components ）で拡張されました。 JSF2.0以降のビュー定義言語としてJSPよりもFaceletsが推奨される理由/ も参照してください。

Ajaxパワーは、Ajax4jsfと多くの類似点を持つ<f:ajax>コンポーネントのフレーバーで導入されました。 kill 冗長なfaces-config.xmlファイルに、可能な限りアノテーションと設定の規約の強化が導入されました。また、デフォルトの命名コンテナID区切り文字:が構成可能になったため、HTML/CSSの純粋主義者は安心できました。必要なことは、init-paramでweb.xmlのjavax.faces.SEPARATOR_CHARとして名前を定義し、-などのクライアントIDのどこでも自分で文字を使用しないようにすることです。

最後になりましたが、新しいスコープ、viewスコープが導入されました。前述のように、JSF 1.xのもう1つの大きな欠点を取り除きました。 Bean @ViewScopedを宣言するだけで、後続の（会話型）リクエストでデータを保持するすべての方法に煩わされることなく、会話スコープを有効にします。 @ViewScoped Beanは、同期して、または非同期で（Ajax）のいずれかで（開いているブラウザーのタブ/ウィンドウとは無関係に）同じビューに送信してナビゲートしている限り有効です。 マネージドBeanのViewスコープとRequestスコープの違い および 正しい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の時代には、jQueryとjQuery UIに基づいて PrimeFaces が導入されました。最も人気のあるJSFコンポーネントライブラリになりました。

JSF 2.2（2013年5月）

JSF 2.2の導入により、HTML5は技術的にはすべての古いJSFバージョンでサポートされていたにもかかわらず、流行語として使用されました。 JavaServer Faces 2.2およびHTML5サポートもご覧ください。なぜXHTMLがまだ使用されているのか 。最も重要な新しいJSF 2.2機能は、カスタムコンポーネント属性のサポートです。これにより、 カスタムテーブルレスラジオボタングループ などの可能性の世界が開かれます。

実装固有のバグや、バリデーター/コンバーター（すでにJSF 2.3で修正済み）にEJBを挿入できないなどの「ちょっとした面倒なこと」は別として、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 の違いも参照してください。

こちらもご覧ください：

457
BalusC

JSFで5年間働いた後、2セントを追加できると思います。

2つの主要なJSF欠点：

  1. 大きな学習曲線。 JSFは複雑です、それは本当です。
  2. そのコンポーネント性質。コンポーネントベースのフレームワークは、Webの本質を隠そうとします。これには、膨大な量の合併症と災害が伴います（ほぼ5年以内にJSFでGETをサポートしないなど）。
    HTTPリクエスト/レスポンスを開発者から隠すIMHOは大きな間違いです。私の経験から、すべてのコンポーネントベースのフレームワークはWeb開発に抽象化を追加し、その抽象化は不必要なオーバーヘッドとより高い複雑さをもたらします。

マイナー私の頭に浮かぶ欠点：

  1. デフォルトでは、オブジェクトのIDは親のIDで構成されます（たとえば、form1：button1）。
  2. 間違ったページのフラグメントをコメントアウトする簡単な方法はありません。タグ<ui:remove>は、とにかく解析される構文的に正しいコンテンツを必要とします。
  3. 低品質のサードパーティコンポーネント。続行する前にisRendered()メソッド内のprocessXxx()メソッドをチェックしないでください。
  4. LESSとSenchaの組み込みは困難です。
  5. RESTではうまく機能しません。
  6. すぐに使用できるコンポーネントには独自のCSSスタイルがあり、上書きする必要があるため、UXデザイナーにとってそれほど簡単ではありません。

誤解しないでください。コンポーネントフレームワークとして、バージョン2のJSFは本当に優れていますが、それでもコンポーネントベースであり、常にそうです...

Tapestry、Wicketの人気の低さ、経験豊富なJSF開発者の熱意の低さ（さらに意味のあること）をご覧ください。また、対照的に、Rails、Grails、Django、Play！の成功を見てください。フレームワーク-それらはすべてアクションベースであり、プログラマーtrue request/responseおよびstateless natureのWebから隠そうとしません。

私にとっては、JSFの大きな欠点です。 IMHO JSFは、ある種のアプリケーション（イントラネット、フォーム集約型）に適していますが、実際のwebアプリケーションには適していません。

フロントエンドに関する選択を誰かが助けることを願っています。

54
G. Demecki

思い浮かぶいくつかの欠点：

  1. JSFはコンポーネントベースのフレームワークです。これには、コンポーネントモデルに従うことに関係する固有の制限があります。
  2. AFAIK JSFはPOSTのみをサポートしているため、どこかでGETが必要な場合は、プレーンなサーブレット/ JSPを実行する必要があります。
  3. ほとんどのコンポーネントは、リレーショナルデータベースやフロントエンドJavaScriptなどのドメインを抽象化しようとしますが、多くの場合、これらの抽象化は「漏れやすく」、デバッグが非常に困難です。
  4. これらの抽象化は、ジュニア開発者や特定のドメイン（フロントエンドJavaScriptなど）に不慣れな人にとっては良い出発点かもしれませんが、いくつかのレイヤーが関係するため、パフォーマンスを最適化するのは非常に困難です。フードの下で何が起こっているのかほとんど理解していない。
  5. JSFで通常使用されるテンプレートメカニズムは、Webデザイナーの動作とは関係ありません。 JSFのWYSIWYGエディターは原始的であり、いずれの場合でも、デザイナーはHTML/CSSを提供します。
  6. EL式のようなものは静的にチェックされず、コンパイラとIDEの両方がエラーを見つけるのに良い仕事をしていないので、実行時にキャッチしなければならないエラーになります。これはRubyやPHPのような動的に型付けされた言語では問題ないかもしれませんが、Javaエコシステムの膨大な量に耐えなければならない場合、テンプレートの入力を要求します。

要約すると： JSFで節約する時間は、JSP /サーブレット/ビーンボイラープレートコードの記述を避けることから、x10を使ってスケーリングし、望みどおりに実行します。行う。

24
Kay Pale

私にとってJSF 2.0の最大の欠点は、JSFの学習曲線だけでなく、有用な作業を行うために使用する必要があるコンポーネントライブラリです。本当に熟練するために取り扱っている膨大な数の仕様と標準を考慮してください。

  • さまざまな化身のHTML。あなたがそれを知る必要がないふりをしないでください。
  • HTTP-何が起こっているのかわからないときは、Firebugを開いて確認する必要があります。そのためには、これを知る必要があります。
  • CSS-好きかどうか。それほど悪くはなく、少なくともいくつかの素晴らしいツールがあります。
  • XML-JSFは、おそらくこの程度の名前空間を最初に使用する場所です。
  • サーブレット仕様。遅かれ早かれ、このパッケージのメソッドを呼び出すことになります。それとは別に、FaceletsがどのようにXHTMLに変換されるかを知る必要があります。
  • JSP（ほとんどの場合、JSFで必要ない理由がわかります）
  • JSTL（やはり、主にレガシーフレームワークに対処するため）
  • さまざまな形式の式言語（EL）。
  • ECMAScript、JavaScript、またはその他の名前を付けます。
  • JSON-使用しない場合でも、これを知っておく必要があります。
  • AJAX。私はJSF 2.0がこれをあなたから隠すというまともな仕事をすると言うでしょうが、あなたはまだ何が起こっているのかを知る必要があります。
  • DOM。そして、ブラウザがどのように使用するか。 ECMAScriptを参照してください。
  • DOMイベント-単独でのトピック。
  • Java Persistence Architecture（JPA）は、アプリにバックエンドデータベースが必要な場合に使用します。
  • Java自体。
  • あなたがそこにいる間にJSEE。
  • Context Dependency Injection仕様（CDI）と、JSF 2.0との衝突および使用方法
  • JQuery-それなしであなたが仲良くなるのを見たいです。

さて、それが終わったら、独自仕様、つまりコンポーネントライブラリとプロバイダーライブラリを手に入れることができます：

  • PrimeFaces（選択した私のコンポーネントライブラリ）
  • リッチフェイス
  • MyFaces
  • ICEFaces
  • EclipseLink（私のJPAプロバイダー）
  • Hibernate
  • 溶接

そして、コンテナを忘れないでください！そして、これらすべての構成ファイル：

  • GlassFish（2、3など）
  • JBoss
  • Tomcat

それで、これは_IS簡単にする？確かに、JSF 2.0は、やりたいことが最も簡単な相互作用を備えた最も基本的なWebページである限り、「簡単」です。

簡単に言えば、JSF 2.0は、今日のソフトウェアの世界に存在する、最も複雑で厄介な、接着されたテクノロジーの組み合わせです。そして、私は私がむしろ使用したいものを考えることはできません。

19
AlanObject
  1. 経験の浅い開発者は、通常、非常に遅く、コードが本当にくて保守が難しいアプリケーションを作成します。開始するのは一見簡単ですが、優れたプログラムを作成する場合は、実際に学習にいくらかの投資が必要です。
  2. 少なくとも最初は、いくつかの問題にしばしば「立ち往生」し、実際に働くよりもインターネット上のbaluscの投稿を読むことに多くの時間を費やします:)しばらくすると、それはますます少なくなりますが、それでもいらいらする可能性があります。
  3. 問題が知識/間違いの不足によるものではなく、実際にはバグによるものであることがわかった場合、さらに厄介です。 Mojarraは非常にバグが多かった（または？）ため、コンポーネントの別のレイヤーはさらに多くの問題を追加します。 Richfacesはこれまでに書かれたがらくたソフトウェアの中で最大の部分でした:)バージョン4がどのようになっているのかわかりません。Primefacesの方が優れていますが、特によりエキゾチックなコンポーネントでバグや機能不足が発生します。そして今、あなたはPrimefacesの更新のために支払う必要があります。だから私はバグだと言いますが、特に2.2バージョン以降は仕様に関するいくつかの問題を修正した後に良くなります。フレームワークはより成熟していますが、それでも完璧にはほど遠いです（おそらくmyfacesの方が良いでしょうか？）。
  4. 特に柔軟だとは思いません。多くの場合、非常にカスタマイズされたものが必要で、それを行うコンポーネントがない場合は、少し苦痛になります。繰り返しますが、開発者の平均的な観点から話をしています-期限、クイックリーディングチュートリアル、スタックオーバーフローの検索など、実際にどのように機能するかを学ぶ時間がないので、多くのコンポーネントは必要なものを「ほぼ」持っているように見えますが、正確ではなく、時にはあなたがやりたいことをするのに時間がかかりすぎるかもしれません:)独自のコンポーネントを作成するか、既存のコンポーネントを拷問する方が良いかどうかを評価する際には注意が必要です。実際、本当にユニークなものを作成している場合、JSFはお勧めしません。

要するに、私の欠点は次のとおりです。複雑さ、開発があまりスムーズに進まない、バギー、柔軟性がない。

もちろん利点もありますが、それはあなたが尋ねたものではありません。とにかくそれはフレームワークでの私の経験であり、他の人は異なる意見を持っているかもしれないので、最善の方法はあなたのためにそれを見るためにしばらく試してみることです（単純な例ではなく、もっと複雑なもの-JSFが本当に輝いています:) JSFはCRMなどのビジネスアプリケーションです...

13
Koks Skirtumas

「JSFは、コントローラーコードに移動しないと制御または変更できないビューレイヤーHTMLおよびJavaScriptを出力します。」

実際、JSFは柔軟性を提供します。標準/サードパーティのコンポーネントを使用するか、独自のコンポーネントを作成して、レンダリング対象を完全に制御できます。 JSF 2.0でカスタムコンポーネントを作成するために必要なxhtmlは1つだけです。

11
Cagatay Civici

JSFでサンプルプロジェクトを開発しました（3週間の調査でしたので、何かが失われる可能性があります！）

PrimeFacesを使用してコンポーネントが必要な場合は、コアjsfを使用しようとします。

プロジェクトは、ナビゲーションを備えたWebサイトでした。メニューをクリックすると、各ページがajax経由でロードされます。

このサイトには2つのユースケースがあります。

  1. グリッドのあるページ。グリッドはajaxを介してロードされ、ソートとページングをサポートする必要があります
  2. 3ステップのウィザードページ。各ページには、クライアント側の検証（単純な検証用）とサーバー側のajaxベース検証（複雑な検証用）があります。 （サービス層からの）サーバー例外は、次のページに移動せずにウィザードの同じページに表示する必要があります。

私たちはそれを見つけました：

  1. JSFビューステートを修正するには、omniFacesのいくつかのハックを使用する必要があります。 Ajaxを介してページを相互に含めると、JSF状態が破損します。これはJSFのバグのようであり、次のリリースで修正される可能性があります（2.3ではありません）。
  2. JSF Flowはajaxで正しく機能していません（または機能しません！）代わりにprimefaceウィザードコンポーネントを使用しようとしますが、クライアント検証はサポートされていないようで、標準のJSFフロー標準ではありませんでした。
  3. JqGirdのようなjQueryコンポーネントを使用し、JSONの結果をロードする必要がある場合は、純粋なサーブレットを使用することをお勧めします。JSFは何も行いません。したがって、これらの種類のコンポーネントを使用すると、設計はJSFに適合しません。
  4. ajaxCompleteによってajaxが完了したときにいくつかのクライアントスクリプトを実行しようとしましたが、PF 4が独自のajaxイベントを実装していることがわかりました。 jQueryコンポーネントがいくつかあり、それらのコードを変更する必要があります。

上記のサンプルをnon Ajaxプロジェクト（または少なくともajaxプロジェクト以下）に変更すると、上記の問題の多くに直面することはありません。

私たちの研究を次のように要約します。

JSFは、完全にajaxベースのWebサイトではうまく機能していません。

もちろん、JSFには、一部のプロジェクトで非常に役立つ多くのNice機能がありますので、プロジェクトのニーズを考慮してください。

JSFの技術文書を参照してJSFの利点を確認してください。私の意見では、JSFの最大の利点は@BalusCからの完全かつ大規模なサポートです;-)

10
Alireza Fattahi

私はJava Server Facesのエキスパートではありません。しかし、私見の主な欠点は、サーバー側であることです。 ASP.NET Web Forms、ASP.NET MVC、Java Server Faces、Struts、PHPフレームワーク、およびRubyなどのサーバーサイドWebプレゼンテーションレイヤーフレームワークの学習と使用にうんざりしていますRailsフレームワーク。それらすべてに別れを告げ、AngularjsとTypeScriptに挨拶しました。プレゼンテーションレイヤーはブラウザーで実行されます。 phpまたはASP.NETを実行しているWindows IISによって提供されるか、Linuxで実行されるApache Webサーバーによって提供されるかは関係ありません。どこでも機能するフレームワークを1つだけ学ぶ必要があります。

ちょうど私の2セント。

10
Jesús López

Primefaces/JSFでの過去数ヶ月の経験についてコメントする：

  • 「既製」のコンポーネントを使用できる場合、それはひどいものではないと思います。
  • ただし、外に出てカスタムUIが必要になるとすぐにはうまく動作しません。 -たとえば、プロジェクトにTwitterのbootstrapを使用する必要がありました。 （primefacesブートストラップではありません）。
    • これで、ページは次のように機能します。
      • ページがロードされます。
      • ユーザーは、ajax機能を持つPrimefacesと対話します
      • ブートストラップのjavascriptバインディングが壊れる
      • 追加のJavaScriptを実行して、すべてを再バインドします

JavaScriptの記述を回避するというJSFの約束は、Primefacesを使用しない場合よりも多くのJavaScriptを記述することになり、そのJavaScriptがPrimefacesの破損を修正します。

これは時間の無駄です。「市販」のものを再び使用する場合を除きます。また、Seleniumで作業しなければならないときは本当にい（Primefaces）。それはすべて行うことができます-しかし、再び-そんなに時間がありません。

UX /デザインチームと連携しており、UIをすばやく反復する必要がある場合は、これを絶対に避けてください（jqueryの学習/ HTMLの直接記述）または反応/角度を確認することで時間を節約できます。

6
rprasad

私にとって、JSFの最大の欠点は、プログラムで（動的に）生成されたページのサポートが不十分であることです。
Javaコードからページを動的に構築する（ページコンポーネントモデルを作成する）場合。たとえば、WYSIWYG Webページコンストラクターで作業している場合。このユースケースの適切なドキュメントは、一般には入手できません。あなたが実験しなければならない多くのポイントがあり、開発は静かにゆっくりです。多くのことは、期待どおりには機能しません。しかし、一般的には何らかの方法でハッキングする可能性があります。
良い点は、JSFの哲学やアーキテクチャに問題がないことです。 （私が知る限り）十分に詳しく説明されていないだけです。

JSF 2は、コンポーネント開発を容易にする複合コンポーネントをもたらしましたが、動的（プログラム）構築のサポートは非​​常に貧弱です。静かで複雑でほとんど文書化されていない動的な複合コンポーネントの構築プロセスを克服すると、いくつかの複合コンポーネントを少し深くネストすると、動作を停止し、いくつかの例外がスローされることがわかります。

しかし、JSFコミュニティはこの欠点を認識しているようです。これらの2つのバグからわかるように、彼らはこれに取り組んでいます
http://Java.net/jira/browse/JAVASERVERFACES-1309
http://Java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

少なくとも仕様について話している場合は、JSF 2.2で状況が改善されるはずです。

6
Ondrej Bozek

JSFには多くの利点がありますが、不利な点に疑問を抱かせてください。

時間枠内でWebプロジェクトを実装する実用的なシナリオでは、次の要素に注意する必要があります。

  • チームには、各シナリオに適した最適なコントロールを提案できる十分な上級メンバーがいますか？

  • 初期学習曲線に対応する帯域幅はありますか？

  • JSFを確認できる十分な専門知識がチームにありますか
    ものは開発者によって作成されますか？

質問に対する答えが「いいえ」の場合、保守不能なコードベースになる可能性があります。

1
Sam

Spring MVC、Wicket、Tapestryなどのすべての「メインストリーム」フレームワークの中で、Java EEとその複合コンポーネントのJSFは、提供される最も精巧なプレゼンテーション層およびコンポーネント指向のテクノロジーです。 HybridJavaが提供するソリューションと比較すると、少し面倒で不完全です。

0
Dima

JSFには欠点が1つしかありません。「JSF」開発を開始する前に、Web開発、コアJavaおよびフロントエンドアーキテクチャを明確に理解する必要があります。

最近の「新しい」JavaScriptフレームワークは、「JSF」コンポーネントベースのモデルをコピー/貼り付けしようとしています。

0
Armen Arzumanyan