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

21

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?

javascript readability jsp reactjs wrschneider
fuente
1
No creo que sea malo tener bucles en su JSP per se, el problema es incrustar código en las etiquetas de scriptlet. Si los elimina y usa JSTL, se verá obligado a simplificar sus JSP. Además, como usted señala, una ventaja adicional es que la sintaxis JSTL es un poco menos discordante que la sintaxis de scriptlet. Si bien no estoy familiarizado con JSX, supongo que probablemente podría abusar de los fragmentos JSX con mucha lógica enrevesada que no se recomendaría pero que no evitará.
PhilDin

Respuestas:

11

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.

Winston Ewert
fuente
No me quejo de encapsular la renderfunción en el mismo lugar que la lógica de otros componentes. Estoy estrictamente preocupado por la legibilidad de mezclar la generación de elementos con otros tipos de código.
wrschneider
@wrschneider, ¿en qué se renderdiferencia una función de reacción en los tipos de código que se mezclan con el típico lenguaje de plantilla?
Winston Ewert
3

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.

dwoz
fuente
"Una definición viable de útil es ...", ese es un gran punto. Y sí, JSX resuelve más problemas de lo que pensamos. El componente React view es más simple y expresivo con JSX. Puede ser unitario comprobable con renderizado superficial. Si dice olor, JSP tiene olores y tiene más posibilidades de errores. Y no soy agnest jsp.
Sagar
Lo siento, pero no veo cómo esto responde la pregunta.
sleske
Sleske, los devotos de la crítica literaria lo llamarían una "lectura interna" de la pregunta. La pregunta en la superficie pide una comparación, pero en el interior se trata de marcos. Mi respuesta aborda el concepto de "marcos que resuelven más problemas de los que causan". El OP podría tomar mi comentario, aplicar ese credo a su situación particular y única, y decidir si JSX es una ayuda o un obstáculo. Se podría decir que su estado de cuenta plantea la cuestión de si hay una deficiencia en la respuesta o una deficiencia en su comprensión, ya que ninguno de estos problemas podría provocar que el resultado exacto
dwoz
0

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.

PhilDin
fuente
Tenga en cuenta que JSX se puede usar del lado del cliente o del lado del servidor. La manera elegante de usar JSX es representar los controles iniciales en el servidor y luego realizar actualizaciones DOM (en respuesta a las llamadas de servicio) del lado del cliente. De todos modos, tiene razón en que React es la capa de vista ( citando Facebook : "Mucha gente usa React como V en MVC").
Brian
La pregunta específica es por qué React / JSX considera que es bueno usar la sintaxis nativa de Javascript para bucles / condicionales, mientras que JSP eliminó la sintaxis (scriptlets) nativa de Java.
wrschneider
Lo siento, perdí ese punto. Comencé a componer una respuesta, pero luego me di cuenta de que era simplemente un caso de "su suposición es tan buena como la mía". Una buena sintaxis de capa de presentación para JSX podría ser útil, solo puedo suponer que esto fue importante para los diseñadores de Java y no para los diseñadores de JSX.
PhilDin