Почему JSX хорош, когда JSP скриптлеты плохи?

React.js предоставляет JSX в виде XHTML-подобного синтаксиса для построения дерева компонентов и элементов. 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 (curlies, запятые, parens)
• когда у вас есть полный язык и платформа, доступные для использования внутри функции рендеринга, есть меньше, чтобы отговорить вас от использования логики, которой там не место.

Единственные причины, по которым я могу думать, почему JSX отличается:

• в Java у вас был стимул сделать что-то не то - JSP был бы перегружен, поэтому было заманчиво поместить код в JSP, чтобы избежать цикла перестроения / перезапуска. Ремонтопригодность была принесена в жертву для немедленной производительности. Изгнание скриптлетов и ограничение фиксированного набора шаблонных конструкций было эффективным способом обеспечения возможности сопровождения. В мире JS такого искажения не существует.

• Синтаксис JSP и Java не совсем удобен, <% ... %>чтобы отличать Java-код от генерации элементов, а в родном синтаксисе Java отсутствует foreachконцепция или первоклассные функции (до недавнего времени). Синтаксическое наказание за использование нативного Javascript для циклов и условных выражений в JSX является ненулевым (на мой взгляд), но не таким плохим, как JSP, и, возможно, не настолько плохим, чтобы оправдать введение специфичных для JSX элементов для циклов и условных выражений.

Что-то еще мне не хватает?

Прежде всего, люди, которые создали JSX, не согласились с людьми, которые не любили JSP. Смотрите их обсуждение здесь: Почему мы создали React? а также отображение данных

Шаблоны основаны на идее создания разделения между логикой и представлением страницы. Согласно этой теории, ваш javascript-код (или java-код) не должен интересоваться отображаемой разметкой, а ваша разметка не должна касаться какой-либо логики. Это разделение, по сути, является причиной того, что люди критикуют различные языки шаблонов, которые с готовностью позволяют смешивать код с вашим шаблоном (PHP / JSP / ASP).

Реакт основан на компонентах. Авторы реакции утверждают, что логика и представление компонента тесно связаны, и попытка разделить их не имеет никакого смысла. Вместо этого страница должна быть разбита на логические части. Таким образом, вы можете разбить панель заголовков, комментарии, сообщения, связанные вопросы и т. Д. На отдельные компоненты. Но не имеет смысла пытаться отделить логику связанных вопросов от презентации.

Основное различие между чем-то вроде JSX и чем-то вроде JSP заключается в том, что JSP - это язык шаблонов, который включает немного java для логики. JSX - это javascript с расширением синтаксиса, позволяющий легко создавать фрагменты html. Акцент другой. Поскольку JSX использует этот подход, он в итоге дает более приятный и чистый подход, чем JSP или его друзья.

Но в конечном итоге все сводится к тому, что люди, которые реагировали, не любили шаблоны. Они думают, что это плохая идея, и что вы должны поместить свою разметку и логику представления в одно и то же место.

Как сторонник React, я рассматривал JSX как еще один «запах фреймворка» в очень переполненном зоопарке вонючих фреймворков. Я до сих пор не уверен, что это не так.

Я думаю, что работоспособное определение «полезного» состоит в том, что библиотека / фреймворк / шаблон решает больше проблем, чем вызывает. Я еще не уверен, что JSX соответствует этому определению. Это общеизвестный «сдавливание воздушного шара» ... вы решаете проблему здесь, она появляется там. Для меня JSX не решает какую-то конкретную проблему ... он просто "другой".

Идея введения скомпилируемой семантики, которая требует формализованного процесса сборки, полезна в некоторых обстоятельствах: например, LESS-компиляция файлов .css обеспечивает некоторую крайне необходимую структуру вокруг css, которая представляет собой иерархическую структуру с импортом и переопределением, таким образом будучи очень склонным к "решениям для спагетти". Но прекомпиляторы Javascript ... не так уж и много.

Короче говоря:

• Ожидается, что фронтенд-разработчики будут знать скрипты и шаблоны
• JSX и JSP являются языками шаблонов
• JavaScript это язык сценариев
• Java не является языком сценариев

Ссылки

• Вредно ли разделение HTML и JavaScript? | Bitnative от Cory House

• Почему скрипты считаются вредными и как отключить скрипты в вашей программе?

• Как избежать Java-кода в файлах JSP? - Переполнение стека

Хотя я не использую JSX, основываясь на вашем описании, работа фрагмента JSX состоит в представлении данных, то есть это компонент представления на языке MVC. Фрагмент JSX, по-видимому, не знает и не заботится о том, откуда поступили данные, что вам нужно.

Хорошо структурированная JSP-страница будет содержать директивы JSTL, о которых вы упомянули. Директивы JSTL просто упрощают ваши JSP, так что они не загромождаются извлечением из области, проверкой на ноль и т. Д. Удивительно, насколько много беспорядка это удаляет, и это также побуждает вас сохранять его в беспорядке.

Так же, как фрагмент JSX; единственной задачей JSP должно быть выяснение того, как представлять полученные данные, не беспокоясь о том, откуда они поступили.

Таким образом, независимо от того, является ли ваше представление JSX или JSP, если вы делаете это правильно, то ваше представление просто представит данные.

Что касается того, почему вы можете перенести презентацию на клиент вместо того, чтобы делать это на сервере, это дает вам больше гибкости. Ваш веб-сайт может получать свои данные через веб-сервисы (например, ReST) и быть просто другим клиентом. Если позже вы решите, что хотите использовать нативное приложение для Android или iOS, они могут использовать тот же набор веб-служб, что и ваш веб-сайт.