Perché dovrei evitare gli script in linea?

what are the real problems with inline scripting? Is there a significant performance issue, or is it mostly just a matter of good style?

I vantaggi non sono basati sulle prestazioni, sono (come ha sottolineato Michael nel suo commento) più sulla separazione tra vista e controllore. 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 pari) leggere e mantenere sia gli aspetti visivi che quelli funzionali.

Can I justify immediate action on the inline scripting front to my superiors, when there are other things to work on that might have a more obvious impact on the site?

No, probabilmente no. Può essere molto difficile convincere i poteri che sono di puro lavoro di manutenzione, anche se pensi che risparmierà denaro nel lungo periodo. In questo caso, tuttavia, non penso sia così importante che tu debba interrompere tutto e liberarti degli script inline. Invece, assicurati di fare uno sforzo consapevole per rettificare 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.

If you pulled up to a website, and took a peek at the source code, what factors would lead you to say "hmm, professional work here", and what would cause you to recoil from an obviously amateurish job?

Il fattore numero uno che mi direbbe che non è professionale è l'uso eccessivo di tabelle o div. Ecco un articolo che spiega perché nessuno dovrebbe essere usato troppo.

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

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

Ciascuna delle loro home page utilizza JavaScript in linea. Significa che tutte queste società assumono persone amatoriali per creare le loro home page?

