Perché dovrei evitare gli script in linea?

Un amico esperto ha recentemente visto un sito Web che ho aiutato a lanciare e ha commentato qualcosa come "sito molto interessante, peccato per lo script in linea nel codice sorgente".

Sono sicuramente in grado di rimuovere gli script in linea in cui si verificano; Sono vagamente consapevole che è "una brutta cosa". La mia domanda è: quali sono i veri problemi con gli script inline? C'è un problema di prestazioni significative o è principalmente solo una questione di buon stile? Posso giustificare un'azione immediata sul fronte dello scripting in linea con i miei superiori, quando ci sono altre cose su cui lavorare che potrebbero avere un impatto più evidente sul sito? Se accedessi a un sito Web e dessi una sbirciatina al codice sorgente, quali fattori ti porterebbero a dire "hmm, lavoro professionale qui" e cosa ti indurrebbe a indietreggiare da un lavoro ovviamente amatoriale?

Va bene, quella domanda si è trasformata in più domande nella scrittura. Ma fondamentalmente, script in linea - qual è il problema?

quali sono i veri problemi con gli script inline? C'è un problema di prestazioni significative o è principalmente solo una questione di buon stile?

I vantaggi non sono basati sulle prestazioni, ma sono (come ha sottolineato Michael nel suo commento) più legati alla separazione della vista e del controller. Il file HTML / CSS dovrebbe, idealmente, contenere solo la presentazione e file separati dovrebbero essere usati per gli script. Ciò rende più facile per te (e per i tuoi colleghi) leggere e mantenere sia gli aspetti visivi che quelli funzionali.

Posso giustificare un'azione immediata sul fronte dello scripting in linea con i miei superiori, quando ci sono altre cose su cui lavorare che potrebbero avere un impatto più evidente sul sito?

No, probabilmente no. Può essere molto difficile convincere i poteri del puro lavoro di manutenzione, anche se credi che li farà risparmiare denaro nel lungo periodo. In questo caso, tuttavia, non penso che sia così importante che tu debba fermare tutto e sbarazzarti del tuo script in linea. Invece, assicurati di fare uno sforzo consapevole per correggere le aree mentre lavori su di esse per altri motivi. Il codice di refactoring dovrebbe essere qualcosa che fai regolarmente ma solo un po 'alla volta.

Se accedessi a un sito Web e dessi una sbirciatina al codice sorgente, quali fattori ti porterebbero a dire "hmm, lavoro professionale qui" e cosa ti indurrebbe a indietreggiare da un lavoro ovviamente amatoriale?

Il fattore numero uno che mi direbbe che non è professionale è l'uso eccessivo di tavoli o div. Ecco un articolo che spiega perché nessuno dei due dovrebbe essere abusato.

Non sarò il difensore del diavolo, ma non esiste una relazione stretta tra lavoro amatoriale e JavaScript incorporato. Vediamo il codice sorgente di diversi siti Web più noti:

• Google,
• Wikipedia,
• Microsoft,
• Adobe,
• Dell,
• IBM.

Ogni loro home page utilizza JavaScript incorporato. Significa che tutte quelle aziende assumono persone amatoriali per creare le loro home page?

