Pourquoi JSX est-il bon, alors que les scriptlets JSP sont mauvais?

React.js fournit JSX comme une syntaxe de type XHTML pour la construction d'un arbre de composants et d'éléments. JSX compile en Javascript, et au lieu de fournir des boucles ou des conditions dans JSX proprement dit, vous utilisez directement Javascript:

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

Ce que je n'ai pas encore pu expliquer, c'est pourquoi est-ce considéré comme bon si les constructions analogues sont considérées comme mauvaises dans JSP?

Quelque chose comme ça dans JSP

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

est considéré comme un problème de lisibilité à résoudre avec des balises comme <c:forEach>. Le raisonnement derrière les balises JSTL semble également pouvoir s'appliquer à JSX:

• c'est un peu plus facile à lire lorsque vous ne basculez pas entre la syntaxe de type XHTML (crochets, imbrication) et Java / Javascript (curlies, virgules, parens)
• lorsque vous avez le langage complet et la plate-forme disponibles pour une utilisation à l'intérieur de la fonction de rendu, il y a moins pour vous décourager de mettre une logique qui n'y appartient pas.

Les seules raisons pour lesquelles je peux penser pourquoi JSX est différent sont:

• en Java, vous étiez incité à faire la mauvaise chose - JSP serait rechargé à chaud, il était donc tentant de mettre du code dans les JSP pour éviter un cycle de reconstruction / redémarrage. La maintenabilité a été sacrifiée pour une productivité immédiate. Bannir les scriptlets et se limiter à un ensemble fixe de constructions de modèles était en fait un moyen de renforcer la maintenabilité. Aucune distorsion de ce type n'existe dans le monde JS.

• La syntaxe JSP et Java est maladroite avec le supplément <% ... %>pour distinguer le code Java de la génération d'éléments, et avec la syntaxe native de Java dépourvue de foreachconcept ou de fonctions de première classe (jusqu'à récemment). La pénalité syntaxique de l'utilisation de Javascript natif pour les boucles et les conditions dans JSX est non nulle (à mon avis) mais pas aussi mauvaise que JSP, et sans doute pas assez mauvaise pour justifier l'introduction d'éléments spécifiques à JSX pour les boucles et les conditions.

Y a-t-il autre chose qui me manque?

Principalement, les personnes qui ont créé JSX n'étaient pas d'accord avec les personnes qui n'aimaient pas JSP. Voir leur discussion ici: Pourquoi avons-nous construit React? ainsi que l' affichage des données

Les modèles sont basés sur l'idée de créer une division entre la logique et la présentation d'une page. Dans cette théorie, votre code javascript (ou java) ne devrait pas être concerné par le balisage affiché, et votre balisage ne devrait pas être concerné par la logique impliquée. Cette division est essentiellement la raison pour laquelle les gens critiquent les différents langages de modèles qui permettaient facilement de mélanger du code avec votre modèle (PHP / JSP / ASP).

React est basé sur des composants. Les auteurs de react soutiennent que la logique et la présentation d'un composant sont étroitement liées, et tenter de les diviser n'a aucun sens. Au lieu de cela, une page doit être brisée par des éléments logiques. Vous pouvez donc décomposer la barre d'en-tête, les commentaires, les articles, les questions connexes, etc. en composants séparés. Mais cela n'a pas de sens d'essayer de séparer la logique des questions connexes de la présentation.

La principale différence entre quelque chose comme JSX et quelque chose comme JSP est que JSP est un langage de modèle qui inclut un peu de java pour la logique. JSX est javascript avec une extension de syntaxe pour faciliter la construction de fragments de code html. L'accent est différent. Étant donné que JSX adopte cette approche, il finit par produire une approche plus agréable et plus propre, puis effectuée par JSP ou des amis.

Mais finalement, cela revient au fait que les personnes qui ont réagi n'aimaient pas les modèles. Ils pensent que c'est une mauvaise idée et que vous devriez mettre votre logique de balisage et de présentation au même endroit.

En tant qu'étranger de React, je considérais JSX comme une autre "odeur de cadre" dans le zoo très encombré de puanteurs du cadre. Je ne suis toujours pas convaincu que ce ne soit pas le cas.

Je pense qu'une définition pratique de "utile" est qu'une bibliothèque / framework / pattern résout plus de problèmes qu'elle n'en provoque. Je ne suis pas encore convaincu que JSX corresponde à cette définition. C'est le proverbial "presser le ballon" ... vous écrasez un problème ici, il apparaît là-bas. Pour moi, JSX ne résout aucun problème particulier ... il est juste "différent".

La notion d'introduction d'une sémantique compilable qui nécessite un processus de construction formalisé est utile dans certaines circonstances: par exemple, la compilation MOINS de fichiers .css fournit une structure très nécessaire autour de css, qui est une structure hiérarchique avec des importations et des remplacements, donc étant très enclin aux «solutions de spaghetti». Mais les pré-compilateurs Javascript ... pas tellement.

En bref:

• Les développeurs frontaux devraient connaître les scripts et les modèles
• JSX et JSP sont tous deux des langages de modèles
• JavaScript est un langage de script
• Java n'est pas un langage de script

Les références

• La séparation du HTML et du JavaScript est-elle nuisible? | Bitnative par Cory House

• Pourquoi les scripts sont-ils considérés comme nuisibles et comment désactiver les scripts dans votre programme?

• Comment éviter le code Java dans les fichiers JSP? - Débordement de pile

Bien que je n'utilise pas JSX, d'après votre description, le travail du fragment JSX consiste à présenter les données, c'est-à-dire qu'il s'agit d'un composant d'affichage dans le langage MVC. Le fragment JSX ne sait probablement pas ou ne se soucie pas d'où proviennent les données, ce que vous voulez.

Une page JSP bien structurée ne contiendra que des directives JSTL comme vous le mentionnez. Les directives JSTL simplifient simplement vos JSP afin qu'elles ne soient pas encombrées lors de la récupération de la portée, de la vérification de la valeur null, etc.

Tout comme le fragment JSX; le seul travail du JSP devrait être de comprendre comment présenter les données qu'il a reçues sans se soucier de leur origine.

En résumé, que votre vue soit JSX ou JSP, si vous le faites correctement, votre vue ne présentera que des données.

Quant à savoir pourquoi vous pouvez déplacer la présentation vers le client au lieu de le faire sur le serveur, cela vous donne plus de flexibilité. Votre site Web peut obtenir ses données via des services Web (ReST par exemple) et être simplement un autre client. Si vous décidez plus tard que vous souhaitez une application Android ou iOS native, ils peuvent consommer le même ensemble de services Web que votre site Web.