jQueryやAngularJSなどのJavaScriptライブラリでUIを実現できる場合のJSFの必要性

私は、JSFがUIフレームワークであり、いくつかのUIコンポーネントを提供していることについて読んでいました。しかし、jQueryUI、AngularJS、ExtJS、さらにはプレーンなHTML、CSS、JavaScriptから利用できるコンポーネントの数とはどのように優れているか、どのように異なるのでしょうか。

なぜ誰かがJSFを学ぶ必要があるのですか？

プレーンなJSP /サーブレット/ HTML / CSS / JSへのJSFは、プレーンなJSへのjQueryのようなものです：より少ないコードでより多くを実行します。PrimeFaces（jQuery + jQuery UIベース）を例に取るには、ショーケースを参照して完全なコード例を確認してください。BootsFaces（jQuery + Bootstrap UIベース）にも、完全なコード例を示すショーケースがあります。これらの例を詳しく検討すると、基本的にはモデルとして単純なJavabeanクラスが、ビューとしてXHTMLファイルが必要であることがわかります。

JSFをHTML / CSS / JSだけの代わりとして見るべきではないことに注意してください。サーバー側の部分（特に：JSP /サーブレット）も考慮する必要があります。JSFは、HTTP要求パラメーターを収集し、それらを変換/検証し、モデル値を更新し、ビジネスに適切なJavaメソッドを実行し、HTML / CSS / JSボイラープレートコードを生成するというすべてのボイラープレートの必要性を取り除きます。JSFを使用すると、基本的にはビュー定義としてのXHTMLページとモデル定義としてのJavabeanクラスになります。これにより、開発が大幅にスピードアップします。

すべてのコンポーネントベースのWeb MVCフレームワークと同様に、JSFでは、レンダリングされたHTML / CSS / JSをより細かく制御できます。カスタムJSコードの追加は、サーバー側のJSFビューステートも考慮する必要があるため、それほど簡単ではありません（たとえば、JS側で無効なボタンを有効にしても、JSF側のボタンは有効になりません。大きなセキュリティ上の利点）。ただし、それが主要なショートッパーである場合は、Spring MVCのようなアクションベースのWeb MVCフレームワークを探してください。HTML / CSS / JSコード（およびXSS、CSRF、DOM操作の防止！）をすべて自分で作成する必要があることだけを考慮に入れます。。また、FaceletsからJSPにフォールバックすると、高度なテンプレート機能も使用できなくなります。

一方、大きなJSP /サーブレット/ HTML / CSS / JS / jQueryベースのWebサイトがあり、繰り返されるJSP /サーブレット/ HTML / CSS / JS / jQueryボイラープレートコードを再利用可能なコンポーネントにリファクタリングする場合は、ソリューションの1つはJSFです。カスタムテンプレート、タグファイル、コンポーネントがこれを支援します。その観点では、JSFはJSP /サーブレット/ HTML / CSS / JS / jQueryの上に立っています（それが、JSFに飛び込む前にこれらの基本を理解することが非常に重要である理由でもあります）。

実際のキックオフJSFベースのプロジェクトは、Java EEキックオフアプリにあります。JSFの隣に、優れたHTML5、CSS3、jQueryが含まれていることがわかります。。

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

• リクエストMVCとコンポーネントMVCの違い
• JSP、サーブレット、JSFの違い
• JSF 2.0の主な欠点は何ですか？
• HTML 4/5でJSF + Faceletsを使用することは可能ですか？
• <ui：include>、タグファイル、複合コンポーネント、カスタムコンポーネントを使用する場合

JSFは、JavaショップがjQueryのようなものを学び、複雑なJSを構築する必要がなく、純粋にJavaスタックに焦点を合わせるために作成されました。時は金なりであり、すでにJava開発に重点を置いている多くの場所で、スタック内の言語/ピースが1つ少ないため、トレーニングと保守がより速く、したがってより安価になります。

特に、プロジェクトの開発者の一部がWebにあまり精通していない場合は、JavaScriptが大規模なチームのメンテナンスの悪夢になりやすいことを付け加えておきます。