Sono uno di quegli sviluppatori che non riescono a inserire il codice JavaScript all'interno di HTML. Non lo faccio mai all'interno dei progetti su cui lavoro (tranne probabilmente alcune chiamate come <a href="javascript:...">per i progetti in cui JavaScript discreto non era un requisito dall'inizio, e rimuovo sempre JavaScript incorporato quando refactoring il codice di qualcun altro. Ma ne vale la pena ? Non così sicuro.

Per quanto riguarda le prestazioni, non sempre si ottengono prestazioni migliori quando si inserisce JavaScript in un file separato. Di solito, siamo tentati di considerare che la larghezza di banda dei rifiuti JavaScript incorporata, dal momento che non può essere memorizzata nella cache (tranne quando si tratta di HTML statico memorizzabile nella cache). Al contrario, un file .js esterno viene caricato solo una volta.

In realtà, questa è solo un'altra ottimizzazione prematura : potresti avere ragione pensando che esternalizzare JavaScript renderebbe sicuro il tuo sito web, ma potresti anche sbagliarti totalmente:

• Cosa succede se la maggior parte dei tuoi utenti arriva con una cache vuota?
• Hai considerato che con un file .js esterno, verrà fatta una richiesta a questo file ad ogni richiesta di pagina, se il sito Web non è configurato correttamente (e di solito non lo è),
• Il file .js è davvero memorizzato nella cache (con IIS, potrebbe non essere così semplice)?

Quindi, prima di ottimizzare prematuramente, raccogliere statistiche sui visitatori e valutare le prestazioni con e senza JavaScript incorporato.

Poi arriva l'argomento finale: hai mescolato JavaScript e HTML nella tua fonte, quindi fai schifo. Ma chi ha detto che hai mescolato entrambi? Il codice sorgente utilizzato dal browser non è sempre il codice sorgente che hai scritto. Ad esempio, il codice sorgente può essere compresso, ridotte di, o più file CSS o JS può essere unito in un unico file, ma questo non significa che si ha realmente chiamato il vostro variabili a, b, c... a1, ecc, o che hai scritto un enorme file CSS senza spazi o newline. Allo stesso modo, puoi facilmente inserire codice HTML esterno in HTML in fase di compilazione o successivamente attraverso i modelli.

Per concludere, se mescoli JavaScript e HTML nel codice sorgente che scrivi, dovresti considerare di non farlo nei tuoi progetti futuri. Ma ciò non significa che se il codice sorgente inviato al browser contiene JavaScript incorporato, è sempre male.

• Potrebbe essere male.
• Al contrario, potrebbe essere un segno che il sito Web è stato scritto da professionisti che si preoccupavano delle prestazioni, eseguivano test specifici e stabilivano che per i loro clienti sarebbe stato più veloce incorporare parti di JavaScript.
• O potrebbe non significare nulla.

quindi piuttosto vergogna per la persona che dice "sito molto interessante, vergogna per gli script in linea nel codice sorgente" guardando solo la fonte inviata al browser, senza sapere nulla su come è stato fatto il sito web.

È generalmente buono cercare di mantenere HTML e JS generalmente separati. HTML è per la vista, JS è per la logica dell'applicazione. Ma nella mia esperienza l'estremo disaccoppiamento di html e javascript (per motivi di purezza) non lo rende più mantenibile; in realtà può essere meno gestibile.

Ad esempio, a volte utilizzo questo modello (preso in prestito da ASP.net) per impostare i gestori di eventi:

<input type="button" id="yourId" onclick="clickYourId()" />

o

<input type="button" id="yourId" onclick="clickYourId(this)" />

Non c'è mistero che cosa sta scatenando un evento. Il motivo è che sei mesi dopo è possibile ispezionare l'elemento (ad esempio, in Chrome) e vedere immediatamente quale evento javascript viene attivato.

D'altra parte, immagina di leggere il codice di qualcun altro, che è di centomila righe, e ti imbatti in un elemento magico che scatena un evento javascript:

<input id="yourId"  />

Come puoi dirmi facilmente quale metodo javascript sta chiamando? Chrome ha reso tutto più semplice, ma forse l'evento è associato all'ID o forse è associato al primo figlio del contenitore. Forse l'evento è collegato all'oggetto padre. Chissà? Buona fortuna a trovarlo. :)

Inoltre, direi che nascondere javascript completamente dal designer potrebbe effettivamente aumentare la probabilità che si rompano su un aggiornamento. Se qualcuno modifica il codice per un elemento magicamente attivo, quale indicazione hanno nel codice che gli farebbe sapere che questo è un elemento attivo nella pagina?

Quindi, in breve, la migliore pratica è quella di separare HTML e Javascript. Ma anche capire le regole empiriche sono talvolta controproducenti se portate all'estremo. Discuterei per un approccio a metà strada. Evitare grandi quantità di j in linea. Se si utilizza in linea, la firma della funzione dovrebbe essere molto semplice come:

1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)

Un argomento che mi manca qui è la possibilità di una maggiore protezione dagli attacchi di cross-site scripting .

È possibile disabilitare l'esecuzione di JavaScript inline nel browser moderno tramite la politica di sicurezza dei contenuti . Ciò ha ridotto il rischio che il tuo sito sia vittima di XSS. Questo potrebbe essere un argomento più convincente da presentare alla tua direzione per investire nella rimozione di script in linea.

