Pourquoi devrais-je éviter les scripts en ligne?
Un ami bien informé a récemment regardé un site Web que j'ai aidé à lancer et a commenté quelque chose comme "site très cool, dommage pour les scripts en ligne dans le code source".
Je suis définitivement en mesure de supprimer les scripts en ligne là où ils se produisent; Je suis vaguement conscient que c'est "une mauvaise chose". Ma question est: quels sont les vrais problèmes avec les scripts en ligne? Existe-t-il un problème de performances important ou s'agit-il principalement d'une question de bon style? Puis-je justifier une action immédiate sur le front des scripts en ligne auprès de mes supérieurs, lorsqu'il y a d'autres choses à travailler qui pourraient avoir un impact plus évident sur le site? Si vous vous présentez sur un site Web et jetez un œil au code source, quels facteurs vous amèneraient à dire "hmm, travail professionnel ici", et qu'est-ce qui vous ferait reculer devant un travail manifestement amateur?
D'accord, cette question s'est transformée en plusieurs questions écrites. Mais en gros, les scripts en ligne - quel est le problème?
quels sont les vrais problèmes avec les scripts en ligne? Existe-t-il un problème de performances important ou s'agit-il principalement d'une question de bon style?
Les avantages ne sont pas basés sur les performances, ils sont (comme l'a souligné Michael dans son commentaire) davantage liés à la séparation de la vue et du contrôleur. Idéalement, le fichier HTML/CSS ne devrait contenir que la présentation et des fichiers séparés devraient être utilisés pour les scripts. Cela vous permet (ainsi qu'à vos pairs) de lire et de maintenir plus facilement les aspects visuels et fonctionnels.
Puis-je justifier une action immédiate sur le front des scripts en ligne auprès de mes supérieurs, lorsqu'il y a d'autres choses à travailler qui pourraient avoir un impact plus évident sur le site?
Non, probablement pas. Il peut être très difficile de convaincre les pouvoirs publics de pur travail de maintenance, même si vous croyez que cela leur fera économiser de l'argent à long terme. Dans ce cas cependant, je ne pense pas qu'il soit si important que vous arrêtiez tout et vous débarrassiez de vos scripts en ligne. Au lieu de cela, assurez-vous simplement de faire un effort conscient pour rectifier les zones lorsque vous travaillez dessus pour d'autres raisons. La refactorisation du code devrait être quelque chose que vous faites régulièrement, mais seulement un petit peu à la fois.
Si vous vous présentez sur un site Web et jetez un œil au code source, quels facteurs vous amèneraient à dire "hmm, travail professionnel ici", et qu'est-ce qui vous ferait reculer devant un travail manifestement amateur?
Le facteur numéro un qui me dirait que ce n'est pas professionnel est la surutilisation des tables ou des divs. Voici n article expliquant pourquoi ni l'un ni l'autre ne devraient être surutilisés.
Je ne vais pas être l'avocat du diable, mais il n'y a pas de relation stricte entre le travail amateur et JavaScript en ligne. Voyons le code source de plusieurs sites Web les plus connus:
- Google,
- Wikipédia,
- Microsoft,
- Adobe,
- Dell,
- IBM.
Chacune de leurs pages d'accueil utilise JavaScript en ligne. Cela signifie-t-il que toutes ces entreprises embauchent des amateurs pour créer leur page d'accueil?
Je fais partie de ces développeurs qui ne peuvent pas mettre de code JavaScript dans HTML. Je ne le fais jamais dans les projets sur lesquels je travaille (sauf probablement certains appels comme <a href="javascript:..."> pour les projets où le JavaScript discret n'était pas une exigence depuis le début, et je supprime toujours le JavaScript en ligne lorsque je refactorise le code de quelqu'un d'autre. Mais cela vaut-il la peine? Pas si sûr.
En termes de performances, vous n'avez pas toujours de meilleures performances lorsque vous placez JavaScript dans un fichier séparé. Habituellement, nous sommes tentés de considérer que la bande passante JavaScript inutilisée gaspille, car elle ne peut pas être mise en cache (sauf lorsque vous traitez avec du HTML cachable statique). Au contraire, un fichier .js externe n'est chargé qu'une seule fois.
En réalité, ce n'est qu'un autre optimisation prématurée: vous avez peut-être raison de penser que l'externalisation de JavaScript accélérerait votre site Web, mais vous pouvez également avoir totalement tort:
- Et si la plupart de vos utilisateurs ont un cache vide?
- Avez-vous considéré qu'avec un fichier .js externe, une demande sera faite à ce fichier à chaque demande de page, si le site Web n'est pas configuré correctement (et généralement, ce n'est pas le cas),
- Le fichier .js est-il vraiment mis en cache (avec IIS, ce n'est peut-être pas si facile)?
Donc, avant d'optimiser prématurément, collectez des statistiques sur vos visiteurs et évaluez les performances avec et sans JavaScript intégré.
Vient ensuite le dernier argument: vous avez mélangé JavaScript et HTML dans votre source, donc vous êtes nul. Mais qui a dit que vous aviez mélangé les deux? Le code source utilisé par le navigateur n'est pas toujours le code source que vous avez écrit. Par exemple, le code source peut être compressé, minifié, ou plusieurs fichiers CSS ou JS peuvent être joints en un seul fichier, mais cela ne signifie pas que vous avez vraiment nommé vos variables a, b, c ... a1, etc. ou que vous avez écrit un énorme fichier CSS sans espaces ni nouvelles lignes. De la même manière, vous pouvez facilement injecter du code source JavaScript externe dans HTML au moment de la compilation ou ultérieurement via les modèles.
Pour conclure, si vous mélangez JavaScript et HTML dans le code source que vous écrivez, vous devriez envisager de ne pas le faire dans vos futurs projets. Mais cela ne signifie pas que si le code source envoyé au navigateur contient du JavaScript en ligne, c'est toujours mauvais.
- C'est peut-être mauvais.
- Cela peut au contraire être un signe que le site Web a été écrit par des professionnels qui se sont souciés des performances, ont effectué des tests spécifiques et ont déterminé qu'il serait plus rapide pour leurs clients d'inclure des parties de JavaScript.
- Ou cela peut ne rien signifier du tout.
donc plutôt honte à la personne qui dit "site très cool, honte au script en ligne dans le code source" en regardant juste la source envoyée au navigateur, sans rien savoir de la façon dont le site a été fait.
Il est généralement bon d'essayer de garder HTML et JS généralement séparés. HTML est pour la vue, JS est pour la logique d'application. Mais d'après mon expérience, un découplage extrême de html et javascript (pour des raisons de pureté) ne le rend pas plus maintenable; il peut en fait être moins maintenable.
Par exemple, j'utilise parfois ce modèle (emprunté à ASP.net) dans la configuration des gestionnaires d'événements:
<input type="button" id="yourId" onclick="clickYourId()" />
ou
<input type="button" id="yourId" onclick="clickYourId(this)" />
Il n'y a aucun mystère sur ce qui déclenche un événement. La raison en est que six mois plus tard, vous pouvez inspecter l'élément (par exemple, dans Chrome) et voir immédiatement quel événement javascript est déclenché.
D'un autre côté, imaginez que vous lisez le code de quelqu'un d'autre, qui est de cent mille lignes, et que vous tombez sur un élément magique qui déclenche un événement javascript:
<input id="yourId" />
Comment pouvez-vous facilement me dire quelle méthode javascript cela appelle? Chrome a rendu cela plus facile, mais peut-être que l'événement est lié à l'id, ou peut-être qu'il est lié au premier enfant du conteneur. Peut-être que l'événement est attaché à l'objet parent. Qui sait? Bonne chance pour le trouver. :)
En outre, je dirais que masquer complètement javascript au concepteur peut en fait augmenter la probabilité qu'il le casse lors d'une mise à jour. Si quelqu'un modifie le code d'un élément magiquement actif, quelle indication dans le code a-t-il qui pourrait lui faire savoir qu'il s'agit d'un élément actif sur la page?
Bref, la meilleure pratique consiste à séparer HTML et Javascript. Mais comprenez également que les règles générales sont parfois contre-productives lorsqu'elles sont poussées à l'extrême. Je plaiderais pour une approche intermédiaire. Évitez les grandes quantités de js en ligne. Si vous utilisez inline, la signature de la fonction doit être très simple comme:
1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)
Un argument qui me manque ici est la possibilité d'une protection accrue contre les attaques cross site scripting .
Il est possible de désactiver l'exécution de JavaScript en ligne dans un navigateur moderne via Politique de sécurité du conten . Cela a réduit le risque que votre site soit victime de XSS. Cela peut être un argument plus convaincant à faire valoir auprès de votre direction pour investir dans la suppression du script en ligne.
Voici quelques raisons.
Le script en ligne ne peut pas être réduit (converti en une version plus courte grâce à la réduction des symboles). Pas un problème sur le haut débit, mais pensez à un appareil mobile dans une zone à faible bande passante ou à des utilisateurs qui sont en itinérance mondiale de données - chaque octet peut compter.
Le script en ligne ne peut pas être mis en cache par le navigateur à moins que la page elle-même ne puisse être mise en cache (ce qui rendrait la page très terne). Les fichiers Javascript externes ne doivent être récupérés qu'une seule fois, même si le contenu de la page change à chaque fois. Peut sérieusement affecter les performances des connexions à faible bande passante.
Le script en ligne est plus difficile à déboguer car le numéro de ligne associé à toute erreur n'a pas de sens.
Le script en ligne est réputé interférer avec les considérations d'accessibilité (508/WAI), bien que cela ne signifie pas que tous les scripts en ligne provoquent des problèmes. Si vous vous retrouvez avec un lecteur d'écran annonçant le contenu du script, vous avez un problème! (Je n'ai jamais vu cela arriver cependant).
Le script en ligne ne peut pas être testé indépendamment de sa page; les fichiers Javascript externes peuvent être exécutés par des tests indépendants, y compris des tests automatisés.
Le script en ligne peut conduire à une mauvaise séparation des préoccupations (comme décrit par de nombreuses autres réponses ici).
Il y a plusieurs raisons qui justifieraient de ne pas inclure le script en ligne:
Tout d'abord, la réponse évidente - cela rend le code plus propre, plus concis, plus facile à comprendre et à lire.
D'un point de vue plus pratique, vous souhaitez souvent réutiliser des scripts/CSS/etc. partout sur votre site Web - en insérant ces parties, vous devrez modifier chaque page chaque fois que vous effectuez un petit changement.
Si vous utilisez un SCM pour votre projet, le fait de bien séparer vos différents composants facilitera le suivi des modifications et des validations pour toutes les personnes impliquées.
Pour autant que je sache, la performance ne serait pas un problème. Cela dépend de beaucoup de choses liées à la nature de votre site Web, aux spécifications de votre serveur, etc. Par exemple, si votre page Web utilise beaucoup de javascript, votre navigateur peut mettre en cache les scripts, ce qui entraînerait de meilleures performances lorsque le code est séparé dans plusieurs fichiers. D'un autre côté, je serais tenté de dire que certains serveurs pourraient servir un seul gros fichier plus rapidement que plusieurs petits fichiers - dans ce cas, on pourrait dire que ne pas séparer le code est meilleur en termes de performances.
Je ne connais aucun test formel dans ce domaine, bien qu'il soit très probable que quelqu'un l'ait fait.
En fin de compte, je dirais que c'est une question de bonnes pratiques plus que toute autre chose, et que les avantages en termes de lisibilité et d'organisation (en particulier par rapport au point 2) font de la séparation du code dans des fichiers distincts une bien meilleure option.
La réponse dépend vraiment de la façon dont le code en ligne (en supposant que javascript) est utilisé.
Nous avons utilisé une combinaison de code en ligne, de SSI (côté serveur inclus), de fichiers js et de fichiers css pour créer les effets que nous voulions et pour réduire également les trajets de retour du serveur pour les événements onClick.
Donc, pour quelqu'un, faire une déclaration générale selon laquelle l'utilisation du "code en ligne" est mauvais sans bien comprendre comment il est utilisé peut être trompeur.
Cela dit, si chaque page a la même copie et le même code javascript au lieu d'utiliser un fichier js, je dis que c'est mauvais.
Si chaque page a sa propre copie et la section CCS collée au lieu d'utiliser un fichier CSS, je dis que c'est mauvais.
Il est également très fastidieux d'inclure l'intégralité de votre bibliothèque js sur chaque page, surtout si aucune des fonctions n'est utilisée sur cette page.
Je vais supposer le javascript en ligne ici.
Sans voir le code, il est difficile d'être sûr. Je soupçonne qu'il faisait référence à l'une des deux choses:
- Vous avez
<script>s dispersés sur toute la page - Tout ce que vous JS est dans l'en-tête de la page, pas dans des fichiers externes
Le premier est une mauvaise décision de conception. La propagation des scripts dans un fichier source rend la page beaucoup plus difficile à maintenir, car vous devez rechercher un script donné. Il vaut mieux garder tout ce code en un seul endroit (je préfère en haut du fichier source).
Quant au second - ce n'est pas nécessairement une mauvaise chose. Code spécifique à la page devrait être dans cette page. Si vous avez du code en double entre les pages, vous devez l'externaliser à l'aide de <script src>. Ensuite, lorsque vous allez créer une nouvelle page, vous pouvez simplement inclure ce fichier et les bogues que vous y avez corrigés n'auront pas à être revisités.
Une raison de NE PAS utiliser InLine Javascript (même pas onclick = "DoThis (this)" sur les boutons), c'est si vous avez l'intention de faire de votre application web une Chrome App. Donc, si vous prévoyez pour porter votre application Web dans une application native Chrome App, commencez par n'inclure AUCUN javascript en ligne. Ceci est expliqué au début de ce que vous devrez modifier (obligatoirement) à partir de votre application Web si vous avez l'intention de le "Chrome-etize".
Quels sont les vrais problèmes avec les scripts en ligne?
Les scripts en ligne sont mauvais et doivent être évités car ils rendent le code plus difficile à lire.
Un code difficile à lire est difficile à maintenir. Si vous ne pouvez pas facilement le lire et comprendre ce qui se passe, vous ne pourrez pas facilement repérer les bogues. S'il est difficile à entretenir, il vous fera perdre plus de temps plus tard en cas de problème.
La difficulté vient généralement des encodages imbriqués. Il y a un problème dans la ligne de code suivante, pouvez-vous le détecter?
<a onclick='alert("What\'s going wrong here?")'>Alert!</a>
Idéalement, le code est écrit d'une manière qui le rend facile à repérer en cas d'erreur. Joel Spolsky a écrit un excellent article qui met l'accent sur ce point en 2005 . Les exemples de code pourraient utiliser une amélioration significative, car ils montrent qu'ils ont 9 ans, mais le concept sous-jacent est toujours solide: écrire du code d'une manière qui facilite la détection des bogues.
Existe-t-il un problème de performances important ou s'agit-il principalement d'une question de bon style?
Les scripts en ligne conduisent à la répétition. Au lieu de modifier une ligne de code pour affecter 100 pages, vous devrez probablement modifier 100 pages individuellement. Ceci ainsi qu'une mauvaise lisibilité affectent sérieusement les performances du mainteneur . Le temps de programmation a un coût réel qui affecte le résultat net d'une entreprise plus rapidement que les quelques millisecondes de la plupart des optimisations de code. Il est certes important d'optimiser les goulots d'étranglement, mais la différence de performances du code est négligeable dans ce cas.
Puis-je justifier une action immédiate sur le front des scripts en ligne auprès de mes supérieurs, lorsqu'il y a d'autres choses à travailler qui pourraient avoir un impact plus évident sur le site?
Non. Si c'est stupide et que ça marche, ce n'est pas stupide.
Le corollaire de la programmation est le suivant: si c'est du code stupide et qu'il fonctionne, ce n'est pas du code stupide. Concentrez-vous sur les vrais problèmes avant d'essayer de réparer quelque chose qui n'est pas cassé. Lorsque le code en ligne a finalement besoin d'une mise à jour, que ce soit dans six heures, six mois ou six ans, corrigez le code d'une manière qui facilite sa maintenance future.
Quels facteurs vous amèneraient à dire "hmm, un travail professionnel ici", et qu'est-ce qui vous ferait reculer devant un travail manifestement amateur?
J'ai tendance à préférer définir "professionnel" simplement comme quelqu'un qui est payé pour effectuer une tâche, plutôt que de supposer qu'il possède une capacité significative dans ce qu'il est payé pour faire. De nombreux professionnels sont certainement capables de faire du bon travail, mais le plus souvent, je me retrouve avec horreur devant le travail terrible que d'autres professionnels ont fait plutôt que quelque chose qu'un amateur a imaginé. Une grande partie de mon travail à ce jour a consisté à récupérer des projets d'épave de train qui ont été bâclés par les premiers développeurs, de sorte que votre kilométrage peut varier.
Cela dit, il est généralement facile de choisir une programmation de qualité entreprise