JSPスクリプトレットが悪いのに、なぜJSXが良いのですか？

React.jsは、コンポーネントと要素のツリーを構築するためのXHTMLのような構文としてJSXを提供します。JSXはJavascriptにコンパイルされ、JSX固有のループまたは条件を提供する代わりに、Javascriptを直接使用します。

<ul>
  {list.map((item) =>
    <li>{item}</li>
  )}
</ul>

まだ説明できていないのは、JSPで類似のコンストラクトが悪いと考えられる場合、なぜこれが良いと考えられるのですか？

JSPのこのようなもの

<ul>
   <% for (item in list) { %>
     <li>${item}</li>
   <% } %>
</ul>

はのようなタグで解決される読みやすさの問題と見なされます<c:forEach>。JSTLタグの背後にある理由は、JSXにも適用できるようです。

• XHTMLのような構文（山括弧、ネスト）とJava / Javascript（中括弧、コンマ、括弧）を切り替えていない場合は、読みやすくなります。
• レンダリング関数内で使用可能な完全な言語とプラットフォームがある場合、そこに属さないロジックを入れることを思いとどまらせることはほとんどありません。

JSXが異なる理由を考えることができる唯一の理由は次のとおりです。

• Javaでは、間違ったことをするインセンティブがありました。JSPはホットリロードされるので、JSPにコードを入れて再構築/再起動のサイクルを避けようとしました。保守性は、即時の生産性のために犠牲になりました。スクリプトレットを廃止し、テンプレート構成体の固定セットに制限することは、実質的に保守性を強化する方法でした。JSの世界にはそのような歪みはありません。

• JSPとJavaの構文は、<% ... %>Javaコードと要素の生成を区別するための余分な要素や、foreach概念やファーストクラスの機能を持たないJavaのネイティブな構文（最近まで）に不格好です。JSXでループと条件にネイティブJavascriptを使用する構文のペナルティはゼロではありませんが（私の意見では）、JSPほど悪くはなく、ループと条件にJSX固有の要素を導入することを保証するのに十分なほど悪くはありません。

私が見逃している何か他のものがありますか？

主に、JSXを作成した人々は、JSPを嫌う人々とは反対しました。こちらの議論をご覧ください：なぜReactを構築したのですか？データの表示と同様に

テンプレートは、ページのロジックと表示を分割するという考えに基づいています。この理論では、javascript（またはjava）コードは表示されるマークアップに関係するべきではなく、マークアップは関係するロジックに関係するべきではありません。基本的に、この区分が、コードをテンプレート（PHP / JSP / ASP）と混合することを容易にするさまざまなテンプレート言語を人々が批判する理由です。

Reactはコンポーネントに基づいています。反応の著者は、コンポーネントのロジックとプレゼンテーションは密接に関連していると主張しており、それらを分割しようとしても意味がありません。代わりに、ページを論理的な断片で分割する必要があります。そのため、ヘッダーバー、コメント、投稿、関連する質問などを個別のコンポーネントに分割できます。しかし、プレゼンテーションから関連する質問のロジックを分けてみても意味がありません。

JSXのようなものとJSPのようなものの主な違いは、JSPがロジック用のJavaを少し含むテンプレート言語であることです。JSXは、htmlのフラグメントを簡単に作成できるようにする構文拡張機能を備えたjavascriptです。強調は異なります。JSXはこのアプローチを採用しているため、最終的にはJSPまたは友人が行うより優れた、よりクリーンなアプローチを作成します。

しかし、最終的には、反応した人がテンプレートを好まなかったという事実に帰着します。彼らは悪い考えだと思い、マークアップとプレゼンテーションのロジックを同じ場所に置くべきだと考えています。

Reactの部外者として、私はJSXをフレームワークの悪臭の非常に混雑した動物園でのもう1つの「フレームワークの匂い」と見なしました。私はまだそうではないとは確信していません。

「有用」の実行可能な定義は、ライブラリ/フレームワーク/パターンが引き起こすよりも多くの問題を解決することだと思います。JSXがその定義に適合するとはまだ確信していません。それは「風船を絞る」ということわざです...ここで問題をつぶすと、そこから飛び出します。私にとって、JSXは特定の問題を解決しているのではなく、単に「異なる」だけです。

正式なビルドプロセスを必要とするコンパイル可能なセマンティクスを導入するという概念は、状況によっては役立ちます。たとえば、.cssファイルのLESSコンパイルは、cssの周囲に非常に必要な構造を提供します。 「スパゲッティソリューション」に陥りやすい。しかし、Javascriptプリコンパイラは...それほどではありません。

要するに：

• フロントエンド開発者は、スクリプトとテンプレートを知っていることが求められます
• JSXとJSPは両方ともテンプレート言語です
• JavaScriptはスクリプト言語です
• Javaはスクリプト言語ではありません

参照資料

• HTMLとJavaScriptの分離は有害ですか？| Cory HouseのBitnative

• スクリプトが有害であると見なされる理由と、プログラムでスクリプトを無効にする方法

• JSPファイルでJavaコードを回避する方法は？- スタックオーバーフロー

あなたの説明に基づいてJSXを使用していませんが、JSXフラグメントの仕事はデータを表示することです。つまり、MVCの用語ではビューコンポーネントです。JSXフラグメントは、おそらくデータがどこから来たのかを知りませんし、気にしません。

よく構造化されたJSPページには、ご指摘のようにJSTLディレクティブのみが含まれます。JSTLディレクティブはJSPを単純化するだけなので、スコープからのフェッチ、nullのチェックなどで煩雑になりません。

JSXフラグメントと同じです。JSPの唯一の仕事は、送信元を気にせずに受信したデータをどのように表示するかを把握することです。

要約すると、ビューがJSXであるかJSPであるかにかかわらず、適切に実行している場合、ビューはデータを表示するだけです。

プレゼンテーションをサーバー上ではなくクライアントに移行する理由については、これにより柔軟性が高まります。Webサイトは、Webサービス（たとえば、ReST）を介してデータを取得し、別のクライアントになることができます。後でAndroidまたはiOSのネイティブアプリが必要だと判断した場合、それらはWebサイトと同じWebサービスのセットを使用できます。