Ecco alcuni motivi.

1. Lo script incorporato non può essere minimizzato (convertito in una versione più breve tramite la riduzione dei simboli). Non è una preoccupazione per la banda larga, ma considera un dispositivo mobile in un'area a bassa larghezza di banda o gli utenti che utilizzano il roaming di dati globale: ogni byte può contare.

2. Lo script incorporato non può essere memorizzato nella cache dal browser a meno che la pagina stessa non sia memorizzabile nella cache (il che renderebbe una pagina molto noiosa). I file Javascript esterni devono essere recuperati una sola volta, anche se il contenuto della pagina cambia ogni volta. Può compromettere seriamente le prestazioni su connessioni a bassa larghezza di banda.

3. Lo script inline è più difficile da eseguire il debug perché il numero di riga associato a qualsiasi errore non ha senso.

4. Si ritiene che lo script inline interferisca con le considerazioni sull'accessibilità (508 / WAI), sebbene ciò non significhi che tutti gli script inline causano problemi. Se finisci con uno screen reader che annuncia il contenuto dello script, hai un problema! (Non l'ho mai visto accadere però).

5. Lo script incorporato non può essere testato indipendentemente dalla sua pagina; I file Javascript esterni possono essere eseguiti tramite test indipendenti, inclusi test automatici.

6. Lo script in linea può portare a una scarsa separazione delle preoccupazioni (come descritto da molte delle altre risposte qui).

Esistono diversi motivi che giustificherebbero di non includere lo script in linea:

• Prima di tutto, la risposta ovvia: rende il codice più pulito, più conciso, più facile da capire e da leggere.

• Da un punto di vista più pratico, spesso si desidera riutilizzare script / CSS / ecc. in tutto il tuo sito web, l'integrazione di queste parti significherebbe dover modificare ogni singola pagina ogni volta che fai una piccola modifica.

• Se usi un SCM per il tuo progetto, avere i diversi componenti ben separati renderà il monitoraggio delle modifiche e impegni più facili per tutti i soggetti coinvolti.

Per quanto ne so, le prestazioni non sarebbero una preoccupazione. Dipenderebbe da molte cose legate alla natura del tuo sito Web, alle specifiche del tuo server, ecc. Ad esempio, se la tua pagina web utilizza molti javascript, il tuo browser potrebbe memorizzare nella cache gli script, il che si tradurrebbe in prestazioni migliori quando il codice è separato in più file. D'altra parte, sarei tentato di dire che alcuni server potrebbero servire un singolo file di grandi dimensioni più velocemente rispetto a più file più piccoli, in questo caso si potrebbe sostenere che non separare il codice è meglio dal punto di vista delle prestazioni.

Non sono a conoscenza di alcun test formale in questo settore, anche se è molto probabile che qualcuno li abbia eseguiti.

Alla fine, direi che è una questione di buone pratiche più di ogni altra cosa e che i vantaggi in termini di leggibilità e organizzazione (in particolare il punto 2) rendono la separazione del codice in file distinti un'opzione molto migliore.

La risposta dipende davvero da come viene utilizzato il codice in linea (supponendo javascript).

Abbiamo usato una combinazione di codice inline, SSI (include lato server), file js e file css per creare gli effetti desiderati e anche ridurre i viaggi di ritorno del server per eventi onClick.

Quindi, per qualcuno fare un'affermazione generale che l'uso del "codice in-line" è negativo senza comprendere appieno come viene usato può essere fuorviante.

Detto questo, se ogni pagina ha la stessa copia e incollato il codice javascript invece di utilizzare un file js, dico che è male.

Se ogni pagina ha la sua copia e la sua sezione CCS incollata invece di usare un file CSS dico che non va bene.

È anche un sacco di spese generali includere l'intera libreria js su ogni pagina, specialmente se nessuna delle funzioni viene utilizzata su quella pagina.

Presumo javascript in linea qui.

Senza vedere il codice, è difficile esserne sicuri. Sospetto che si riferisse a una di queste due cose:

1. Hai <script>sparso in tutta la pagina
2. Tutto ciò che JS è nell'intestazione della pagina, non in file esterni

