Quando JavaScript dovrebbe generare HTML?

Ogni volta che ho incontrato una generazione HTML pesante in javascript, era quasi esclusivamente un plug-in UI stand-alone. Ha senso, poiché consente di incapsulare l'intero plug-in in un singolo file .js (+ a .css per personalizzare gli stili), rendendolo così facilmente riutilizzabile, distribuibile e indipendente dal framework utilizzato nell'applicazione.

Quindi, se stai scrivendo un plugin javascript standalone o una componente generica della UI che vorresti usare in diverse applicazioni, un simile approccio ha i suoi lati positivi. Altrimenti, penso che sia sia più pulito, più facile da scrivere e più facile da mantenere quando mantieni la generazione di HTML lontano da javascript e dal lato server.

Penso che il problema sia che si stanno confrontando template server scritti in modo pulito per la generazione di HTML lato client ad hoc scritto male. Ovviamente il codice scritto in modo pulito è più facile da leggere, conservare e tracciare.

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

Là fuori ci sono molte librerie di template per client side. Funzionano in modo simile a quelli laterali del server. Per quanto riguarda ciò che si preferisce, il compromesso delle prestazioni è complicato, ma JSON è solitamente più compatto rispetto all'HTML e con il modello sul client può eliminare alcune chiamate al server. D'altra parte, il client può avere disabilitato JS, o essere troppo lento per essere pratico, quindi dipende anche dal pubblico di destinazione. Nel complesso, ritengo che gli approcci siano abbastanza comparabili, con il fattore più importante delle capacità del browser del tuo pubblico di destinazione.

Ma dipende esattamente da quello che stai facendo, che tu preferisca JS al tuo ambiente server, quale soluzione di template preferisci, ecc.

C'è una tendenza ad usare i template lato client, in caso estremo avresti server che fornisce solo API RESTful, ad esempio in formato JSON, mentre esegui tutto il lato client di rendering. Il vantaggio di tale approccio è che il codice JS ei modelli sono risorse statiche che possono essere memorizzate nella cache, inoltrate e distribuite tramite CDN. Quale non può essere fatto se hai HTML dinamico generato lato server. Inoltre, la restituzione dei soli dati dall'API RESTful in formato leggero utilizza molte meno risorse lato server, rendendo la risposta più rapida. Inoltre, essendo più leggero è meno il trasferimento di rete, che rende ancora più veloce. In questo modo puoi avere un'applicazione a bassa latenza molto reattiva anche su connessioni lente come 3G. Quindi questo approccio è popolare per le pagine e le applicazioni mobili.

Esistono numerose librerie che implementano i modelli JS, uno dei più popolari è Pure , Moustache e dust.js . In seguito viene utilizzato da LinkedIn, hanno descritto i vantaggi nel loro articolo " Lasciando i JSP nella polvere: spostando LinkedIn in modelli client.kash di dust.js " .

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

Facciamo un'app Web che genera esclusivamente HTML con Javascript. L'87% dei colpi del 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 che ha Javascript disabilitato, ma non sono sicuro che questo sia ancora rilevante con Youtube, Twitter, Facebook, Gmail, ... costringendo naturalmente le persone ad abilitarlo.

Per quanto riguarda il caricamento dinamico delle pagine, è necessario rendersi 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 (cattivo) o
2. Il contenuto viene caricato in un iframe (meglio, ma non è lo stesso ...)

Riguardo alla domanda originale, creo solo contenuto HTML tramite Javascript quando creo un'applicazione web di qualche tipo che legge dati XML o JSON memorizzati sul server, e viene cambiata molto.

Non avrebbe molto senso caricare il contenuto statico su una pagina con Javascript, poiché c'è sempre la possibilità che non si carichi a destra, altrimenti il client lo disabiliterà ("prendi quegli annunci fastidiosi!"). Inoltre, rende davvero difficile modificare il contenuto HTML quando è immerso in un brutto document.write() o in una catena di document.createElement() .

Quindi hai ragione; o scrivi l'HTML grezzo, oppure se è necessario il contenuto di dynamic-ish, usa uno script lato server per produrre ciò che è necessario. Usa Javascript per iniettare HTML solo se il sito è pensato per funzionare senza una connessione Internet o un caso simile.

Un'ultima nota, se vuoi implementare xmlhttprequests, er, AJAX, in un sito web, probabilmente il modo migliore / più sicuro per farlo è archiviare i dati in un formato dati (come XML), caricarlo e emetterlo di conseguenza sul client. document.write e element.innerHTML in realtà non è 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 tag <i> è in corsivo tutto! .).

Il mio mantra su questo è: quando è più facile e a nessuno interessa il markup.

Puoi anche sfruttare entrambi e definire un limite in cui è troppo difficile preoccuparsi del markup e preferisci 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 soluzione può essere applicata ad altri problemi sul lato client, incapsulala in js.

Costruiamo app a pagina singola (ala Google Mail) e non esiste letteralmente nessuna generazione di codice HTML lato server nelle nostre app. Invece stiamo usando Backbone.js per strutturare il nostro lato client e Handlebars per rendere il nostro JSON in modelli che vanno nella pagina. Funziona molto bene e stiamo arrivando alla conclusione della nostra prima app che la usa e affronteremo un progetto ancora più grande in futuro.

Qualsiasi tipo di fat client in cui il server viene utilizzato solo per mantenere i dati e restituire i risultati delle query è un poster per un periodo in cui desideri che JavaScript generi HTML. Assicurati di utilizzare un motore di template valido per renderlo pulito e facile.

Sto generando un 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 riesca a entrare in un ciclo java for con qualche codice javascript all'interno . Così sto riproducendo java arraylist in un array javascript e usando le stringhe per generare html.