Quali sono i vantaggi dell'uso di moduli JavaScript asincroni (come AMD) per i siti tradizionali?

0

Questo è specifico per JS nel browser per un sito multipagina tradizionale (vale a dire non un'app a pagina singola).

Per le app a pagina singola, i vantaggi sono piuttosto chiari: la pagina di visualizzazione principale sarà di lunga durata e caricherà qualsiasi numero di sottoview che potrebbero avere tutte dipendenze JS diverse. Caricare tutto il tuo JS in primo piano non è l'ideale per qualcosa di non banale, quindi avere dichiarazioni di dipendenza strutturate esplicite e utilizzare un caricatore di script asincrono sembra la strada da percorrere.

Tuttavia, per un design più tradizionale a più pagine, in cui ogni pagina è una pagina HTML completa e separata, non vedo il vantaggio. In questo design tutte le dipendenze JS sono note al caricamento della pagina. Quindi idealmente li metterei tutti insieme in un unico script sul lato server e scaricarlo in un colpo solo - caricare moduli separati con richieste separate sarebbe un male per le prestazioni.

Quindi, quando garantisci che tutti i moduli JS necessari sono presenti sul caricamento della pagina, non vedo la necessità di qualcosa come AMD. Puoi utilizzare il modello di modulo per creare moduli: puoi utilizzare oggetti semplici per creare spazi dei nomi . C'è qualcosa che mi manca?

    
posta alexp 23.11.2014 - 17:02
fonte

2 risposte

1

For single-page apps, the advantages are pretty clear ... having explicit, structured dependency declarations and using an async script loader seems like the way to go.

Tuttavia, questi non sono gli unici vantaggi. I moduli in stile AMD non rimuovono solo la necessità di spazi dei nomi, ma offrono anche altri vantaggi, come l'eliminazione delle dipendenze hard-coded e la facilitazione dell'iniezione delle dipendenze per il mocking / testing. Questa domanda va più nel dettaglio.

However for a more traditional, multi-page design ... you'd just put those all together into a single script on the server side and download it in one go - loading separate modules with separate requests would be bad for performance.

Un albero dei sorgenti di moduli stile AMD può essere facilmente compilato in una singola risorsa con uno strumento come RequireJS Optimizer . Questo ti dà il meglio di entrambi i mondi; durante lo sviluppo e il test è possibile caricare separatamente i moduli e ottenere informazioni di debug significative senza ricorrere alle mappe di origine. È possibile apportare modifiche a uno script e testarlo senza ricostruire il progetto. In produzione, puoi compilare i moduli in un'unica risorsa.

So when you guarantee that all needed JS modules are there on page load, I don't see the need for something like AMD.

Come garantite che tutti i moduli necessari siano presenti al caricamento della pagina? Se si utilizzano i moduli AMD, ogni modulo conosce le proprie dipendenze e si può puntare uno strumento come RequireJS Optimizer su un singolo modulo di un punto di accesso e utilizzarlo. Puoi anche riutilizzare gli stessi moduli in altre app (incluse le app a pagina singola) senza modificare nulla; i moduli possono essere caricati singolarmente o combinati in singole risorse.

Se segui il percorso dello spazio dei nomi, dovrai monitorare quali moduli sono necessari per ogni pagina, gestire l'intero grafico delle dipendenze per ogni modulo dei punti di accesso e gestire il processo di compilazione in qualche modo.

In altre parole, il caricatore di script non è l'unico vantaggio di AMD. L'altro grande vantaggio è che ogni modulo è responsabile delle proprie dipendenze (piuttosto che assumere che alcuni spazi dei nomi esistano e lasciarlo allo sviluppatore per assicurarsi che gli spazi dei nomi richiesti siano impostati prima che il modulo possa fare il suo lavoro). / p>     

risposta data 23.11.2014 - 22:09
fonte
0

La differenza tra le applicazioni a pagina singola e i siti multipagina potrebbe non essere particolarmente rilevante oggi. La maggior parte delle app web è tra queste due: hanno più pagine, un codice JavaScript comune che viene utilizzato su tutte o quasi tutte le pagine e un codice utilizzato solo su pagine specifiche.

Questo rende meno pratico il tuo suggerimento di servire un singolo file JavaScript minuscolo per pagina. Finirai con file di grandi dimensioni e file diversi per ogni pagina, con conseguenti scarse prestazioni e maggiore utilizzo della larghezza di banda.

Da qui, ci sono tre soluzioni generiche:

  1. È sufficiente lanciare tutto il codice JavaScript in un unico grande file miniato che viene richiamato da ogni pagina dell'app Web.

    Funziona bene nella maggior parte dei casi, ma diventerebbe problematico se c'è troppo JavaScript o in alcune situazioni specifiche, come un caso in cui la home page non contiene molta interattività e dovrebbe essere estremamente veloce.

  2. Avere un grande file miniato di codice comune chiamato su ogni pagina e codice dedicato su pagine specifiche.

    Questo è un miglioramento quando le prestazioni diventano un problema, ma aumenta la complessità della manutenzione. Se l'architettura è scarsa e / o i programmatori inesperti stanno lavorando sul codice JavaScript, questo potrebbe causare un disastro.

  3. Usare require.js per caricare JavaScript on-demand. Qui, tutta la complessità è gestita da require.js , il che significa che gli sviluppatori possono ottenere prestazioni simili alla seconda soluzione concentrandosi sul codice piuttosto che sull'organizzazione.

Quindi, per rispondere alla tua domanda, usare qualcosa come AMD ti permette semplicemente di attenuare parte della complessità degli sviluppatori mantenendo basso l'impatto sulle prestazioni.

    
risposta data 23.11.2014 - 22:08
fonte

Leggi altre domande sui tag