Quando JavaScript dovrebbe generare HTML?

Cerco di generare il meno HTML possibile da JavaScript. Preferisco invece manipolare il markup esistente ogni volta che posso e generare HTML solo quando devo inserire dinamicamente un elemento che non è un buon candidato per usare Ajax. Questo, credo, rende molto più semplice la manutenzione del codice e la modifica rapida perché il markup è più facile da leggere e tracciare. La mia regola empirica è: HTML è per la struttura del documento, CSS è per la presentazione, JavaScript è per il comportamento.

Tuttavia, ho visto molto codice JS che genera cumuli di HTML, inclusi moduli interi e dialoghi modali ricchi di contenuti. In generale, quale metodo è considerato la migliore pratica? In quali circostanze dovrebbe essere usato JavaScript per generare HTML e quando no?

Ogni volta che ho riscontrato una forte generazione di HTML in javascript, era quasi esclusivamente in un plug-in dell'interfaccia utente autonomo. Ha senso, in quanto consente di incapsulare l'intero plug-in in un singolo file .js (+ a .css per personalizzare gli stili), rendendolo quindi facilmente riutilizzabile, distribuibile e indipendente dal framework utilizzato nell'applicazione.

Quindi, se stai scrivendo un plug-in javascript autonomo o un componente generico dell'interfaccia utente che desideri utilizzare in diverse applicazioni, tale approccio ha i suoi lati positivi. Altrimenti, penso che sia più pulito, più facile da scrivere e più facile da mantenere quando tieni la generazione di html lontana da javascript e sul lato server.

Penso che il problema sia che stai confrontando il modello lato server scritto in modo pulito con la generazione HTML lato client ad hoc scritta male. Naturalmente il codice scritto in modo pulito è più facile da leggere, mantenere e tracciare.

Chiami il codice lato client "tumuli di HTML", ma ovviamente è lo stesso HTML ovunque venga generato. Il "tumulo" è davvero il grosso pezzo di codice.

Esistono molte librerie di template lato client. Funzionano in modo simile a quelli lato server. Per quanto dovresti preferire, il compromesso delle prestazioni è complicato, ma JSON è generalmente più compatto dell'HTML che diventa e avere il modello sul client può eliminare alcune chiamate al server. D'altra parte, il client potrebbe avere JS disabilitato o essere troppo lento per essere pratico, quindi dipende anche dal tuo pubblico di destinazione. Nel complesso, penso che gli approcci siano abbastanza comparabili, con il fattore più grande sono le funzionalità del browser del tuo pubblico di destinazione.

Ma dipende esattamente da cosa stai facendo, se preferisci JS al tuo ambiente server, quale soluzione di template preferisci, ecc.

Vi è una tendenza a utilizzare i modelli sul lato client, in casi estremi si avrebbe server che fornisce solo API RESTful, ad esempio in formato JSON, mentre si esegue tutto il rendering lato client. Il vantaggio di questo approccio è che il codice JS e i modelli sono risorse statiche che possono essere memorizzate nella cache, inoltrate tramite proxy e distribuite tramite CDN. Il che non può essere fatto se si dispone di HTML dinamico generato sul lato server. Inoltre, la restituzione dei soli dati dall'API RESTful in formato leggero utilizza molte meno risorse sul lato server, rendendo più rapida la risposta. Inoltre, essendo più leggero, riduce il trasferimento di rete, il che lo rende ancora più veloce. In questo modo puoi avere un'applicazione a bassa latenza molto reattiva anche su connessioni lente come 3G. Pertanto, questo approccio è popolare per le pagine e le applicazioni mobili.

Ci sono numerose librerie che implementano modelli JS, uno di quelli più popolari sono puro , Baffi e dust.js . Successivamente viene utilizzato da LinkedIn, hanno descritto i vantaggi nel loro articolo "Lasciando JSP nella polvere: spostare LinkedIn in modelli lato client dust.js" .

Il vantaggio di generare HTML sul client, è scaricare il lavoro di rendering su ciascun client, che rimane generalmente inattivo in attesa della risposta. Liberare più risorse del server per fornire solo dati JSON e contenuto statico (HTML, JS e CSS).

