Pourquoi devrais-je éviter les scripts en ligne?

Un ami averti a récemment consulté un site Web que j'ai aidé à lancer et a commenté quelque chose comme "un site très cool, dommage pour les scripts intégrés dans le code source".

Je suis certainement en mesure de supprimer le script en ligne où il se produit; Je suis vaguement conscient que c'est "une mauvaise chose". Ma question est la suivante: quels sont les problèmes réels du script en ligne? Existe-t-il un problème de performances important ou s'agit-il principalement d'une question de style? Puis-je justifier auprès de mes supérieurs des actions immédiates sur le front des scripts en ligne, alors qu'il y a d'autres choses à travailler qui pourraient avoir un impact plus évident sur le site? Si vous vous présentiez sur un site Web et jetiez un coup d'œil au code source, quels facteurs vous pousseraient à dire «hmm, travail professionnel ici» et qu'est-ce qui vous ferait reculer d'un travail manifestement amateur?

D'accord, cette question s'est transformée en plusieurs questions dans l'écriture. Mais fondamentalement, le script 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 style?

Les avantages ne sont pas basés sur les performances, ils sont (comme Michael l'a souligné dans son commentaire) plus liés à la séparation de la vue et du contrôleur. Le fichier HTML / CSS devrait, idéalement, ne contenir que la présentation et des fichiers distincts devraient être utilisés pour les scripts. Cela facilite la lecture et la maintenance des aspects visuels et fonctionnels pour vous (et vos pairs).

Puis-je justifier auprès de mes supérieurs des actions immédiates sur le front des scripts en ligne, alors qu'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 puissances qui se consacrent uniquement à la maintenance, même si cela vous fera économiser de l’argent à long terme. Dans ce cas cependant, je ne pense pas qu'il soit si important de tout arrêter et de vous débarrasser de votre script en ligne. Au lieu de cela, assurez-vous simplement que vous faites un effort conscient pour rectifier les zones à mesure que vous les travaillez pour d'autres raisons. Le code de refactoring devrait être quelque chose que vous faites régulièrement, mais seulement un peu à la fois.

Si vous vous présentiez sur un site Web et jetiez un coup d'œil au code source, quels facteurs vous pousseraient à dire «hmm, travail professionnel ici» et qu'est-ce qui vous ferait reculer d'un travail manifestement amateur?

Le facteur numéro un qui me dirait que ce n'est pas professionnel est la surutilisation de tables ou de divs. Voici un article expliquant pourquoi on ne devrait pas en abuser.

Je ne serai pas l'avocat du diable, mais il n'y a pas de relation stricte entre le travail d'amateur et le JavaScript inline. Voyons le code source de plusieurs sites Web les plus connus:

• Google,
• Wikipédia,
• Microsoft,
• Adobe,
• Dell,
• IBM.

Toutes leurs pages d'accueil utilisent JavaScript. Cela signifie-t-il que toutes ces entreprises engagent des amateurs pour créer leurs pages d'accueil?

Je suis l'un de ces développeurs qui ne peuvent pas insérer de code JavaScript dans HTML. Je ne le fais jamais dans les projets sur lesquels je travaille (sauf probablement des appels comme <a href="javascript:...">pour les projets dans lesquels du code JavaScript discret n'était pas obligatoire depuis le début, et je supprime toujours le code inline en code JavaScript lorsque je refacture le code de quelqu'un d'autre. Mais cela en vaut-il la peine? ? Pas si sûr.

En termes de performances, les performances ne sont pas toujours meilleures lorsque vous insérez du JavaScript dans un fichier séparé. Habituellement, nous sommes tentés de considérer que la bande passante inerte en JavaScript représente une perte de bande passante, car elle ne peut pas être mise en cache (sauf lorsque vous utilisez du code HTML statique pouvant être mis en cache ). À l'inverse, un fichier extern .js n'est chargé qu'une seule fois.

En réalité, il ne s'agit que d'une autre optimisation prématurée : vous avez peut-être raison de penser que l'externalisation de JavaScript rendrait votre site Web plus rapide, mais vous pouvez également vous tromper totalement:

• Et si la plupart de vos utilisateurs viennent avec un cache vide?
• Pensez-vous 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 ce n'est généralement pas le cas),
• Le fichier .js est-il vraiment mis en cache (avec IIS, ce n'est peut-être pas si facile)?

Avant d’optimiser prématurément, recueillez des statistiques sur vos visiteurs et évaluez les performances avec et sans JavaScript.

Vient ensuite l'argument final: vous avez mélangé JavaScript et HTML dans votre source, donc vous êtes nul. Mais qui a dit que vous avez 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 comprimé, minifiés ou plusieurs fichiers CSS ou JS peut être joint en un seul fichier, mais cela ne signifie pas que vous avez vraiment vos variables nommé 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.

En conclusion, si vous mélangez JavaScript et HTML dans le code source que vous écrivez, vous devriez envisager de ne pas le faire dans vos projets futurs. Mais cela ne signifie pas que si le code source envoyé au navigateur contient du code JavaScript intégré, il est toujours mauvais.

• C'est peut-être mauvais.
• Cela peut au contraire indiquer que le site Web a été écrit par des professionnels soucieux de la performance, qui ont effectué des tests spécifiques et qui ont déterminé qu'il serait plus rapide pour leurs clients d'intégrer des parties de JavaScript.
• Ou cela ne veut peut-être rien dire du tout.

donc plutôt honte à la personne qui dit "site très cool, honte au sujet des scripts intégrés dans le code source" en regardant uniquement le code source envoyé au navigateur, sans rien savoir de la façon dont le site Web a été créé.

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 de l'application. Mais selon mon expérience, le découplage extrême de HTML et de javascript (pour des raisons de pureté) ne le rend pas plus facile à gérer; En réalité, il peut être moins facile à gérer.

Par exemple, j’utilise parfois ce modèle (emprunté à ASP.net) pour configurer 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 pas de 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'autre part, imaginez que vous lisiez le code de quelqu'un d'autre, qui compte cent mille lignes, et que vous rencontriez 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 simplifié les choses, mais peut-être que l'événement est lié à l'ID ou peut-être au premier enfant du conteneur. Peut-être que l'événement est attaché à l'objet parent. Qui sait? Bonne chance pour le trouver. :)

De plus, je dirais que cacher complètement le javascript au concepteur peut en fait augmenter la probabilité qu'il le casse lors d'une mise à jour. Si une personne modifie du code pour un élément actif comme par magie, quelle indication dans le code leur permet-elle de savoir qu'il s'agit d'un élément actif sur la page?

En bref, la meilleure pratique consiste à séparer HTML et Javascript. Mais comprenez également que les règles empiriques sont parfois contre-productives lorsqu'elles sont poussées à l'extrême. Je plaiderais pour une approche médiane. Évitez les grandes quantités de js en ligne. Si vous utilisez inline, la signature de la fonction devrait être très simple, comme ceci:

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

Un argument qui me manque ici est la possibilité d'une protection accrue contre les attaques de script entre sites .

Il est possible de désactiver l'exécution du code JavaScript intégré dans un navigateur moderne via la stratégie de sécurité du contenu . Cela réduisait le risque que votre site soit victime de XSS. Cela peut constituer un argument plus convaincant pour amener votre direction à investir dans la suppression du script en ligne.

Voici quelques raisons.

1. Le script en ligne ne peut pas être minifié (converti en une version plus courte par réduction de symbole). Pas d'inquiétude pour le haut débit, mais considérons un appareil mobile dans une zone à faible bande passante ou des utilisateurs en itinérance de données globale - chaque octet peut compter.

2. Le script en ligne ne peut pas être mis en cache par le navigateur à moins que la page elle-même 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 sur les connexions à faible bande passante.

3. Le script en ligne est plus difficile à déboguer car le numéro de ligne associé à une erreur n'a pas de sens.

4. Le script en ligne est réputé interférer avec les considérations d'accessibilité (508 / WAI), bien que cela ne signifie pas que tout le script en ligne pose problème. Si vous vous retrouvez avec un lecteur d'écran annonçant le contenu du script, vous avez un problème! (Jamais vu cela arriver cependant).

5. Le script en ligne ne peut pas être testé indépendamment de sa page. Les fichiers Javascript externes peuvent être exécutés via des tests indépendants, y compris des tests automatisés.

6. Le script en ligne peut conduire à une séparation médiocre des problèmes (comme décrit par de nombreuses autres réponses ici).

Plusieurs raisons peuvent justifier de ne pas inclure le script en ligne:

• Tout d'abord, la réponse évidente est que le code est plus propre, plus concis, plus facile à comprendre et à lire.

• D'un point de vue plus pratique, vous souhaiterez souvent réutiliser des scripts / CSS / etc. partout sur votre site Web, inclure ces parties impliquerait de modifier chaque page à chaque fois que vous apportez une petite modification.

• Si vous utilisez un GDS pour votre projet, la séparation de vos différents composants facilitera le suivi des modifications et des validations pour toutes les personnes concernées.

Autant que je sache, la performance ne serait pas une préoccupation. Cela dépend de nombreux facteurs liés à 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înera de meilleures performances. le code est séparé en plusieurs fichiers. D'un autre côté, je serais tenté de dire que certains serveurs peuvent traiter un seul fichier volumineux plus rapidement que plusieurs fichiers plus petits. Dans ce cas, on pourrait affirmer que ne pas séparer le code est préférable en termes de performances.

Je ne suis au courant d'aucun test officiel 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 avant tout une question de bonnes pratiques et que les avantages en termes de lisibilité et d’organisation (plus précisément le 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), de fichiers js et de fichiers css pour créer les effets souhaités et réduire également le nombre de voyages de retour du serveur pour les événements onClick.

Il est donc trompeur pour une personne de faire une déclaration générale affirmant que l’utilisation du «code en ligne» est mauvaise sans bien comprendre en quoi il est utilisé.

Cela dit, si chaque page a la même copie et que le code javascript est collé au lieu d'utiliser un fichier js, je dis que c'est mauvais.

Si chaque page a sa propre section CCS copiée et collée au lieu d'utiliser un fichier css, je dis que c'est mauvais.

Il est également très fastidieux d'inclure toute votre bibliothèque js sur chaque page, surtout si aucune des fonctions n'est utilisée sur cette page.

Je vais assumer javascript en ligne ici.

Sans voir le code, il est difficile d’en être sûr. Je soupçonne qu'il faisait référence à l'une des deux choses suivantes:

1. Vous êtes <script>dispersés sur toute la page
2. 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 à gérer, car vous devez rechercher un script donné. Il est bien préférable de garder tout ce code au même endroit (je préfère en haut du fichier source).

Quant à la seconde - ce n'est pas nécessairement une mauvaise chose. Le code spécifique à la page doit être dans cette page. Si vous avez du code en double entre les pages, vous devez l'externaliser en utilisant <script src>. Ensuite, lorsque vous créez une nouvelle page, vous pouvez simplement inclure ce fichier et tout bogue que vous aurez corrigé ne devra pas être revisité.

Une raison de ne pas utiliser Javascript en ligne (même pas onclick = "DoThis (this)" sur les boutons) est si vous souhaitez transformer votre application Web en application Chrome. Par conséquent, si vous envisagez de porter votre application Web dans une application Native Chrome, commencez par NE PAS inclure de JavaScript javascript. Ceci est expliqué dès le début de ce que vous devrez changer (obligatoirement) à partir de votre application Web si vous avez l’intention de la "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 à maintenir, il perdra plus de temps par la suite en cas de problèmes.

La difficulté provient généralement d'encodages imbriqués. Il y a un problème dans la ligne de code suivante, pouvez-vous le repérer?

<a onclick='alert("What\'s going wrong here?")'>Alert!</a>

Idéalement, le code est écrit de manière à ce qu'il soit facile de détecter les erreurs éventuelles. Joel Spolsky a écrit un excellent article qui souligne ce point en 2005 . Les exemples de code pourraient nécessiter une amélioration significative, car ils affichent un âge de 9 ans, mais le concept sous-jacent est toujours valable: écrire du code de manière à faciliter la détection des bogues.

Existe-t-il un problème de performances important ou s'agit-il principalement d'une question de style?

Le script en ligne conduit à la répétition. Au lieu de modifier une ligne de code pour affecter 100 pages, vous devrez probablement modifier 100 pages individuellement. Ceci, associé à une mauvaise lisibilité, affecte 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. Certes, l'optimisation des goulots d'étranglement est importante, mais la différence de performance du code est négligeable dans ce cas.

Puis-je justifier auprès de mes supérieurs des actions immédiates sur le front des scripts en ligne, alors qu'il y a d'autres choses à travailler qui pourraient avoir un impact plus évident sur le site?

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 que cela 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 nécessite éventuellement une mise à jour, que ce soit dans six heures, six mois ou six ans, corrigez le code de manière à faciliter la maintenance future.

Quels facteurs vous amèneraient à dire "hmm, travail professionnel ici" et qu'est-ce qui vous ferait reculer d'un travail manifestement amateur?

J'ai tendance à préférer définir le terme "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 rémunéré à faire. Beaucoup de professionnels sont certes capables de faire du bon travail, mais le plus souvent, je me retrouve horrifié par le travail épouvantable accompli par d’autres professionnels plutôt que par un amateur. À ce jour, une grande partie de mon travail a consisté à récupérer des projets d'accident de train qui ont été bâclés par les développeurs initiaux. Votre kilométrage peut donc varier.

Cela dit, il est généralement facile de choisir une programmation de qualité entreprise