Warum ist JSX gut, wenn JSP-Scriptlets schlecht sind?

React.js stellt JSX als XHTML-ähnliche Syntax zum Erstellen eines Baums von Komponenten und Elementen bereit. JSX wird in Javascript kompiliert. Anstatt Schleifen oder Bedingungen in JSX bereitzustellen, verwenden Sie Javascript direkt:

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

Was ich noch nicht erklären konnte, ist, warum dies als gut angesehen wird, wenn analoge Konstrukte in JSP als schlecht angesehen werden?

So etwas in JSP

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

wird als ein Lesbarkeitsproblem angesehen, das mit Tags wie gelöst werden soll <c:forEach>. Die Gründe für JSTL-Tags scheinen auch für JSX zutreffend zu sein:

• Es ist etwas einfacher zu lesen, wenn Sie nicht zwischen XHTML-ähnlicher Syntax (spitze Klammern, Verschachtelung) und Java / Javascript (Curlies, Kommas, Parens) wechseln.
• Wenn Sie die vollständige Sprache und Plattform für die Verwendung innerhalb der Rendering-Funktion zur Verfügung haben, können Sie weniger davon abhalten, Logik einzufügen, die nicht dazu gehört.

Die einzigen Gründe, warum JSX anders ist, sind:

• In Java hatten Sie einen Anreiz, etwas Falsches zu tun - JSP wurde bei laufendem Betrieb neu geladen, daher war es verlockend, Code in JSPs einzufügen, um einen Wiederherstellungs- / Neustartzyklus zu vermeiden. Die Wartbarkeit wurde für die sofortige Produktivität geopfert. Das Bannen von Scriptlets und das Beschränken auf einen festen Satz von Vorlagenkonstrukten war ein wirksames Mittel zur Durchsetzung der Wartbarkeit. In der JS-Welt gibt es keine derartigen Verzerrungen.

• Die JSP- und Java-Syntax ist umständlich <% ... %>, da Java-Code von der Elementgenerierung unterschieden werden kann und die native Java-Syntax foreach(bis vor kurzem) weder ein Konzept noch erstklassige Funktionen enthält. Der Syntaxnachteil bei der Verwendung von nativem Javascript für Schleifen und Bedingungen in JSX ist (meiner Meinung nach) ungleich Null, aber nicht so schlimm wie bei JSP und wahrscheinlich nicht schlimm genug, um die Einführung von JSX-spezifischen Elementen für Schleifen und Bedingungen zu rechtfertigen.

Fehlt mir noch etwas?

Vor allem stimmten die Leute, die JSX erstellt haben, nicht mit den Leuten überein, die JSP nicht mochten. Sehen Sie ihre Diskussion hier: Warum haben wir React gebaut? sowie Anzeigen von Daten

Vorlagen basieren auf der Idee, eine Trennung zwischen der Logik und der Präsentation einer Seite zu erstellen. Nach dieser Theorie sollte sich Ihr Javascript- (oder Java-) Code nicht darum kümmern, welches Markup angezeigt wird, und Ihr Markup sollte sich nicht mit einer der beteiligten Logik befassen. Diese Unterteilung ist im Wesentlichen der Grund, warum die Leute die verschiedenen Vorlagensprachen kritisieren, mit denen Code problemlos in Ihre Vorlage (PHP / JSP / ASP) eingemischt werden konnte.

Reaktion basiert auf Komponenten. Die Autoren von react argumentieren, dass Logik und Darstellung einer Komponente eng miteinander verbunden sind und der Versuch, sie zu teilen, keinen Sinn ergibt. Stattdessen sollte eine Seite durch logische Teile getrennt werden. So können Sie die Kopfzeile, Kommentare, Posts, verwandte Fragen usw. in separate Komponenten aufteilen. Es ist jedoch nicht sinnvoll, die Logik für die zugehörigen Fragen von der Präsentation zu trennen.

