Por que o JSX é bom, quando os scriptlets JSP são ruins?

O React.js fornece JSX como uma sintaxe semelhante ao XHTML para construir uma árvore de componentes e elementos. O JSX é compilado no Javascript e, em vez de fornecer loops ou condicionais no JSX propriamente dito, você usa o Javascript diretamente:

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

O que ainda não consegui explicar é: por que isso é considerado bom se construções análogas são consideradas ruins no JSP?

Algo assim em JSP

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

é considerado um problema de legibilidade a ser resolvido com tags como <c:forEach>. O raciocínio por trás das tags JSTL também parece que eles poderiam se aplicar ao JSX:

• é um pouco mais fácil de ler quando você não está alternando entre sintaxe do tipo XHTML (colchetes angulares, aninhamento) e Java / Javascript (curvas, vírgulas, parênteses)
• quando você tem o idioma e a plataforma completos disponíveis para uso dentro da função de renderização, há menos para desencorajá-lo a inserir lógica que não pertence a ele.

As únicas razões pelas quais consigo pensar por que o JSX é diferente é:

• em Java, você tinha um incentivo para fazer a coisa errada - o JSP seria recarregado a quente, por isso era tentador colocar código em JSPs para evitar um ciclo de reconstrução / reinicialização. A capacidade de manutenção foi sacrificada para produtividade imediata. O banimento de scriptlets e a limitação a um conjunto fixo de construções de modelos eram efetivamente uma maneira de reforçar a manutenção. Nenhuma distorção existe no mundo das JS.

• A sintaxe JSP e Java é desajeitada com o extra <% ... %>para distinguir o código Java da geração de elementos e com a sintaxe nativa do Java sem um foreachconceito ou funções de primeira classe (até recentemente). A penalidade de sintaxe do uso de Javascript nativo para loops e condicionais em JSX é diferente de zero (na minha opinião), mas não é tão ruim quanto JSP e, possivelmente, não é ruim o suficiente para justificar a introdução de elementos específicos de JSX para loops e condicionais.

Há algo mais que estou perdendo?

Principalmente, as pessoas que criaram o JSX discordavam das pessoas que não gostavam do JSP. Veja a discussão deles aqui: Por que criamos o React? bem como exibir dados

Modelos é baseado na idéia de criar uma divisão entre a lógica e a apresentação de uma página. Nesta teoria, seu código javascript (ou java) não deve se preocupar com a marcação exibida, e sua marcação não deve se preocupar com nenhuma das lógicas envolvidas. Essa divisão é essencialmente o motivo pelo qual as pessoas criticam as várias linguagens de modelo que prontamente permitiram misturar código com o seu modelo (PHP / JSP / ASP).

A reação é baseada em componentes. Os autores da reação argumentam que a lógica e a apresentação de um componente estão fortemente conectadas, e tentar dividi-las não faz sentido. Em vez disso, uma página deve ser quebrada por partes lógicas. Portanto, você pode dividir a barra de cabeçalho, comentários, postagens, perguntas relacionadas etc. em componentes separados. Mas não faz sentido tentar dividir a lógica das questões relacionadas da apresentação.

A principal diferença entre algo como JSX e algo como JSP é que JSP é uma linguagem de modelo que inclui um pouco de java para a lógica. JSX é javascript com uma extensão de sintaxe para facilitar a construção de fragmentos de html. A ênfase é diferente. Como o JSX adota essa abordagem, ela acaba produzindo uma abordagem mais agradável e mais limpa do que o JSP ou os amigos.

Mas, no final das contas, tudo se resume ao fato de as pessoas que fizeram a reação não gostarem de modelos. Eles acham que é uma má ideia e que você deve colocar sua lógica de marcação e apresentação no mesmo local.

Como alguém de fora do React, eu via o JSX como mais um "cheiro de estrutura" no zoológico muito lotado de fedores de estrutura. Ainda não estou convencido de que não seja esse o caso.

Acho que uma definição viável de "útil" é que uma biblioteca / estrutura / padrão resolve mais problemas do que causa. Ainda não estou convencido de que o JSX se encaixe nessa definição. É o proverbial "apertar o balão" ... você esmaga um problema aqui, ele aparece lá. Para mim, o JSX não está resolvendo nenhum problema específico ... é apenas "diferente".

A noção de introdução de uma semântica compilável que precisa de um processo formal de construção é útil em algumas circunstâncias: por exemplo, a compilação MENOS de arquivos .css fornece uma estrutura muito necessária em torno do css, que é uma estrutura hierárquica com importações e substituições, portanto sendo muito propenso a "soluções de espaguete". Mas pré-compiladores Javascript ... nem tanto.

Em resumo:

• Espera-se que os desenvolvedores front-end conheçam scripts e modelos
• JSX e JSP são linguagens de modelos
• JavaScript é uma linguagem de script
• Java não é uma linguagem de script

Referências

• Separar HTML e JavaScript é prejudicial? | Bitnative por Cory House

• Por que os scripts são considerados prejudiciais e como desativar o script no seu programa?

• Como evitar o código Java nos arquivos JSP? - Estouro de pilha

Embora eu não use o JSX, com base na sua descrição, o trabalho do fragmento JSX é apresentar os dados, ou seja, é um componente de exibição no jargão MVC. O fragmento JSX presumivelmente não sabe nem se importa de onde os dados vieram e é o que você deseja.

Uma página JSP bem estruturada conterá apenas diretivas JSTL como você mencionou. As diretivas JSTL simplificam suas JSPs para que não sejam confusas com a busca no escopo, a verificação de nulos, etc.

Assim como o fragmento JSX; o único trabalho do JSP deve ser descobrir como apresentar os dados que recebeu sem se preocupar com a origem.

Em resumo, se sua visualização é JSX ou JSP, se você estiver fazendo isso corretamente, sua visualização apresentará apenas dados.

Por que você pode mudar a apresentação para o cliente em vez de fazê-lo no servidor, isso oferece mais flexibilidade. Seu site pode obter seus dados por meio de serviços da web (ReST, por exemplo) e ser apenas mais um cliente. Se você decidir posteriormente que deseja um aplicativo nativo para Android ou iOS, eles poderão consumir o mesmo conjunto de serviços da Web que o seu site.