Devez-vous vraiment garder vos js, html et css séparés?


10

J'entends / lis tout le temps qu'il est plus propre de garder vos js , html et css séparés. Soi-disant, il est plus facile à maintenir, à déboguer. Soi - disant il est plus efficace, car elle permet la mise en cache / minifying css et js fichiers.

En ce qui me concerne, en utilisant des frameworks web (Django, Rails, ...), des bibliothèques de modèles javascript, ... j'ai tendance à diviser beaucoup de pages html en plusieurs modèles réutilisables - une sorte de widgets si vous le souhaitez . Par exemple, je peux avoir un widget de flux d'actualités , un widget de sélection multiple , etc ... chacun d'eux ayant une mise en page cohérente sur les différentes pages, et chacun étant contrôlé par son morceau de javascript.

Avec cette organisation - qui me semble aussi propre que possible, maximisant la réutilisabilité - j'ai du mal à comprendre pourquoi il serait plus simple de conserver tous les js et css dans des fichiers séparés. Je pense que ce serait tellement plus simple par exemple :

dans le fichier de sélection de widgets multiples

  • html
  • mise en page css de base
  • contrôle des interactions directes et des améliorations UX avec un peu de JS.

Je pense que de cette façon, il est plus réutilisable, beaucoup plus maintenable, car vous n'avez pas à faire défiler un gros fichier js , puis basculer vers et faire défiler un gros fichier css , basculer à nouveau vers votre fichier html ... .