Realizziamo un'app Web che genera esclusivamente HTML con Javascript. L'87% degli accessi al server sono dati JSON, il contenuto statico viene generalmente caricato una volta, quindi dalla cache del browser.

Ma non puoi usarlo - almeno non facilmente - se hai bisogno di SEO. O se scegli come target una popolazione con Javascript disabilitato, ma non sono sicuro che questo sia ancora rilevante con Youtube, Twitter, Facebook, Gmail, ... forzando naturalmente le persone ad abilitarlo.

Per quanto riguarda il caricamento dinamico della pagina, ci si dovrebbe rendere conto che dietro tutto il "JQuery AJAX Cloud!" magia, stanno accadendo solo due cose possibili:

1. Il codice di un elemento viene iniettato in un div (errato), oppure
2. Il contenuto viene caricato in un iframe (meglio, ma non è lo stesso ...)

Per quanto riguarda la domanda originale, creo contenuti HTML tramite Javascript solo quando creo un'app Web di qualche tipo che legge dati XML o JSON memorizzati sul server e viene cambiata molto.

Non avrebbe molto senso caricare contenuti statici su una pagina con Javascript, dato che esiste sempre la possibilità che non vengano caricati correttamente o che il client lo disabiliti ("prendi quelle fastidiose pubblicità!"). Inoltre, rende davvero difficile cambiare il contenuto HTML quando è nascosto in un brutto document.write()o una catena di document.createElement().

Quindi hai ragione; digitare l'HTML non elaborato o, se è necessario il contenuto dinamico, utilizzare uno script sul lato server per generare ciò che è necessario. Usa Javascript per iniettare HTML solo se il sito deve funzionare senza una connessione Internet o un caso simile.

Un'ultima nota, se si desidera implementare xmlhttprequests, er, AJAX, in un sito Web, probabilmente il modo migliore / più sicuro per farlo è archiviare i dati in un formato di dati (come XML), caricarli e produrli di conseguenza sul client. document.writee element.innerHTMLnon è davvero il modo migliore per manipolare il contenuto ed è destinato a causare potenziali mal di testa in futuro (perché questo script non è in esecuzione? Il mio <i>tag non funzionante è in corsivo tutto! ecc.).

Il mio mantra è: quando è più facile e nessuno si preoccupa del markup.

Puoi anche sfruttare entrambi e definire un limite in cui è troppo difficile prendersi cura del markup e preferiresti concentrarti sull'albero DOM. Ad esempio, un modulo con righe dinamiche (ad esempio "aggiungi un altro allegato"), probabilmente vorrai il modulo in HTML, il pulsante "aggiungi riga" e il pulsante di invio ... probabilmente non vuoi generare l'HTML con la tua lingua lato server o qualcosa del genere.

Un'altra regola empirica può essere la riusabilità. Se la tua soluzione può essere applicata ad altri problemi sul lato client, incapsulala in js.

Costruiamo app per pagina singola (ala Google Mail) e non c'è letteralmente alcuna generazione di HTML lato server nelle nostre app. Invece stiamo usando Backbone.js per strutturare il nostro lato client e il manubrio per rendere il nostro JSON in modelli che vanno nella pagina. Funziona davvero molto bene e stiamo arrivando alla fine della nostra prima app che la utilizza e affronteremo un progetto ancora più grande in futuro.

Qualsiasi tipo di client fat in cui il server viene utilizzato solo per conservare i dati e restituire i risultati delle query è un bambino poster per un periodo in cui si desidera che JavaScript generi HTML. Assicurati di utilizzare un buon motore di template per renderlo semplice e pulito.

Sto generando codice html in jquery perché sto usando un portlet e dopo l'esecuzione del codice jsp, ho bisogno di creare un ciclo con codice html, che non riesco a ottenere in un java per il ciclo con un codice javascript all'interno. Quindi sto eseguendo il rendering dell'arraylist java in un array javascript e l'utilizzo delle stringhe per generare html.