Dovresti davvero tenere separati js, html e css?


10

Ho sentito / letto tutto il tempo che è più pulito mantenere separati js , html e css . Presumibilmente rende più facile la manutenzione, il debug. Presumibilmente è più efficiente, perché consente di memorizzare nella cache / minimizzare i file css e js .

Per quanto mi riguarda, usando i framework web (Django, Rails, ...), le librerie di template javascript ... . Ad esempio, posso avere un widget di feed di notizie , un widget di selezione multipla , ecc ... ognuno di essi ha un layout coerente nelle diverse pagine e ognuno è controllato dal suo pezzo di javascript.

Con questa organizzazione - che mi sembra più pulita possibile, massimizzando la riusabilità - ho difficoltà a capire perché sarebbe più semplice mantenere tutti i file js e css in file separati. Penso che sarebbe molto più semplice ad esempio :

nel selezionare più file widget

  • html
  • layout di base css
  • controllo delle interazioni dirette e miglioramenti UX con un po 'di JS.

Penso che in questo modo sia più riutilizzabile, molto più mantenibile, perché non è necessario scorrere un file js fat , quindi passare e scorrere un file css fat , passare di nuovo al file html ... avanti e indietro .

Quindi mi piacerebbe sapere come organizzate il vostro codice, se seguite la separazione che di solito è consigliata.

  • Ci sono davvero dei buoni motivi per farlo?
  • non è che le guide sul web di solito presumono che non userete alcuno strumento di fantasia (nel qual caso mi piacerebbe avere letture online più aggiornate per le migliori pratiche)?
  • È solo una questione di preferenza?

2
Il principio a cui alludi si chiama Separazione di presentazione e contenuto.
Robert Harvey,

8
Tieni presente che se non ti separi dai file, i tuoi utenti scaricheranno il codice HTML e CSS incorporato su ogni caricamento della pagina invece di scaricarlo una volta e memorizzarlo nella cache.
Nicole,

@RobertHarvey: ok buon riferimento ... Ma l'unico motivo elencato lì per il contenuto / presentazione della separazione è migliorare la leggibilità della macchina. Tuttavia, penso che non abbia importanza quando i widget vengono aggiunti alla pagina con JS. L'html di base non li contiene comunque !?
sebpiq,

1
@Renesis: questo è un grosso svantaggio, vero ... tuttavia con Django ad esempio è abbastanza facile raccogliere i tuoi js e css da più template e unirli in un singolo file.
sebpiq,

2
Ciò significa che puoi pubblicare una normale pagina Web, una pagina Web mobile e una pagina stampabile, senza dover scrivere ogni pagina a mano da zero, semplicemente modificando la presentazione (ovvero il CSS).
Robert Harvey,

Risposte:


5

Mantengo questa struttura

Per ogni pagina o controllo, gli do una cartella per la sua pagina html (o aspx, o php, ecc.). In quella cartella si trovano anche le cartelle per i file js, xml, immagini e css. Questi sono per risorse specifiche di pagina / controllo, non condivise.

Nella radice del sito sono presenti anche le cartelle js, xml, images e css, ognuna delle quali contiene risorse a livello di sito.

I file js e css a livello di sito vengono arrotolati sul lato server e restituiti come un singolo file js. Quelli specifici della pagina, poiché di solito ce n'è solo uno per pagina, vengono lasciati soli.

Questo organizza le mie risorse per quanto riguarda la loro portata. E mentre potrei avere una dozzina di file js nella cartella js root, verranno restituiti come una risorsa js combinandoli e minimizzandoli sul lato server (e memorizzando nella cache il risultato).

Inoltre non sto caricando risorse specifiche per pagex quando sono su pagey. L'unico "spreco" potrebbe essere nel file di risorse a livello di sito, ma poiché è memorizzato nella cache e molte delle risorse SARANNO utilizzate in più punti, è più efficiente.


1
Suona bene ! Non avevo pensato di raggruppare semplicemente i file in cartelle separate e di raccoglierli per la pubblicazione! Risolve tutti i problemi - memorizzazione nella cache, SoC, ... - consentendo l'incapsulamento. Grande !
sebpiq,

2

generalmente la convenzione prevede di avere file separati per JS / CSS / HTML per mantenere una separazione di contenuto, presentazione e comportamento. Tuttavia, se la velocità diventa un problema, allora tutto va bene.


i file separati in realtà migliorano la velocità piuttosto che degradarla: \
Raynos il

Una quantità minore di CSS e JS nel file HTML è una richiesta di pagina invece di tre richieste di pagina, che potrebbe essere migliore per servire un numero elevato di pagine molto velocemente. O almeno
combinali

1

nel selezionare più file widget

  • html
  • layout di base css
  • controllo delle interazioni dirette e miglioramenti UX con un po 'di JS.

Ho uno strumento di organizzazione ( trinità ) che ti promuove a farlo.

Tranne che il file del widget è diviso in 3 piccoli file, HTML, CSS e JS. Questo significa che hai i tuoi file separati ma sono ancora collegati.

Questo evita il problema dei file fat ma ti dà comunque file separati.

Quindi semplicemente separare le preoccupazioni non significa che dovresti avere un grosso file HTML / CSS / JS. È necessario disporre di più terzine <HTML, CSS, JS>per tutto il codice incapsulato riutilizzabile

Ora non c'è nulla di sbagliato nell'avere tutti questi in un file purché siano chiaramente separati.

Quindi un widget che sembra

<div id="wrapper">
  <style scoped> CSS code </style>
  <script> JS code </script>
  HTML code
</div>

Va bene e fantastico. Tranne il fatto di avere tutto in un unico file, è troppo facile per un manutentore iniziare a mescolare e abbinare CSS / JS / HTML.

Lo rende troppo facile perché si trasforma in spaghetti nel tempo.

Il motivo principale per cui le persone promuovono file separati è duplice

  • download separati. Non appena copi e incolli qualsiasi codice css / js in più "widget", devi scomporlo nel suo file.
  • Previene in modo aggressivo il codice spaghetti non affidandosi all'autore per mantenere i loro css / js / html ben separati in un singolo file

Sì ... lo stesso suggerimento di Chad! E in effetti l'ho provato subito e sono venduto :) Questo è molto più pulito del genere ... Il tuo strumento è per il nodo giusto? Dovrei trovare qualcosa del genere per Django ...
sebpiq

@sebpiq è per il nodo, ma lo sto trasferendo al client. È anche alfa e sto lavorando molto per renderlo un'intera piattaforma di organizzazione HTML / CSS / JS, incluso il riutilizzo del codice client / server. Personalmente dubito che potresti trovare qualcosa del genere su altre piattaforme, puoi portarlo tramite o /
Raynos il

1

È una buona pratica separare html, css e js in quanto semplifica la gestione del sito Web.

Quando inizi potresti avere solo un indice.html principale e un singolo file styles.css, ma molto probabilmente con la crescita del tuo sito web, finirai con più script e fogli di stile specifici di un singolo componente o endpoint.

Usando la separazione:

  • JavaScript separato può essere riutilizzato su altre pagine
  • CSS separato può essere in grado di dare al sito un nuovo look facilmente insieme al riutilizzo
  • HTML separato può essere Focus sul contenuto, non guardare.

Inoltre, va menzionato che CSS / JS potrebbe essere memorizzato nella cache se utilizzato su più pagine del tuo sito


... e ci sono molti "strumenti di costruzione" che possono raccogliere risorse JS e CSS da singoli file (non distribuiti) per creare i file effettivi che vengono distribuiti ... raccogliere le risorse, rimuovere (o rilevare) duplicati, minimizzare e presto.
Mike Robinson,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.