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

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

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

だから私の質問は：

• Java Server Faces 2.0の主な欠点は何ですか？
• JSF開発者がJSFの代わりにASP.NET MVCの使用を検討する理由は何ですか？

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

JSF 1.0（2004年3月）

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

JSF 1.1（2004年5月）

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

JSF 1.2（2006年5月）

これは、Ryan Lubkeが率いる新しいJSF開発チームの最初のリリースでした。新しいチームは多くの素晴らしい仕事をしました。仕様にも変更がありました。主な変更点は、ビューの処理の改善です。これにより、JSFがJSPから完全に切り離されるだけでなく、JSPとは異なるビューテクノロジを使用できるようになるだけでなく、開発者は<f:verbatim>タグを煩わせることなく、JSFページに単純なHTMLをインライン化できます。新しいチームのもう1つの主な焦点は、パフォーマンスの向上でした。Sun JSFリファレンス実装1.2（Mojarraとコードネームが付けられた）の存続期間中 2008年頃のビルド1.2_08以降、、実質的にすべてのビルドは、通常の（マイナー）バグフィックスの隣に（メジャー）パフォーマンスの改善が施されて出荷されました。

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

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

また、JSF 1.xにはAjax機能が付属していません。実際には技術的な欠点ではありませんが、その期間のWeb 2.0の誇大宣伝により、機能上の欠点になりました。Exadelは早い時期にAjax4jsfを導入しました。Ajax4jsfは、長年にわたって徹底的に開発され、JBoss RichFacesコンポーネントライブラリのコア部分になりました。別のコンポーネントライブラリには、組み込みのAjaxパワーも含まれており、よく知られているのはICEfacesです。

JSF 1.2の存続期間のほぼ半分に、新しいXMLベースのビュー技術であるFaceletsが導入されました。これは、特にテンプレートの領域において、JSPを超える大きな利点をもたらしました。

JSF 2.0（2009年6月）

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

Ajaxパワーは<f:ajax>、Ajax4jsfと非常に類似しているコンポーネントのフレーバーで導入されました。詳細ファイルを可能な限り削除するために、アノテーションと設定より規約の拡張機能が導入されましたfaces-config.xml。また、デフォルトのネーミングコンテナID区切り文字:が構成可能になったため、HTML / CSSの純粋主義者は安心できました。あなたがやらなければならないことは、としてそれを定義することであるinit-paramでweb.xml名前でjavax.faces.SEPARATOR_CHAR、あなたはどこにでもクライアントIDの中の文字を自分で使用していないことを確実にすること、など-。

最後になりましたが、ビューのスコープという新しいスコープが導入されました。前述のように、JSF 1.xのもう1つの主要な欠点を排除しました。Bean @ViewScopedを宣言するだけで、後続の（会話型）リクエストでデータを保持するためのあらゆる方法を煩わせることなく、会話スコープを有効にできます。@ViewScopedあなたは後で提出し、同じビューにナビゲートしているとして、Beanは限り生きてます（独立して開いたブラウザタブ/ウィンドウの！）、同期または非同期（アヤックス）。参照してください管理Beanで表示し、Requestスコープの違いとどのように右の豆の範囲を選択するには？

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機能は、カスタムコンポーネント属性のサポートです。これにより、カスタムのテーブルレスラジオボタングループなどの可能性の世界が広がります。

実装固有のバグと、EJBをバリデーター/コンバーターに挿入できない（JSF 2.3ですでに修正されている）など、いくつかの「迷惑な小さなこと」を除いて、JSF 2.2仕様にはそれほど大きな欠点はありません。

コンポーネントベースのMVCとリクエストベースのMVC

JSFの主な欠点は、生成されたHTML / CSS / JSを細かく制御できないことを選択する人もいます。それはJSF独自のものではありません。それは、それがコンポーネントベースの MVCフレームワークであり、リクエスト（アクション）ベースの MVCフレームワークではないからです。HTML / CSS / JSの高度な制御がMVCフレームワークを検討する際の主要な要件である場合、コンポーネントベースのMVCフレームワークではなく、Spring MVCなどのリクエストベースのMVCフレームワークを検討している必要があります。HTML / CSS / JSのボイラープレートをすべて自分で作成する必要があることだけを考慮に入れる必要があります。リクエストMVCとコンポーネントMVCの違いもご覧ください。

以下も参照してください。

• JSF、サーブレット、JSPの違いは何ですか？（基本を理解するためだけに）
• JSFを使用したテーブルレスCSSレイアウトの開発（JSFに関する別の神話）
• JSF対プレーンHTML / CSS / JS / jQuery（JSFが間違った選択である場合）
• Webアプリケーションのデザインパターン（MVCの背後にあるイデオロギーを示します）

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

JSFの 2つの主な欠点：

1. 大きな学習曲線。JSFは複雑ですが、それは事実です。
2. そのコンポーネントの性質。コンポーネントベースのフレームワークはWebの本来の性質を隠そうとしますが、それには膨大な量の複雑化と災害が伴います（ほぼ5年以内にJSFでGETをサポートしないなど）。
   IMHOがHTTPリクエスト/レスポンスを開発者から隠すことは、大きな間違いです。私の経験から、すべてのコンポーネントベースのフレームワークは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の成功をご覧ください。フレームワーク-それらはすべてアクションベースであり、プログラマから真の要求/応答を隠そうとせず、 Webのステートレスな性質。

私にとって、これはJSFの大きな欠点です。IMHO JSFは、特定のタイプのアプリケーション（イントラネット、フォーム集約型）に適していますが、実際のWebには適しています適していますアプリケーションの場合、これは適切な方法ではありません。

