È una buona idea che gli oggetti JS si disegnino da soli quando viene caricata la pagina?

0

Quindi normalmente userei JS solo per modificare il dom dopo che l'utente interagisce con qualcosa o qualche evento si spegne. Questo sembra giusto per qualche ragione.

Ma sto sviluppando un'applicazione basata su widget in cui i widget hanno la capacità di disegnare (stampare) se stessi e ritiene ridondante inviare l'html del widget tramite la richiesta http iniziale quando posso semplicemente stamparli con il metodo js quando la pagina carichi.

Dovrei cercare di evitare la stampa di elementi HTML con JS sul caricamento della pagina come regola o è solo una cosa di ottimizzazione?

    
posta slicedtoad 07.07.2014 - 21:18
fonte

2 risposte

2

Dipende.

A meno che le prestazioni lato client non siano osservabili, concentrarsi sulla manutenibilità.

Ciò significa che idealmente vuoi che la traduzione dai dati al markup / DOM sia consolidata. Non vuoi due o tre oggetti diversi, in particolare seduti in due o tre lingue diverse, ognuno dei quali è responsabile della produzione della stessa struttura DOM.

Se il tuo script sul lato client fornisce un miglioramento progressivo o ha bisogno di essere eseguibile per la ricerca per indicizzazione / in grado di graffiare / googleable, esegue il rendering del lato server HTML. Scrivi i componenti lato server in modo altamente modulare: puoi richiedere nuovi markup per un singolo componente in modo rapido e semplice. E dipendono il meno possibile dalla manipolazione diretta del DOM da parte del cliente.

In alternativa, se la tua app è "altamente interattiva" o dipendente dallo script sul lato client, il server probabilmente non ha bisogno di sapere nulla sul markup / DOM finale relativo a questi componenti interattivi. Invia markup "nudo", XML o JSON per la tua libreria JavaScript da consumare e visualizzare.

Non perdere tempo a ottimizzare le prestazioni di rendering lato client a meno che non si tratti di un problema noto.

Se hai dubbi e anche se non lo fai, modella la tua app dopo un'altra app di successo simile. Apri il profilo di rete del tuo browser e guarda cosa succede sul filo e quando.

Personalmente, mi sono occupato della costruzione DOM lato client e ho scoperto che anche i dispositivi più antichi, con browser moderni, funzionano perfettamente usando questa strategia. L'onere di mantenere il mio codice lato client e il codice lato server è notevolmente ridotto.

    
risposta data 07.07.2014 - 22:21
fonte
4

Per coloro che cercano la risposta rapida

Evitare di scrivere qualsiasi cosa che modifichi il JS DOM è sempre una buona pratica, a meno che tu non abbia una buona padronanza su esattamente ciò che è o non sta andando nella pagina, probabilmente ti imbatterai in un sacco di problemi.

Se desideri una risposta più lunga, continua a leggere

A meno che il codice e l'html non siano incapsulati nella nuova architettura del componente Web, quando invochi uno dei vari metodi di output JS, è probabile che modifichi qualsiasi cosa dipenda dal resto del flusso della pagina, hai intenzione di fermare il renderer DOM e forzarlo ad attendere mentre controlla tutto.

Anche se ciò che si stampa non interferirà con altri elementi nella pagina, il renderer DOM non lo sa ancora, (specialmente se sta ancora costruendo cose) e quindi si fermerà mentre controlla due volte cosa fa già lo so.

Ci sono modi e mezzi per mitigarlo, ad esempio puoi produrre tutto in un I-Frame in sandbox, quindi l'unico renderer che viene messo in pausa è quello nell'I-Frame, oppure puoi assicurarti che lo script venga eseguito prima di ogni altra cosa, produce il suo output, ma lo tiene nascosto fino a quando non viene creato il resto della pagina.

Un altro motivo per cui spesso le persone trascurano elementi come gli elementi pubblicitari di Google.

GAd fa cose molto, molto funky con il DOM, tra cui liberarsi dei contenitori I-Frame e salire l'albero delle pagine per sedersi sopra altri elementi, in modo che possano interagire con loro.

In un progetto su cui ho lavorato in precedenza, abbiamo lavorato molto in quest'area e il problema che GAd ci ha causato in scenari del genere è stato a dir poco esasperante. E non solo GAd ci sono anche altre cose, widget di altri provider, widget di mappe, componenti web e vari script che cercano di connettersi alle cose in modo subdolo.

A meno che tu non conosca ogni singola riga di codice inclusa nella tua pagina (compreso quello negli script di terze parti), ti consiglio vivamente di non farlo.

Se il tuo obiettivo è un browser basato su HTML5 moderno e non ti interessa molto per i vecchi, allora potresti prendere in considerazione l'utilizzo dello standard dei nuovi componenti web emergenti. È progettato esattamente per questo tipo di scenario ed è stato progettato da zero per essere sicuro di poter avvolgere tutto ciò di cui hai bisogno nel tuo piccolo mondo JS e non danneggiare nulla nel browser. Questa nuova tecnologia è ciò che rende le cose come i nuovi lettori Video e Audio disponibili con i propri controlli e funzionalità di skinning.

Se usi "PolymerJS" o "X-Tags" per supportare i tuoi sforzi, queste cose funzioneranno su tutta la linea in questo momento e si adatteranno all'uso delle funzionalità native man mano che i produttori di browser iniziano a abilitarlo nei loro browser.

Se usi Polymer, anche se ufficialmente i documenti dichiarano IE 10 o versione successiva, puoi ottenere il supporto che lo utilizza fino a IE8, Chrome 30 e non ricordo la versione esatta, ma alcune versioni indietro anche su Fire fox.

Se non sei in grado di utilizzare la nuova architettura di componenti web, o devi supportare browser molto vecchi e devi scrivere contenuti, allora il modo più sicuro è quello di bloccare lo script all'interno di un I-Frame e tienilo fisicamente il più lontano possibile dal resto del DOM della pagina.

    
risposta data 07.07.2014 - 21:41
fonte

Leggi altre domande sui tag