Perché separare i fornitori CSS e JS dai CSS e JS personalizzati in un flusso di lavoro?

Question

Ho cercato di determinare il ragionamento dietro quella che sembra essere diventata la pratica standard nei flussi di lavoro di Front End per separare il fornitore JS & CSS da JS personalizzato & CSS. Non sono sicuro di quali siano i vantaggi rispetto allo svantaggio di una richiesta HTTP aggiuntiva, sembrerebbe più semplice avere un solo file CSS & piuttosto che avere vendor.css, main.css & vendor.js, main.js.

Qualcuno può far luce su questo?

Answer 1

Il codice fornitore cambia in genere meno frequentemente del codice dell'applicazione. Pertanto, man mano che si aggiorna l'applicazione, il codice fornitore può rimanere invariato e memorizzato nella cache del browser dell'utente.

Nello scenario in cui il codice fornitore è associato al codice dell'applicazione, l'utente deve scaricare tutto il codice fornitore ogni volta che si aggiorna l'applicazione.

La richiesta HTTP aggiuntiva dal bundle del fornitore separato è mitigata dal fatto che l'utente scaricherà meno codice su ogni aggiornamento dell'applicazione.

Answer 2

A seconda della situazione, questo consente di ridurre le modifiche nella cascata in modo da poter ignorare gli stili e i comportamenti del fornitore senza eliminare il codice. Questo è utile per avere sempre una versione funzionante (codice fornitore) che è possibile ripristinare. In situazioni come lavorare con Wordpress, lo sviluppo di un tema figlio consente di aggiornare il tema principale senza eliminare le personalizzazioni.

Answer 3

Posso pensare a due ragioni.

1. Hosting codice fornitore separatamente dal codice (ad esempio Google Hosted Libraries)
2. separazione degli interessi: il codice fornitore potrebbe essere di grandi dimensioni e viene aggiornato in modo indipendente del codice personalizzato. Il mantenimento del codice in un file separato evita la necessità di inserire il codice del fornitore nel controllo del codice sorgente, semplifica la navigazione del codice e semplifica l'aggiornamento a un nuovo codice fornitore poiché si sa per certo che il codice del fornitore non è stato ottimizzato.

Tanto più che hai contrassegnato la questione con grunt, l'utente finale potrebbe non vedere mai questo cambiamento dal momento che è possibile unire vendor e utenti stili/scripts durante la compilazione.

Tuttavia, se il codice del fornitore è di grandi dimensioni e cambia di rado, si ottiene un vantaggio di memorizzazione nella cache di un file di fornitore di grandi dimensioni che cambia raramente, accompagnato da un piccolo file di codice personalizzato che cambia rapidamente. Per i siti di grandi dimensioni che non utilizzano un CDN (si spera, non il tuo), l'impatto può essere notevole.

Answer 4

varie risposte già affrontato questo, ma ce la farò molto specifico:

1. codice fornitore potrebbe cambiare più o meno frequentemente di quanto il tuo codice. Se il codice fornitore cambia più frequentemente, ad es. per le correzioni dei bug, dovresti utilizzare le versioni più recenti e avere un sito Web generale migliore. Se il codice del fornitore cambia MENO di frequente rispetto al codice, è possibile che si desideri per modificare il codice senza toccare il materiale di lavoro.

2. codice del fornitore viene spesso ospitato su CDN, per esempio https://cdnjs.com/#q=ajax o https://developers.google.com/speed/libraries/ Questi sono VELOCE carico.Inoltre non cambieranno, quindi l'utente può fare affidamento sui file memorizzati nella cache e quindi il tuo sito Web verrà caricato più velocemente.

3. In genere è preferibile apportare modifiche iterative al codice. È anche più facile gestire il codice, in particolare con il controllo del codice sorgente quando le cose specifiche di cambiano. Non è necessario scambiare file di grandi dimensioni quando non sono stati modificati . Mantenere le cose separate rende più facile apportare modifiche incrementali , specialmente se le due cose cambiano in modo diverso nelle velocità .