¿Por qué es bueno JSX, cuando los scriptlets JSP son malos?

React.js proporciona JSX como una sintaxis similar a XHTML para construir un árbol de componentes y elementos. JSX compila a Javascript, y en lugar de proporcionar bucles o condicionales en JSX propiamente dicho, usa Javascript directamente:

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

Lo que aún no he podido explicar es, ¿por qué esto se considera bueno si las construcciones análogas se consideran malas en JSP?

Algo así en JSP

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

se considera un problema de legibilidad que se debe resolver con etiquetas como <c:forEach>. El razonamiento detrás de las etiquetas JSTL también parece que podrían aplicarse a JSX:

• es un poco más fácil de leer cuando no se alterna entre sintaxis tipo XHTML (corchetes angulares, anidamiento) y Java / Javascript (curvas, comas, parens)
• cuando tienes el lenguaje completo y la plataforma disponibles para usar dentro de la función de representación, hay menos para desanimarte de poner lógica que no pertenece allí.

Las únicas razones por las que puedo pensar por qué JSX es diferente es:

• en Java, tenía un incentivo para hacer lo incorrecto: JSP se volvería a cargar en caliente, por lo que era tentador poner código en JSP para evitar un ciclo de reconstrucción / reinicio. La mantenibilidad fue sacrificada por la productividad inmediata. Desterrar los scriptlets y limitarse a un conjunto fijo de construcciones de plantillas fue efectivamente una forma de hacer cumplir la mantenibilidad. No existe tal distorsión en el mundo JS.

• La sintaxis JSP y Java es torpe con el extra <% ... %>para distinguir el código Java de la generación de elementos, y la sintaxis nativa de Java carece de un foreachconcepto o funciones de primera clase (hasta hace poco). La penalización de sintaxis de usar Javascript nativo para bucles y condicionales en JSX no es cero (en mi opinión) pero no es tan malo como JSP, y posiblemente no sea lo suficientemente malo como para justificar la introducción de elementos específicos de JSX para bucles y condicionales.

¿Hay algo más que me estoy perdiendo?

Principalmente, las personas que crearon JSX no estaban de acuerdo con las personas a las que no les gustaba JSP. Vea su discusión aquí: ¿Por qué construimos React? así como mostrar datos

Las plantillas se basan en la idea de crear una división entre la lógica y la presentación de una página. En esta teoría, su código javascript (o java) no debería preocuparse por el marcado que se muestra, y su marcado no debería preocuparse por ninguna de las lógicas involucradas. Esta división es esencialmente la razón por la cual las personas critican los diversos lenguajes de plantillas que permitieron fácilmente mezclar código con su plantilla (PHP / JSP / ASP).

Reaccionar se basa en componentes. Los autores de react argumentan que la lógica y la presentación de un componente están estrechamente conectadas, e intentar dividirlas no tiene ningún sentido. En cambio, una página debe estar dividida por piezas lógicas. Por lo tanto, puede dividir la barra de encabezado, comentarios, publicaciones, preguntas relacionadas, etc. en componentes separados. Pero no tiene sentido tratar de dividir la lógica de las preguntas relacionadas de la presentación.

La principal diferencia entre algo como JSX y algo como JSP es que JSP es un lenguaje de plantilla que incluye un poco de Java para la lógica. JSX es javascript con una extensión de sintaxis para facilitar la construcción de fragmentos de html. El énfasis es diferente. Dado que JSX adopta este enfoque, termina produciendo un enfoque más agradable y limpio que JSP o sus amigos.

Pero en última instancia, se reduce al hecho de que a las personas que reaccionaron no les gustaron las plantillas. Piensan que son una mala idea, y que debes poner tu marcado y lógica de presentación en el mismo lugar.

Como un extraño a React, vi a JSX como otro "olor a marco" en el zoológico muy concurrido de apesta marco. Todavía no estoy convencido de que este no sea el caso.

Creo que una definición viable de "útil" es que una biblioteca / marco / patrón resuelve más problemas de los que causa. Todavía no estoy convencido de que JSX se ajuste a esa definición. Es el proverbial "apretar el globo" ... aplastas un problema aquí, aparece por allá. Para mí, JSX no está resolviendo ningún problema en particular ... es solo "diferente".

La noción de introducir una semántica compilable que necesita un proceso de compilación formalizado es útil en algunas circunstancias: por ejemplo, MENOS compilación de archivos .css proporciona una estructura muy necesaria alrededor de css, que es una estructura jerárquica con importaciones y anulaciones, por lo tanto siendo muy propenso a las "soluciones de espagueti". Pero los precompiladores de Javascript ... no tanto.

En breve:

• Se espera que los desarrolladores front-end conozcan las secuencias de comandos y las plantillas
• JSX y JSP son lenguajes de plantillas
• JavaScript es un lenguaje de script
• Java no es un lenguaje de script

Referencias

• ¿Es perjudicial separar HTML y JavaScript? El | Bitnative de Cory House

• ¿Por qué los scripts se consideran perjudiciales y cómo deshabilitarlos en su programa?

• ¿Cómo evitar el código Java en archivos JSP? - Desbordamiento de pila

Si bien no uso JSX, según su descripción, el trabajo del fragmento JSX es presentar los datos, es decir, es un componente de vista en el lenguaje MVC. Presumiblemente, el fragmento JSX no sabe ni le importa de dónde provienen los datos, que es lo que desea.

Una página JSP bien estructurada solo contendrá directivas JSTL como usted menciona. Las directivas JSTL simplemente simplifican sus JSP para que no estén abarrotados con la obtención del alcance, la comprobación de nulos, etc. Es sorprendente la cantidad de desorden que esto elimina y también lo alienta a mantenerlo ordenado.

Al igual que el fragmento JSX; El único trabajo del JSP debe ser descubrir cómo presentar los datos que ha recibido sin preocuparse de dónde provienen.

En resumen, si su vista es JSX o JSP, si lo está haciendo correctamente, entonces su vista solo presentará datos.

En cuanto a por qué podría cambiar la presentación al cliente en lugar de hacerlo en el servidor, esto le brinda más flexibilidad. Su sitio web puede obtener sus datos a través de servicios web (ReST, por ejemplo) y ser simplemente otro cliente. Si luego decide que desea una aplicación nativa de Android o iOS, pueden consumir el mismo conjunto de servicios web que su sitio web.