Quando gli script in HTML non sono considerati una cattiva pratica?

Ci sono principalmente due motivi per inserire script all'esterno del codice HTML:

1. Lato server, separazione di problemi e codice pulito. Capisci subito perché devi stare molto attento quando vedi qualche codice PHP che, nello stesso pezzo di codice, mescola le immagini PHP, SQL, JavaScript, HTML, CSS e Base64 incorporate nei CSS.

2. Gli script esterni sul lato client sono facilmente memorizzati nella cache. Se il tuo HTML è una pagina dinamica, potrebbe cambiare spesso. Mettendo script al di fuori dell'HTML, consenti ai tuoi visitatori di scaricare questi contenuti una sola volta, e di non aggiornarli mai più (beh, non mai, ma raramente). Allo stesso modo, se due pagine HTML statiche o dinamiche condividono lo stesso script, inserendolo in un file esterno sarà possibile scaricarlo una sola volta.

▪ Il primo punto è valido in tutti i casi. Non sarai mai in grado di giustificare che è più pulito mescolare tutto in un unico file. Perché i framework consentono questo? Perché ci sono situazioni in cui non ti interessa il codice pulito :

• Se scrivo una pagina piccola, la butto via di sicuro, e devo farlo in fretta, non è così male mettere tutto in un file.

• Se voglio mostrare un breve esempio al mio collega (mettendo un singolo file su una piattaforma del sistema di gestione dei documenti) o pubblicarlo su un blog¹, avere tutto in un file può essere accettabile e utile anche.

• Se devo creare un piccolo prototipo prima di sviluppare l'applicazione per un cliente, le best practice non contano affatto, mentre la riduzione dei costi è fondamentale per il codice sorgente che verrà lanciato in tutti i casi.

▪ Il secondo punto , d'altra parte, spiega perché ci sono casi perfettamente validi per inserire script in HTML :

• Lo script cambia ad ogni cambio di pagina dinamica . In questo caso, perché dovresti forzare il client a scaricare il file HTML, quindi il file separato contenente lo script (cioè fare due richieste, che è uno spreco di tempo e risorse che non deve essere trascurato per i siti web di qualche scala), mentre puoi fornire la stessa cosa attraverso una richiesta?

• La pagina HTML statica utilizza lo script che non è condiviso da nessuna altra pagina del sito web. È anche un candidato perfetto, se vuoi evitare di fare due richieste².

Ora, tornando al primo problema (codice pulito), puoi pubblicare script in HTML e avere codice pulito lato server (ad esempio utilizzando un modello che inietterà, in fase di esecuzione, lo script che viene scritto separatamente). Questo, ovviamente, richiede un certo livello di esperienza e, come ho detto prima, la combinazione di script e HTML è necessaria solo su siti Web di grandi dimensioni. Ciò significa che se stai vedendo uno sviluppatore inesperto che mischia script e HTML quando fai un sito web personale, è un buon segno che qualcosa non va.

^{¹ Personalmente, sono contrario a questa pratica. Più condividiamo attraverso il nostro codice blog che non segue le best practice, più gli sviluppatori meno esperti sarebbero incoraggiati a copiarlo e a credere che questo sia lo stile giusto.}

^{² Con la configurazione di caching appropriata, due richieste avverranno solo per gli utenti con cache vuota. Per gli altri, puoi impostare la data di scadenza per il futuro lontano e il browser eviterà la richiesta che restituirà la risposta 304 Not Modified .}

Posso pensare a diversi posti in cui vorrei farlo

1) Test semplice di un'idea, voglio vedere come funziona qualcosa e non intendo mantenere il codice.

2) Inizializzazione dei dati, in cui la logica del programma corrente si trova in un file esterno, ma voglio caricare i dati iniziali per qualche motivo e non voglio avere una chiamata ajax per ottenerla. Ad esempio, se ho una lista di paesi che dovrò usare, sarebbe un candidato perfetto. Cambierà raramente e può essere inserito nella pagina HTML tramite qualsiasi lingua sto usando lato server (PHP, Ruby, Haskell ecc.), In questo caso potrei avere del codice come questo

Data.countries = <?php echo json_encode($countries); ?>;

Mai. Mescolare la presentazione e la logica aziendale è una pessima strategia per la manutenzione a lungo termine. Dovresti evitarlo e alla fine tornerai a pentirsene quasi in ogni caso.

Ciò che è cambiato è che i problemi con questo approccio sono stati notati, e il mondo si è generalmente spostato verso soluzioni migliori e più robuste - ma la gente di Java si preoccupa profondamente della compatibilità a lungo termine, quindi mantiene questa caratteristica nel caso in cui la vita più miserabile per qualcuno che dipendesse da questo.

Talvolta gli strumenti vengono forniti in modo tale da poter essere utilizzati in modo improprio. Ad esempio, non dovresti mettere le scarpe all'indietro, anche se "tecnicamente" è possibile. All'inizio potrebbe essere bello, o se sei pigro potrebbe risparmiare un po 'di tempo, ma lungo la strada ti farà male ... e le scarpe ... pensa alle scarpe!

Scripting all'interno di applicazioni Web è una pratica molto comune. Ma non si presta a codice manutenibile o codice "a prova di futuro".

Alcune regole d'oro mantengono la logica, la vista e i dati tutti separati. Se ben concepito, non dovresti mai aver bisogno di scrivere effettivamente qualcosa.

Quando vai a fare test di unità ... ma i tuoi punti di vista contengono la logica ... ti prenderesti a calci dopo che ti rendi conto che non puoi fare semplici asserzioni di buon senso.

Inoltre: se qualcuno guarda all'interno di un controller e si aspetta di trovare la logica e non è lì, maledirà il tuo nome quando dovrà cercare l'applicazione per dove hai deciso di incollarla.

I metodi di scripting si prestano all'offuscamento e alla duplicazione.

- > Puoi giocarci da solo nel tempo libero, fare progetti da zero e rivisitarli in un mese.

- > Puoi imparare nel modo più duro e utilizzare i metodi di scripting indipendentemente da ciò che dicono gli altri.

- > Puoi risparmiare tempo prezioso e concentrarti sulla corretta architettura e progettazione dell'applicazione.

Ricorda che l'industria dello sviluppo web è piena di cadaveri di sviluppatori che si sono rifiutati di imparare da persone che hanno dovuto fendere le trincee e risparmiare tempo e sofferenza.