Sono uno di quegli sviluppatori che non possono inserire il codice JavaScript all'interno dell'HTML. Non lo faccio mai nei progetti su cui lavoro (ad eccezione probabilmente di alcune chiamate come <a href="javascript:..."> per i progetti in cui JavaScript non invadente non era un requisito fin dall'inizio e rimuovo sempre JavaScript inline quando rifatto il codice di qualcun altro. vale la pena? Non sono così sicuro.

Per quanto riguarda le prestazioni, non hai sempre prestazioni migliori quando inserisci JavaScript in un file separato. Di solito, siamo tentati di considerare che la larghezza di banda sprecata in linea JavaScript, dal momento che non può essere memorizzata nella cache (eccetto quando si ha a che fare con l'HTML in cache statico). Al contrario, un file .js extern viene caricato una sola volta.

In realtà, questa è solo un'altra ottimizzazione prematura : potresti avere ragione nel ritenere che esternalizzare JavaScript possa bloccare il tuo sito web, ma potresti anche essere totalmente sbagliato:

• Cosa succede se la maggior parte dei tuoi utenti ha una cache vuota?
• L'hai considerato con un file .js extern, verrà richiesta 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 è realmente memorizzato nella cache (con IIS, potrebbe non essere così semplice)?

Quindi, prima di ottimizzare prematuramente, raccogli statistiche sui tuoi visitatori e valuta le prestazioni con e senza JavaScript inline.

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, minimizzato, o più file CSS o JS possono essere uniti in un unico file, ma questo non significa che hai davvero chiamato le tue variabili a , b , c ... a1 , ecc. o che hai scritto un enorme file CSS senza spazi o newline. Allo stesso modo, puoi facilmente avere codice sorgente JavaScript esterno iniettato in HTML in fase di compilazione o successiva tramite i modelli.

Per concludere, se mischi 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 inline, è sempre male.

• Potrebbe essere cattivo.
• All'opposto potrebbe essere il segnale che il sito Web è stato scritto da professionisti che si sono preoccupati delle prestazioni, hanno effettuato test specifici e hanno determinato che sarebbe stato più veloce per i loro clienti integrare parti di JavaScript.
• Oppure potrebbe non significare nulla.

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

In genere è consigliabile provare a mantenere generalmente separati HTML e JS. HTML è per la vista, JS è per la logica dell'applicazione. Ma nella mia esperienza il disaccoppiamento estremo di html e javascript (per motivi di purezza) non lo rende più mantenibile; in realtà può essere meno mantenibile.

Ad esempio, a volte uso questo pattern (preso in prestito da ASP.net) nella configurazione dei gestori di eventi:

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

o

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

Non c'è mistero su cosa stia provocando un evento. Il motivo è che sei mesi dopo puoi controllare 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 facilmente dirmi che metodo javascript sta chiamando? Chrome lo ha reso più semplice, ma forse l'evento è associato all'id, o forse è legato al primo figlio del contenitore. Forse l'evento è collegato all'oggetto padre. Chissà? Buona fortuna a trovarlo. :)

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

Quindi, in breve, la pratica migliore è separare HTML e Javascript. Ma capire anche le regole empiriche a volte sono controproducenti se portate all'estremo. Discuterei per un approccio di middle-road. Evita grandi quantità di js in linea. Se usi inline, la firma della funzione dovrebbe essere molto semplice come:

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

Ecco alcuni motivi.

1. Lo script inline non può essere minimizzato (convertito in una versione più corta tramite la riduzione dei simboli). Non preoccuparti della banda larga, ma considera un dispositivo mobile in un'area con larghezza di banda ridotta o gli utenti che utilizzano il roaming di dati globali: ogni byte può contare.

2. Lo script inline non può essere memorizzato nella cache dal browser a meno che la pagina stessa non sia memorizzata 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ò seriamente influire sulle 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 un errore non ha significato.

4. Lo script in linea ha la reputazione di interferire con le considerazioni sull'accessibilità (508 / WAI), sebbene ciò non significhi che tutti gli script in linea causino problemi. Se si finisce con uno screen reader che annuncia il contenuto dello script si ha un problema! (Mai visto accadere però).

5. Lo script inline 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).

Un argomento che mi manca qui è la possibilità di aumentare la protezione contro gli attacchi cross site scripting .

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

Ci sono diversi motivi che giustificano l'esclusione dello script inline:

• 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'inclusione di queste parti significherebbe dover modificare ogni singola pagina ogni volta che esegui una piccola modifica.

• Se utilizzi un SCM per il tuo progetto, avere i diversi componenti ben separati renderà le modifiche di tracciamento e impegna più facilmente per tutti gli interessati.

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 molto 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ù veloce rispetto a più file più piccoli, in questo caso si potrebbe sostenere che non separare il codice è una prestazione migliore.

Non sono a conoscenza di alcun test formale in quest'area, anche se è molto probabile che qualcuno li abbia fatti.

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

La risposta dipende in realtà da come viene usato il codice in linea (assumendo javascript).

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

Quindi, per qualcuno, fare una dichiarazione generale che l'uso del "codice in-line" è sbagliato senza comprendere appieno come possa essere fuorviante.

Detto questo, se ogni pagina ha la stessa copia e il codice javascript incollato invece di usare un file js, dico che non va bene.

Se ogni pagina ha la propria copia e incolla la sezione CCS invece di usare un file css, io dico che non va bene.

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

Assumerò JavaScript inline qui.

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

1. Hai <script> s sparsi nella pagina
2. Tutto ciò che JS è nell'intestazione della pagina, non nei file esterni

La prima è una pessima decisione di progettazione. Distribuire script in un file sorgente rende la pagina molto più difficile da mantenere, perché devi cercare un determinato script. È molto meglio mantenere tutto quel codice in un posto (preferisco in cima al file sorgente).

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

Una ragione per NON usare InLine Javascript (nemmeno onclick="DoThis (this)" sui pulsanti), è se intendi rendere la tua applicazione web un'app Chrome. Pertanto, se hai intenzione di trasferire la tua app Web in un'app nativa di Chrome, inizia NON includendo QUALSIASI javascript in linea. Questo è spiegato proprio all'inizio di ciò che sarà necessario modificare (obbligatoriamente) dalla tua app Web se intendi "Chrome-etize".

What are the real problems with inline scripting?

Lo scripting inline è cattivo e dovrebbe essere evitato perché rende il codice più difficile da leggere.

Il codice difficile da leggere è difficile da mantenere. Se non puoi 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 da codifiche annidate. 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 rende facile individuare quando c'è un errore. Joel Spolsky ha scritto un grande articolo che sottolinea questo punto nel 2005 . Gli esempi di codice potrebbero apportare miglioramenti significativi, poiché mostrano che la loro età è di 9 anni, ma il concetto di base è ancora valido: scrivi il codice in un modo che permetta di individuare facilmente i bug.

Is there a significant performance issue, or is it mostly just a matter of good style?

Lo scripting in linea porta alla ripetizione. Invece di modificare una riga di codice per interessare 100 pagine, è probabile che dovrai modificare 100 pagine singolarmente. Questo insieme a una scarsa leggibilità incide gravemente sulle prestazioni del maintainer . Il tempo di programmazione ha un costo reale che incide sulla linea di fondo di un'azienda più velocemente dei pochi millisecondi dalla maggior parte delle ottimizzazioni del codice. Sicuramente l'ottimizzazione dei colli di bottiglia è importante, ma in questo caso la differenza di prestazioni del codice è trascurabile.

Can I justify immediate action on the inline scripting front to my superiors, when there are other things to work on that might have a more obvious impact on the site?

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

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

What factors would lead you to say "hmm, professional work here", and what would cause you to recoil from an obviously amateurish job?

Tendo a preferire definire "professionale" semplicemente come qualcuno che è pagato per svolgere un compito, piuttosto che assumere che possiedano una capacità significativa in ciò che viene pagato per fare. Molti professionisti sono certamente in grado di svolgere un buon lavoro, ma il più delle volte mi ritrovo ad allontanarmi inorridito dal terribile lavoro che altri professionisti hanno fatto piuttosto che qualcosa che un dilettante ha inventato. Gran parte del mio lavoro fino ad oggi ha comportato il salvataggio di progetti di demolizione del treno che sono stati danneggiati dagli sviluppatori iniziali, quindi il tuo percorso potrebbe variare.

Con tutto ciò che detto, in genere è facile scegliere la programmazione di qualità aziendale