J'aimerais donc savoir comment vous organisez votre code, si vous vous en tenez à la séparation qui est généralement recommandée.

  • Y a-t-il vraiment de bonnes raisons de le faire?
  • N'est-ce pas que les guides sur le Web supposent généralement que vous n'utiliserez aucun outil sophistiqué (auquel cas j'aimerais obtenir des lectures en ligne plus à jour pour les meilleures pratiques)?
  • Est-ce juste une question de préférence?

2
Le principe auquel vous faites allusion est appelé séparation de la présentation et du contenu.
Robert Harvey

8
Gardez à l'esprit que si vous ne vous séparez pas des fichiers, vos utilisateurs téléchargeront le code HTML et CSS intégré à chaque chargement de page au lieu de le télécharger une fois et de le mettre en cache.
Nicole

@RobertHarvey: ok bonne référence ... Mais la seule raison citée pour la séparation du contenu / de la présentation est l'amélioration de la lisibilité de la machine. Cependant, je pense que cela n'a pas d'importance lorsque des widgets sont ajoutés à la page avec JS. Le html de base ne les contient pas de toute façon!?
sebpiq

1
@Renesis: C'est un gros inconvénient, c'est vrai ... cependant avec Django par exemple, il est assez facile de collecter vos js et css à partir de plusieurs modèles et de les fusionner en un seul fichier.
sebpiq

2
Cela signifie que vous pouvez servir une page Web normale, une page Web mobile et une page imprimable, sans avoir à écrire chaque page à la main à partir de zéro, simplement en peaufinant la présentation (c'est-à-dire le CSS).
Robert Harvey

Réponses:


5

Je maintiens cette structure

Pour chaque page ou contrôle, je lui donne un dossier pour sa page html (ou aspx, ou php, etc.). Dans ce dossier se trouvent également des dossiers pour les fichiers js, xml, images et css. Ce sont des ressources spécifiques aux pages / contrôles et non partagées.

À la racine du site, se trouvent également les dossiers js, xml, images et css, chacun contenant des ressources à l'échelle du site.

Les fichiers js et css à l'échelle du site sont regroupés côté serveur et renvoyés sous forme de fichier js unique. Les pages spécifiques, car il n'y en a généralement qu'une par page, sont laissées seules.

Cela organise mes ressources quant à leur portée. Et bien que je puisse avoir une douzaine de fichiers js dans le dossier racine js, ils seront retournés comme une ressource js en les combinant et en les minimisant côté serveur (et en mettant en cache le résultat).

Je ne charge pas non plus de ressources spécifiques à pagex lorsque je suis sur pagey. Le seul «gaspillage» pourrait être dans le fichier de ressources à l'échelle du site, mais comme il est mis en cache et que de nombreuses ressources SERONT utilisées à plusieurs endroits, il est plus efficace.


1
Ça m'a l'air bien ! Je n'avais pas pensé à simplement regrouper les fichiers dans des dossiers séparés et à les collecter pour les servir! Il résout tous les problèmes - mise en cache, SoC, ... - tout en permettant l'encapsulation. Génial !
sebpiq

2

généralement, la convention est d'avoir des fichiers séparés pour JS / CSS / HTML pour maintenir une séparation du contenu, de la présentation et du comportement. Cependant, si la vitesse devient un problème, tout se passe.


des fichiers séparés améliorent réellement la vitesse plutôt que de la dégrader: \
Raynos

De plus petites quantités de CSS et JS dans le fichier HTML sont une demande de page au lieu de trois demandes de page, ce qui pourrait être mieux pour servir un grand nombre de pages très rapidement. Ou au moins, combinez-les selon vos besoins - code.google.com/speed/page-speed/docs/rtt.html
Bratch

1

dans le fichier de sélection de widgets multiples

  • html
  • mise en page css de base
  • contrôle des interactions directes et des améliorations UX avec un peu de JS.

J'ai un outil d'organisation ( trinité ) qui vous encourage à le faire.

Sauf que le fichier widget est divisé en 3 petits fichiers, HTML, CSS et JS. Cela signifie que vous avez vos fichiers séparés, mais ils sont toujours liés.

Cela évite le problème des gros fichiers mais vous donne toujours des fichiers séparés.

Donc, simplement séparer les préoccupations ne signifie pas que vous devriez avoir un gros fichier HTML / CSS / JS. Vous devriez avoir plusieurs triplets <HTML, CSS, JS>pour tout votre code encapsulé réutilisable

Maintenant, il n'y a rien de mal à avoir tout cela dans un seul fichier tant qu'ils sont clairement séparés.

Donc, un widget qui ressemble à

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

C'est bien et c'est super. Sauf que tout avoir dans un seul fichier, il est beaucoup trop facile pour un responsable de commencer à mélanger et à faire correspondre le CSS / JS / HTML.

Cela le rend beaucoup trop facile pour qu'il se transforme en spaghetti avec le temps.

La raison principale pour laquelle les gens font la promotion de fichiers séparés est double

  • téléchargements séparés. Dès que vous copiez et collez n'importe quel code css / js dans plusieurs "widgets", vous devez le factoriser dans son propre fichier.
  • Agressivement prévient le code de spaghetti en ne comptant pas sur l'auteur pour garder leurs css / js / html bien séparés dans un seul fichier

Ouais ... donc même suggestion que Chad! Et en effet je l'ai tout de suite essayé, et je suis vendu :) C'est tellement plus propre comme ça ... Votre outil est pour le noeud non? Je devrais trouver quelque chose comme ça pour Django ...
sebpiq

@sebpiq c'est pour le noeud, mais je le porte au client. Il est également alpha et je travaille activement à en faire une plate-forme d'organisation HTML / CSS / JS complète, y compris la réutilisation du code client / serveur.
Personnellement,

1

C'est une bonne pratique pour séparer html, css et js car cela facilite la gestion de votre site Web.

Lorsque vous commencez, vous ne pouvez avoir qu'un index.html principal et un seul fichier styles.css, mais plus que probablement à mesure que votre site Web se développe, vous vous retrouverez avec plusieurs scripts et feuilles de style spécifiques à un composant individuel ou point final.

En utilisant la séparation:

  • Un JavaScript séparé peut être réutilisé sur d'autres pages
  • Des CSS séparés peuvent être en mesure de donner au site un nouveau look facilement et à réutiliser
  • Un code HTML séparé peut se concentrer sur le contenu et non sur l'aspect.

Il convient également de mentionner que CSS / JS peut être mis en cache s'il est utilisé sur plusieurs pages de votre site


... et il existe de nombreux "outils de construction" qui peuvent rassembler des actifs JS et CSS à partir de fichiers individuels (non déployés) pour créer les fichiers réels qui sont déployés ... rassembler les actifs, supprimer (ou détecter) les doublons, minimiser et bientôt.
Mike Robinson
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.