La prima è una cattiva decisione di progettazione. La diffusione di script in un file di origine rende la pagina molto più difficile da mantenere, poiché è necessario cercare un determinato script. È molto meglio tenere tutto quel codice in un posto (preferisco all'inizio del file sorgente).

Per quanto riguarda il secondo, non è necessariamente una cosa negativa. Il codice specifico della pagina dovrebbe essere in quella pagina. Se hai un codice duplicato tra le pagine, dovresti esternalizzarlo usando <script src>. Quindi quando vai a creare una nuova pagina, puoi semplicemente includere quel file e tutti i bug che hai risolto non dovranno essere rivisitati.

Uno dei motivi per NON utilizzare InLine Javascript (neanche onclick = "DoThis (this)" sui pulsanti) è se intendi trasformare la tua applicazione web in un'app Chrome. Quindi, se stai pianificando di eseguire il porting della tua app Web in un'app nativa di Chrome, inizia NON includendo NESSUN javascript incorporato. Questo è spiegato all'inizio di ciò che dovrai cambiare (obbligatoriamente) dalla tua app web se intendi "Chrome-etize".

Quali sono i veri problemi con gli script inline?

Gli script in linea sono dannosi e dovrebbero essere evitati perché rendono il codice più difficile da leggere.

Il codice difficile da leggere è difficile da mantenere. Se non riesci a leggerlo facilmente e capire cosa sta succedendo, non sarai in grado di individuare facilmente i bug. Se è difficile da mantenere, sprecherà più tempo in seguito in caso di problemi.

La difficoltà di solito deriva dalle codifiche nidificate. C'è un problema nella prossima riga di codice, puoi individuarlo?

<a onclick='alert("What\'s going wrong here?")'>Alert!</a>

Idealmente il codice è scritto in un modo che lo rende facile da individuare in caso di errore. Joel Spolsky ha scritto un ottimo articolo che sottolinea questo punto nel 2005 . Gli esempi di codice potrebbero utilizzare alcuni miglioramenti significativi, poiché mostrano che la loro età è di 9 anni, ma il concetto di base è ancora forte: scrivere il codice in un modo che renda facile individuare i bug.

C'è un problema di prestazioni significative o è principalmente solo una questione di buon stile?

Lo script in linea porta alla ripetizione. Invece di modificare una riga di codice per influire su 100 pagine, probabilmente dovrai cambiare 100 pagine singolarmente. Questo, insieme a una scarsa leggibilità, influisce gravemente sulle prestazioni del manutentore . I tempi di programmazione hanno un costo reale che influisce sui profitti di un'azienda più rapidamente dei pochi millisecondi della maggior parte delle ottimizzazioni del codice. È sicuramente importante ottimizzare i colli di bottiglia, ma in questo caso la differenza di prestazioni del codice è trascurabile.

Posso giustificare un'azione immediata sul fronte dello scripting in linea con i miei superiori, quando ci sono altre cose su cui lavorare che potrebbero avere un impatto più evidente sul sito?

No. Se è stupido e funziona, non è stupido.

Il corollario della programmazione è questo: se è un codice stupido e funziona, non è un codice stupido. Concentrati sui problemi reali prima di provare a risolvere qualcosa che non è rotto. Quando alla fine il codice inline necessita di un aggiornamento, che sia tra sei ore, sei mesi o sei anni, correggi il codice in modo da semplificarne la manutenzione futura.

Quali fattori ti porterebbero a dire "hmm, lavoro professionale qui" e cosa ti farebbe indietreggiare da un lavoro ovviamente amatoriale?

Tendo a preferire definire "professionale" semplicemente come qualcuno che è pagato per svolgere un compito, piuttosto che supporre che possiedano alcuna capacità significativa in ciò che vengono pagati per fare. Molti professionisti sono sicuramente in grado di svolgere un buon lavoro, ma il più delle volte mi ritrovo a indietreggiare per il terribile lavoro che altri professionisti hanno fatto piuttosto che qualcosa che un dilettante ha inventato. Gran parte del mio lavoro fino ad oggi ha riguardato il recupero di progetti di disastro ferroviario che sono stati compromessi dagli sviluppatori iniziali, quindi il tuo chilometraggio può variare.

Detto questo, è generalmente facile scegliere la programmazione di qualità aziendale