Perché JSX è buono, quando gli scriptlet JSP sono cattivi?

React.js fornisce JSX come una sintassi simile a XHTML per la costruzione di un albero di componenti ed elementi. JSX si compila in Javascript e invece di fornire loop o condizionali in JSX, si utilizza direttamente Javascript:

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

Ciò che non sono stato ancora in grado di spiegare è, perché questo è considerato buono se costrutti analoghi sono considerati cattivi in ​​JSP?

Qualcosa del genere in JSP

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

è considerato un problema di leggibilità da risolvere con tag come <c:forEach>. Il ragionamento dietro i tag JSTL sembra anche che potrebbero applicarsi a JSX:

• è un po 'più semplice da leggere quando non si alternano sintassi simili a XHTML (parentesi angolari, annidamento) e Java / Javascript (ricci, virgole, parentesi)
• quando hai la lingua e la piattaforma complete disponibili per l'uso all'interno della funzione di rendering, c'è meno per scoraggiarti dal mettere la logica in quella che non vi appartiene.

Le uniche ragioni per cui riesco a pensare al perché JSX è diverso sono:

• in Java, hai avuto un incentivo a fare la cosa sbagliata: JSP sarebbe stato ricaricato a caldo, quindi era allettante inserire codice in JSP per evitare un ciclo di ricostruzione / riavvio. La manutenzione è stata sacrificata per una produttività immediata. Bandire gli scriptlet e limitarsi a un insieme fisso di costrutti modello era effettivamente un modo per far rispettare la manutenibilità. Nessuna tale distorsione esiste nel mondo JS.

• La sintassi JSP e Java è goffa con il supplemento <% ... %>per distinguere il codice Java dalla generazione di elementi e con la sintassi nativa di Java priva di un foreachconcetto o di funzioni di prima classe (fino a poco tempo fa). La penalità della sintassi dell'uso di Javascript nativo per loop e condizionali in JSX è diversa da zero (a mio avviso) ma non così grave come JSP, e probabilmente non abbastanza grave da giustificare l'introduzione di elementi specifici di JSX per loop e condizionali.

C'è qualcos'altro che mi manca?

In primo luogo, le persone che hanno creato JSX non erano d'accordo con le persone a cui non piaceva JSP. Vedi la loro discussione qui: Perché abbiamo costruito React? così come la visualizzazione dei dati

I modelli si basano sull'idea di creare una divisione tra la logica e la presentazione di una pagina. In base a questa teoria, il codice javascript (o java) non dovrebbe riguardare il markup visualizzato e il markup non dovrebbe riguardare nessuna delle logiche coinvolte. Questa divisione è essenzialmente il motivo per cui le persone criticano i vari linguaggi di template che hanno prontamente permesso di mescolare il codice con il tuo template (PHP / JSP / ASP).

React si basa sui componenti. Gli autori di reazioni sostengono che la logica e la presentazione di un componente sono strettamente connesse e il tentativo di dividerle non ha alcun senso. Invece, una pagina dovrebbe essere rotta da pezzi logici. Quindi potresti suddividere la barra di intestazione, i commenti, i post, le domande correlate, ecc. In componenti separati. Ma non ha senso cercare di dividere la logica per le domande correlate dalla presentazione.

La differenza principale tra qualcosa come JSX e qualcosa come JSP è che JSP è un linguaggio modello che include un po 'di java per la logica. JSX è javascript con un'estensione di sintassi per facilitare la costruzione di frammenti di HTML. L'enfasi è diversa. Dal momento che JSX abbraccia questo approccio, finisce per produrre un approccio più bello e più pulito, poi fatto da JSP o dagli amici.

Ma alla fine, dipende dal fatto che alle persone che hanno fatto la reazione non sono piaciuti i modelli. Pensano di essere una cattiva idea e che dovresti mettere la tua logica di markup e presentazione nello stesso posto.

Come estraneo a React, ho visto JSX come l'ennesimo "odore di struttura" nello zoo molto affollato di puzzi di struttura. Non sono ancora convinto che non sia così.

Penso che una definizione praticabile di "utile" sia che una libreria / framework / pattern risolva più problemi di quanti ne causi. Non sono ancora convinto che JSX si adatti a tale definizione. È il proverbiale "spremere il palloncino" ... si schiaccia un problema qui, si apre laggiù. Per me, JSX non sta risolvendo alcun problema particolare ... è solo "diverso".

L'idea di introdurre una semantica compilabile che necessita di un processo di compilazione formalizzato è utile in alcune circostanze: ad esempio, MENO la compilazione di file .css fornisce una struttura molto necessaria attorno a css, che è una struttura gerarchica con importazioni e sostituzioni, quindi essendo molto incline a "soluzioni di spaghetti". Ma i pre-compilatori Javascript ... non così tanto.

In breve:

• Gli sviluppatori front-end dovrebbero conoscere scripting e template
• JSX e JSP sono entrambi linguaggi di template
• JavaScript è un linguaggio di scripting
• Java non è un linguaggio di scripting

Riferimenti

• La separazione di HTML e JavaScript è dannosa? | Bitnative di Cory House

• Perché gli script sono considerati dannosi e come disabilitarli nel programma?

• Come evitare il codice Java nei file JSP? - Stack Overflow

Anche se non uso JSX, in base alla tua descrizione, il compito del frammento JSX è presentare i dati, ovvero è un componente di visualizzazione nel linguaggio MVC. Il frammento JSX presumibilmente non sa né cura da dove provengono i dati, qual è ciò che desideri.

Una pagina JSP ben strutturata conterrà solo le direttive JSTL come dici tu. Le direttive JSTL semplificano semplicemente i tuoi JSP in modo che non siano ingombri di recupero dall'ambito, controllo di null, ecc. È sorprendente la quantità di disordine che rimuove e ti incoraggia anche a mantenerlo declassato.

Proprio come il frammento JSX; l'unico compito del JSP dovrebbe essere quello di capire come presentare i dati che ha ricevuto senza preoccuparsi della sua provenienza.

In sintesi, se la tua vista è JSX o JSP, se lo stai facendo correttamente, la vista presenterà solo i dati.

Per quanto riguarda il motivo per cui potresti spostare la presentazione sul client invece di farlo sul server, questo ti dà maggiore flessibilità. Il tuo sito web può ottenere i suoi dati tramite servizi web (ad esempio ReST) ed essere solo un altro client. Se in seguito decidi di volere un'app nativa per Android o iOS, possono utilizzare lo stesso set di servizi Web del tuo sito web.