Der Hauptunterschied zwischen etwas wie JSX und etwas wie JSP besteht darin, dass JSP eine Vorlagensprache ist, die ein wenig Java für die Logik enthält. JSX ist Javascript mit einer Syntaxerweiterung, um das Erstellen von HTML-Fragmenten zu vereinfachen. Der Schwerpunkt liegt anders. Da JSX diesen Ansatz unterstützt, führt dies zu einem schöneren, saubereren Ansatz als von JSP oder Freunden.

Letztendlich kommt es jedoch darauf an, dass die Leute, die reagierten, keine Vorlagen mochten. Sie halten sie für eine schlechte Idee, und Sie sollten Ihre Markup- und Präsentationslogik an derselben Stelle ablegen.

Als Außenseiter von React betrachtete ich JSX als einen weiteren "Framework-Geruch" im überfüllten Zoo von Framework-Stinks. Ich bin immer noch nicht davon überzeugt, dass dies nicht der Fall ist.

Ich denke, eine brauchbare Definition von "nützlich" ist, dass eine Bibliothek / ein Framework / ein Muster mehr Probleme löst, als es verursacht. Ich bin noch nicht überzeugt, dass JSX zu dieser Definition passt. Es ist das sprichwörtliche "Quetschen des Ballons" ... Sie quetschen hier ein Problem, es taucht dort auf. Für mich löst JSX kein bestimmtes Problem ... es ist nur "anders".

Der Gedanke, eine kompilierbare Semantik einzuführen, die einen formalisierten Erstellungsprozess erfordert, ist unter bestimmten Umständen nützlich: Beispielsweise bietet die WENIGER-Kompilierung von CSS-Dateien eine dringend benötigte Struktur um CSS, eine hierarchische Struktur mit Importen und Überschreibungen sehr anfällig für "Spaghetti-Lösungen". Aber Javascript Pre-Compiler ... nicht so sehr.

Zusamenfassend:

• Von Front-End-Entwicklern wird erwartet, dass sie sich mit Skripten und Vorlagen auskennen
• JSX und JSP sind beide Vorlagensprachen
• JavaScript ist eine Skriptsprache
• Java ist keine Skriptsprache

Verweise

• Ist das Trennen von HTML und JavaScript schädlich? | Bitnative von Cory House

• Warum werden Skripte als schädlich eingestuft und wie können Sie die Skripterstellung in Ihrem Programm deaktivieren?

• Wie vermeide ich Java-Code in JSP-Dateien? - Paketüberfluss

Obwohl ich JSX nicht verwende, besteht die Aufgabe des JSX-Fragments nach Ihrer Beschreibung darin, die Daten zu präsentieren, dh es ist eine Ansichtskomponente im MVC-Sprachgebrauch. Dem JSX-Fragment ist es vermutlich egal, woher die Daten stammen und was Sie wollen.

Eine gut strukturierte JSP-Seite enthält nur die von Ihnen erwähnten JSTL-Anweisungen. JSTL-Direktiven vereinfachen Ihre JSPs nur, damit sie nicht durch Abrufen aus dem Gültigkeitsbereich, Überprüfen auf Null usw. überladen werden. Es ist überraschend, wie viel Unordnung dadurch beseitigt wird, und Sie werden außerdem ermutigt, die Unordnung beizubehalten.

Genau wie das JSX-Fragment; Die einzige Aufgabe der JSP sollte es sein, herauszufinden, wie die empfangenen Daten dargestellt werden können, ohne sich Gedanken darüber zu machen, woher sie stammen.

Zusammenfassend lässt sich sagen, dass Ihre Ansicht, unabhängig davon, ob es sich um JSX oder JSP handelt, bei ordnungsgemäßer Ausführung nur Daten darstellt.

Dies gibt Ihnen mehr Flexibilität, warum Sie die Präsentation möglicherweise auf den Client verlagern, anstatt sie auf dem Server auszuführen. Ihre Website kann ihre Daten über Webservices (zum Beispiel ReST) abrufen und nur ein weiterer Kunde sein. Wenn Sie sich später für eine native Android- oder iOS-App entscheiden, können diese dieselben Webdienste wie Ihre Website nutzen.