JavaScriptとjQueryなどのフレームワークを使用すると、完全な柔軟性と完全な制御が得られます。extなどを使用すると、多くの制御が失われ、フレームワークに適応する必要があります。JSFを使用すると、完全にコントロールを失い、フレームワークに完全に適応する必要があります。あなたはライフサイクルなどで呼び出され、最後にサーバーへの呼び出しをいつ行うことができ、どこでできないかを制御できません。「特別な」と考えられることをするなら、あなたは非常に難しい立場にいます。また、JSFの世界では、複数列のテーブルソートや、限られた文字セット（数値フィールドなど）しか入力できないフィールドなどの基本的なものも「特別」と見なされます。

ただし、柔軟性が高ければ高いほど、エラーや悪い習慣が増える可能性があります。高い柔軟性は、高度にインテリジェントなプログラマーでのみ機能します。他のプログラマーは、プロジェクトを管理できない悪夢に変えます。

しかし、JSFとその制限された柔軟性により、何かを行うための正しい方法は常にいくつか（または1つだけ）しかありません。あなたは非常に制限されており、ショートカットを作成することはできません。より多くのXMLを記述する必要があります。しかし、標準に適応すると、経験の浅いプログラマや熟練していないプログラマが生成するコードをより適切に制御できます。その結果、大企業はJSFを「より安全」にするため、JSFを愛しています。

私がGWTからJSFに移行したとき、私にとっては自然なことであるが、非常に非典型的であると見なされ、単純なことを達成することがどれほど困難であるかにショックを受けました。さらに、ラベルの後に「：」記号を追加するなど、最小限の変更を行う場合でも、GWT / jQueryを使用するアプリでは、ラベルを生成する1つの関数を変更するため、ローカライズされたプロパティを持つ数十のファイルを変更する必要があり、これも考慮されていませんでした。奇妙な私以外の誰か...

JSFを使用する利点は、xhtml + css + jsを生成することだけではありません。コンポーネントベースのフレームワークのように、JSFは生成できるマークアップに制限を課すことがあります。しかし、JSFはそれだけでなく、ライフサイクルが大きく役立ちます。入力を検証した後、モデルを更新してサーバー側のBeanを簡単に同期できます。「ユーザーがここに入力するものは何でも、それが数値かどうかを確認し、そうであればオブジェクトXXのプロパティYYに保存します」とJSFがすべて実行します。

つまり、JQueryやJSなどを引き続き使用できます。しかし、JSFはサーバー側のコードの記述に関して多くの利点を提供し、多くのボイラープレートからあなたを救います。

jsfが何かを追加することに強く反対します。オーバーヘッドが増えるだけです。サーバーでuiを実行することは、これまでに聞いた中で最も馬鹿げたことです。そして、大規模なチームのjavascriptはうまく機能します。これは、再利用コードと呼ばれています。

いくつかのjspタグでjqueryをラップするだけで、必要な作業はすべて完了します。.shacklesや、.jsfやrichfacesによるスケーラビリティの問題に耐えないでください。

JSF、Spring MVC、Struts、Grails、JQuery、ExtJSを使用した経験から、Grails + ExtJSは強力な組み合わせの1つだと私は考えています。

私はいつでもJSFよりGrailsを選ぶでしょう。クライアント側のフレームワークおよびライブラリとしてのExtJSの完全性が気に入っていますが、JQueryよりも学習曲線が急です。

jQueryとJSFの最大の違いは次のとおりです。

• MVCアーキテクチャなし
• 状態管理なし（セッションまたは会話に日付を保存、自動クリーンアップなど）
• いいえ（デフォルト）検証ライブラリー
• テンプレートライブラリなし
• 高度なナビゲーション/ルーティングなし
• クライアント側

jQueryは、フルスタックのWebフレームワークとして使用することを意図したものではありません。これは、低レベルのJSコードを置き換えるためのもので、JSの記述がより少ないコード行でより簡単かつ強力になるように意図されていました。

したがって、主にHTML要素に動作を追加するために使用する必要があります。

大規模なWebアプリケーションにExtJSフレームワークを使用したことがあるので、その使い方がいかに簡単かを知っています。ExtJS（Schena）は、MVCアーキテクチャでの（Oracle 11g）データベース相互作用に最適です。ビューは、視覚的/ユーザー対話のためのものでした。コントローラは、PLSQLパッケージ（CRUD、SQL選択クエリなどのAPI）を形成するために必要な「処理」とトリガーを指定しました。モデルとストアファイルは、データ項目をビューア/入力に「マップ」するために使用されました。

ExtJSは、Angular JSの方が適している可能性がある、データベースを多用しないWebインターフェースには適していません。