それがフロントエンドに関する彼/彼女の選択で誰かを助けることを願っています。

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

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 /サーブレット/ 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はこれをあなたから隠す適切な仕事をしていますが、何が起こっているのかを知る必要があります。
• DOM。そして、ブラウザがそれをどのように使用するか。ECMAScriptを参照してください。
• DOMイベント-それ自体がトピックです。
• Java Persistence Architecture（JPA）。これは、アプリにバックエンドデータベースを持たせたい場合に使用します。
• Java自体。
• あなたがそれにいる間JSEE。
• Context Dependency Injection仕様（CDI）とそれがどのように衝突し、JSF 2.0で使用されるか
• jQuery-それなしでうまくやってほしい。

さて、それが終わったら、プロプライエタリな仕様、つまりコンポーネントライブラリとプロバイダーライブラリを使用することができます。

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

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

• GlassFish（2、3など）
• JBoss
• トムキャット

それで、これはそれを簡単にしていますか？もちろん、JSF 2.0は、やり取りが最も単純な最も基本的なWebページであれば、簡単に実行できます。

簡単に言うと、JSF 2.0は、今日のソフトウェアユニバースに存在する、テクノロジーを接着した最も複雑で扱いにくいミッシュマッシュです。そして、自分が使いたいと思うものは何も考えられません。

1. 経験の浅い開発者は通常、非常に遅いアプリケーションを作成し、コードは非常に醜く、保守が困難になります。一見すると簡単に始められますが、優れたプログラムを作成するには、実際には学習にいくらかの投資が必要です。
2. 少なくとも最初は、いくつかの問題に「行き詰まっている」ことが多く、実際の作業よりもインターネット上の手抜きの投稿を読むのに多くの時間を費やします。
3. 問題があなたの知識/間違いの欠如によるものではなく、実際のバグによるものであることがわかると、さらにいらいらします。Mojarraはかなりバグが多く、別のコンポーネント層がさらに問題を追加します。Richfacesはこれまでに書かれたがらくたソフトウェアの最大の部分でした:)現在バージョン4でどのようになっているのかわからない。そして今、あなたはPrimefacesの更新にお金を払う必要があります。だから私はそのバグがあると言いますが、特に2.2バージョンがスペックに関するいくつかの問題を修正した後で、それは良くなっています。フレームワークはより成熟していますが、まだ完璧には程遠いです（多分myfacesはより良いでしょうか？）。
4. 特に柔軟性があるとは思いません。多くの場合、非常に非常にカスタマイズされたものが必要で、それを行うコンポーネントがない場合は、少し苦痛になります。繰り返しますが、私は平均的な開発者の観点から話しています。締め切り、クイックチュートリアル、スタックフローの検索など、実際にどのように機能するかを学ぶ時間がないので、スタックオーバーフローを検索します。正確ではなく、時々あなたがそれをあなたが望む何かをするためにあまりにも多くの時間を費やすかもしれません:)あなた自身のものを作成するか、既存のコンポーネントを拷問する方が良いかどうか評価する際に注意する必要があります。実際、本当にユニークなものを作成しているのであれば、JSFはお勧めしません。

つまり、私の欠点は、複雑さ、開発の進行があまりスムーズでない、バグが多い、柔軟性がない、ということです。

もちろん利点もありますが、それはあなたが求めたものではありません。とにかく、フレームワークでの私の経験は他の人が異なる意見を持っている可能性があるので、最善の方法はそれをしばらく試してみて、それがあなたのためかどうかを確認することですJSFはCRMなどのビジネスアプリケーションです...

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

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

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

ちょうど私の2セント。

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

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

このプロジェクトはナビゲーション付きのWebサイトでした。メニューをクリックすると、各ページがajaxを介して読み込まれます。

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

1. グリッドのあるページ。グリッドはajax経由で読み込まれ、並べ替えとページングをサポートする必要があります
2. 3ステップのウィザードページ。各ページには、クライアント側の検証（単純な検証の場合）とサーバー側のajaxベースの検証（複雑な検証の場合）があります。（サービス層からの）サーバー例外は、次のページに移動せずに、ウィザードの同じページに表示されます。

次のことがわかりました。

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

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

調査結果を次のように要約します。

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

もちろん、JSFには多くの優れた機能があり、プロジェクトによっては非常に役立つ場合があるため、プロジェクトのニーズを考慮してください。

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

私にとって、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では状況が良くなるはずです。

Primefaces / JSFの過去数か月の経験についてコメントします。

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

JavaScriptの作成を回避するというJSFの約束は、Primefacesを使用しない場合よりも多くのjavascriptを作成するようになり、そのJavaScriptはPrimefacesが壊れることを修正します。

これは時間のシンクです。再び「既成」のものを使用しない限り。また、Seleniumで作業する必要がある場合は、本当に醜い（Primefaces）。それはすべて実行できますが、繰り返しになりますが、時間があまりありません。

UX /デザインチームで作業していて、UIですばやく反復処理する必要がある場合は、これを完全に避けてください。jqueryを学習するか、ストレートHTMLを書くか、react / angularを調べることで時間を節約できます。

JSFには多くの利点がありますが、不利な点があるので、それにいくつかポイントを付け加えます。

時間枠内でWebプロジェクトを実装する実際のシナリオでは、以下の要因に注意する必要があります。

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

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

• 
  開発者が作成したJSFの内容をレビューできる十分な専門知識がチームにありますか？

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

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

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

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