Est-ce une mauvaise pratique d'intégrer JavaScript dans le corps du HTML?

Question 1

Une équipe sur laquelle je travaille a pris l'habitude d'utiliser des <script>balises à des endroits aléatoires dans le corps de nos pages HTML. Par exemple:

<html>
    <head></head>
    <body>
        <div id="some-div">
            <script type="text/javascript">//some javascript here</script>
        </div>
    </body>
</html>

Je n'avais jamais vu ça auparavant. Cela semble fonctionner dans les quelques navigateurs que j'ai testés. Mais pour autant que je sache, il n'est pas valide de mettre des balises de script dans des endroits comme celui-ci.

Ai-je tort? À quel point est-ce que nous mettons des balises de script dans des balises div comme celle-ci? Y a-t-il des problèmes de compatibilité du navigateur dont je devrais être conscient?

Question 2

C'est parfaitement valable.

Vous ne voudriez pas y mettre de gros blocs de code mélangés dans le balisage (mieux vaut utiliser des scripts externes), mais cela peut être utile pour:

ajouter des informations de liaison supplémentaires pour l'amélioration progressive (lorsque ces données sont difficiles à intégrer dans un nom de classe ou dans une autre approche pour masquer des informations étendues dans les attributs); ou
où il est nécessaire de lancer une amélioration scriptée le plus rapidement possible (plutôt que d'attendre le chargement de la fenêtre / prêt pour le document). Un exemple de ceci serait la mise au point automatique, qui peut irriter si elle est tirée trop tard.

Vous pensez peut-être à des <style>éléments qui ne sont pas autorisés <body>(bien que la plupart des navigateurs le permettent néanmoins).

Question 3

En fait, c'est assez courant. Par exemple , le code de suivi analytique de Google utilise uniquement cette syntaxe:

<script type="text/javascript">
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
  document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>

Si c'est assez bon pour Google ...

Question 4

Il est valide et, selon votre framework côté serveur et la nature du code, parfois très difficile à éviter.

Question 5

Comme plusieurs personnes l'ont mentionné, c'est valable, cela fonctionne et c'est largement utilisé.

Les meilleures pratiques dans la mesure où la sémantique le recommande (ou du moins utilisée pour le recommander) consiste à placer des balises de script à l'intérieur de l'en-tête.

Les meilleures pratiques plus modernes qui prennent en compte les performances recommandent de placer des balises de script (externes et en ligne) en bas à droite avant la balise body, pour permettre au balisage de s'afficher complètement avant l'exécution de tout code JavaScript.

Pour un code plus facile à comprendre et à maintenir, «JavaScript discret» est recommandé, où le code est dans un fichier externe et lie les événements au DOM (JavaScript discret de Google).

Un cas où il est utile d'avoir JavaScript en ligne est d'initialiser des variables avec des valeurs qui n'existent que côté serveur, qui seront ensuite utilisées par le code JavaScript externe.

Question 6

Je préfère mettre des références à des scripts externes dans la tête, et des scripts qui démarrent et initialisent des widgets et autres dans le corps.

Un problème très facile à rencontrer est qu'un élément de script dans le corps ne peut pas accéder aux éléments qui le suivent. De plus, un problème de compatibilité avec les navigateurs est le fait qu'IE ne permet pas aux éléments de script de modifier l'élément dans lequel ils se trouvent. Donc, si vous avez ceci:

<div id="foo">
  <script type="text/javascript">
    document.getElementById("foo")... // do something to it
  </script>
</div>

IE ne va pas aimer votre page. Les anciennes versions d'IE avaient l'habitude de donner des messages d'erreur très cryptiques pour cela ou même de vider toute la page, mais IE8 semble donner un message d'erreur descriptif.

Tant que vous vous assurez que vos scripts n'accèdent qu'au DOM auquel l'accès est sûr, je ne pense pas que ce soit mal de mettre des éléments de script dans le corps. En fait, à mon humble avis, mettre des scripts qui initialisent les widgets après les éléments associés peut être plus lisible que de tout mettre au même endroit (et je pense que cela pourrait également les faire fonctionner plus tôt, ce qui fait que les choses sautent moins à mesure que la page se charge).

Question 7

C'est valable!

Vous pouvez utiliser:

<script type="text/javascript">
    //<![CDATA[

    // Some JavaScript code that perfectly validates in the W3C validator

    //]]>
</script>

Je ne pense pas que vous puissiez dire si c'est une mauvaise pratique en général. Vous devez dire dans l'affaire. Mais c'est sûr qu'il est bon d'avoir tout votre code JavaScript au même endroit. C'est un peu compliqué si vous avez de petits morceaux de code JavaScript partout dans votre fichier HTML.

Question 8

Je n'avais jamais vu ça auparavant. Cela semble fonctionner dans les quelques navigateurs que j'ai testés. Mais pour autant que je sache, il n'est pas valide de mettre des balises de script dans des endroits comme celui-ci.

C'est une pratique valide, mais pas une bonne (ou recommandée).

Ai-je tort? À quel point est-ce que nous mettons des balises de script dans des balises div comme ça? Y a-t-il des problèmes de compatibilité du navigateur dont je devrais être conscient?

Il n'y a aucun problème à placer un <script>sous d'autres éléments (mais il devrait être à l'intérieur <head>ou <body>). Il n'y a pas non plus de problème en termes de compatibilité du navigateur, cependant, l'intégration de scripts JS sur des pages Web présente de sérieux inconvénients (comment / pourquoi ils sont considérés comme mauvais) :

Ajoute du poids à la page
Difficulté (ou probablement impossible) pour la minification
Ne peut pas être migré ou utilisé pour d'autres pages
Ne peut pas être mis en cache (doit être téléchargé à chaque fois que la page est chargée)
Pas de séparation des préoccupations (plus difficile à maintenir)

Question 9

Cependant, il est également bon que vous sachiez que le code JavaScript nécessaire à une section HTML sera là pour cela. Plutôt que d'avoir à affirmer et à construire une inclusion en haut du fichier.

Donc, plutôt que "si vous allez utiliser ce HTML, assurez-vous d'importer xyz.js", vous pouvez simplement inclure le HTML et en finir avec lui.

Donc, ce n'est pas nécessairement un mal horrible. Peut-être pas spectaculairement génial, mais pas vraiment terrible non plus. Cela dépend en quelque sorte de l'intention.

Question 10

Consultez l'interface utilisateur de Yahoo pour les meilleures pratiques: http://developer.yahoo.com/performance/rules.html (JavaScript au bas de la page)

Question 11

C'est certainement légal; Je l'ai vu sur quelques pages ici sur Exforsys par exemple.

Maintenant, c'est un site de tutoriel montrant les bases de HTML et JavaScript donc dans ce contexte c'est parfaitement compréhensible. Cependant, je n'aimerais pas le voir dans le code de production pour autre chose qu'une simple déclaration ou deux. Sans voir ce que vous avez remplacé, // Some JavaScript code hereje ne voudrais pas commenter.

Il ne devrait pas y avoir de problèmes de navigateur avec cela.

Question 12

Il est valide d'ajouter <script> body, mais Internet Explorer ne l'aime vraiment pas. Donc, pour être plus sûr, assurez-vous d'avoir vos scripts dans la balise <head>.

Cela a vraiment fait des ravages (en particulier pour Internet Explorer) dans le projet sur lequel nous travaillons.

Question 13

Je suppose que votre équipe fait cela soit parce qu'elle souhaite insérer un script de manière dynamique, soit parce qu'elle écrit un script qui se déclenchera au chargement de la page.

Je ne dirais pas qu'il y a quelque chose de mal à faire cela quand ABSOLUMENT NÉCESSAIRE (tant que c'est dans un bloc CDATA), mais en dehors de cela, je recommanderais à votre équipe d'utiliser une bibliothèque de scripts comme Prototype ou jQuery, et de garder les scripts externes à la page. C'est généralement plus propre, et les bibliothèques forceront parfois un peu de propreté au code, ce qui, je parie, ne se produit pas actuellement.

Je n'exécuterais pas non plus de fonctions chronophages dans les balises de script en ligne, car elles se produisent lors du chargement de la page et, comme Jason l'a déclaré ci-dessus, pourraient ralentir le chargement de la page. Toutes les bibliothèques de scripts ont des fonctions intéressantes qui vous permettent de faire des choses au chargement de la page, et vous donneront la possibilité de les lancer dans la page, par exemple après le chargement du DOM.

Question 14

C'est l'une des nombreuses meilleures pratiques qui visent autant à améliorer les performances qu'à améliorer votre approche de la programmation.

En fin de compte, dans le développement Web, c'est la sortie du produit qui compte le plus!

Question 15

C'est parfaitement valable, même si cela pourrait nuire à la maintenabilité. Voir aussi Où dois-je mettre les balises <script> dans le balisage HTML? et Pourquoi l'appel à cette fonction jQuery échoue-t-il dans Firefox? .

Question 16

La recommandation souvent formulée selon laquelle les scripts doivent être conservés dans l'en-tête est de s'assurer que le script est chargé avant d'être appelé. Ce problème concerne uniquement certains gestionnaires d'événements. Pour d'autres types de script, cela n'a pas d'importance, et pour certains types (comme document.write), cela n'a aucun sens.

Question 17

Si vous disposez d'un éditeur capable de gérer simultanément la syntaxe HTML et JavaScript. Et si vous aimez d'abord lire quelques lignes de HTML puis JavaScript cpde ... bien sûr. Fonce.

Question 18

Quelques choses:

C'est complètement valide au niveau du code.
C'est complètement déconseillé.

Cela ralentit considérablement le chargement de votre page car le code JavaScript doit s'exécuter avant que le reste de la page puisse être rendu. Si vous travaillez beaucoup avec ce code JavaScript, votre navigateur pourrait se bloquer. Vous devriez essayer de charger (dans la mesure du possible) votre code JavaScript dynamiquement et à la fin de votre page (de préférence avant la </body>balise).

Achetez et lisez du JavaScript haute performance . Cela changera la façon dont vous écrivez le code JavaScript.

Answer 1

84

Une équipe sur laquelle je travaille a pris l'habitude d'utiliser des <script>balises à des endroits aléatoires dans le corps de nos pages HTML. Par exemple:

<html>
    <head></head>
    <body>
        <div id="some-div">
            <script type="text/javascript">//some javascript here</script>
        </div>
    </body>
</html>

Je n'avais jamais vu ça auparavant. Cela semble fonctionner dans les quelques navigateurs que j'ai testés. Mais pour autant que je sache, il n'est pas valide de mettre des balises de script dans des endroits comme celui-ci.

Ai-je tort? À quel point est-ce que nous mettons des balises de script dans des balises div comme celle-ci? Y a-t-il des problèmes de compatibilité du navigateur dont je devrais être conscient?

javascript html Andrew
la source

1

Le fait- document.writesil là ou n'y a-t-il aucune raison particulière pour qu'il soit là où il se trouve?

Martin Smith

8

Les scripts sont autorisés à se produire n'importe où dans le corps. Il n'y a rien de mal à cela. Cela a ses implications (timing, maintenabilité, mélange de code et de mise en page, préférence personnelle), mais sinon, ça va.

Tomalak

@earlz - voyez ma réponse pour savoir pourquoi c'est mauvais. essayant juste de sauver une vie ici. et j'ai raison.

Jason

Answer 2

1

Le fait- document.writesil là ou n'y a-t-il aucune raison particulière pour qu'il soit là où il se trouve?

Martin Smith

Answer 3

8

Les scripts sont autorisés à se produire n'importe où dans le corps. Il n'y a rien de mal à cela. Cela a ses implications (timing, maintenabilité, mélange de code et de mise en page, préférence personnelle), mais sinon, ça va.

Tomalak

Answer 4

@earlz - voyez ma réponse pour savoir pourquoi c'est mauvais. essayant juste de sauver une vie ici. et j'ai raison.

Jason

Answer 5

C'est parfaitement valable.

Vous ne voudriez pas y mettre de gros blocs de code mélangés dans le balisage (mieux vaut utiliser des scripts externes), mais cela peut être utile pour:

ajouter des informations de liaison supplémentaires pour l'amélioration progressive (lorsque ces données sont difficiles à intégrer dans un nom de classe ou dans une autre approche pour masquer des informations étendues dans les attributs); ou
où il est nécessaire de lancer une amélioration scriptée le plus rapidement possible (plutôt que d'attendre le chargement de la fenêtre / prêt pour le document). Un exemple de ceci serait la mise au point automatique, qui peut irriter si elle est tirée trop tard.

Vous pensez peut-être à des <style>éléments qui ne sont pas autorisés <body>(bien que la plupart des navigateurs le permettent néanmoins).

Answer 6

12

+1 pour l'autofocus; parfois je suis sur une connexion lente et ce n'est pas amusant d'être déjà ailleurs (dans le pire des cas: taper un mot de passe) en étant remis dans le premier champ.

Marcel Korpel

Answer 7

1

Cependant, l'intégration de JS peut être utile lorsqu'il n'y a qu'une seule page et pour réduire les recherches sur le serveur. Même histoire avec le CSS intégré. Mais normalement, il est préférable de séparer le code javascript et le css dans des fichiers séparés pour réduire les temps de chargement des pages (en utilisant un en-tête de cache valide) lors de l'utilisation d'un modèle avec les mêmes exigences javascript et css.

Codebeat

Answer 8

17

En fait, c'est assez courant. Par exemple , le code de suivi analytique de Google utilise uniquement cette syntaxe:

<script type="text/javascript">
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
  document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>

Si c'est assez bon pour Google ...

Keltex
la source

37

-1 - ce n'est pas parce que Google le fait que c'est une bonne pratique. Commun! = Bon.

Jason

3

Google Analytics est de toute façon trop compliqué et leur utilisation de JavaScript pour le suivi est en fait un bon exemple de suringénierie.

Esko

De plus, ils vous recommandent de placer le script en bas de la page, pas au milieu, c'est là que les scripts doivent être placés si vous devez les placer. PAS dans l'en-tête où les gens les mettent habituellement

Jason

2

Hors sujet à part: je suis toujours irrité par l'utilisation inutile et bizarre de Google unescape, étant donné que escape/ unescapeIs Evil (et cela \x3Caurait été une façon beaucoup plus simple de le faire).

bobince

3

@Keltex: Le code n'est pas invalide, mais prétendre que c'est une bonne pratique simplement parce que certaines personnes l'utilisent n'est pas un argument valide.

Matti Virkkunen

Answer 9

37

-1 - ce n'est pas parce que Google le fait que c'est une bonne pratique. Commun! = Bon.

Jason

Answer 10

3

Google Analytics est de toute façon trop compliqué et leur utilisation de JavaScript pour le suivi est en fait un bon exemple de suringénierie.

Esko

Answer 11

De plus, ils vous recommandent de placer le script en bas de la page, pas au milieu, c'est là que les scripts doivent être placés si vous devez les placer. PAS dans l'en-tête où les gens les mettent habituellement

Jason

Answer 12

2

Hors sujet à part: je suis toujours irrité par l'utilisation inutile et bizarre de Google unescape, étant donné que escape/ unescapeIs Evil (et cela \x3Caurait été une façon beaucoup plus simple de le faire).

bobince

Answer 13

3

@Keltex: Le code n'est pas invalide, mais prétendre que c'est une bonne pratique simplement parce que certaines personnes l'utilisent n'est pas un argument valide.

Matti Virkkunen

Answer 14

4

Il est valide et, selon votre framework côté serveur et la nature du code, parfois très difficile à éviter.

Pointu
la source

Answer 15

Comme plusieurs personnes l'ont mentionné, c'est valable, cela fonctionne et c'est largement utilisé.

Les meilleures pratiques dans la mesure où la sémantique le recommande (ou du moins utilisée pour le recommander) consiste à placer des balises de script à l'intérieur de l'en-tête.

Les meilleures pratiques plus modernes qui prennent en compte les performances recommandent de placer des balises de script (externes et en ligne) en bas à droite avant la balise body, pour permettre au balisage de s'afficher complètement avant l'exécution de tout code JavaScript.

Pour un code plus facile à comprendre et à maintenir, «JavaScript discret» est recommandé, où le code est dans un fichier externe et lie les événements au DOM (JavaScript discret de Google).

Un cas où il est utile d'avoir JavaScript en ligne est d'initialiser des variables avec des valeurs qui n'existent que côté serveur, qui seront ensuite utilisées par le code JavaScript externe.

Answer 16

Je préfère mettre des références à des scripts externes dans la tête, et des scripts qui démarrent et initialisent des widgets et autres dans le corps.

Un problème très facile à rencontrer est qu'un élément de script dans le corps ne peut pas accéder aux éléments qui le suivent. De plus, un problème de compatibilité avec les navigateurs est le fait qu'IE ne permet pas aux éléments de script de modifier l'élément dans lequel ils se trouvent. Donc, si vous avez ceci:

<div id="foo">
  <script type="text/javascript">
    document.getElementById("foo")... // do something to it
  </script>
</div>

IE ne va pas aimer votre page. Les anciennes versions d'IE avaient l'habitude de donner des messages d'erreur très cryptiques pour cela ou même de vider toute la page, mais IE8 semble donner un message d'erreur descriptif.

Tant que vous vous assurez que vos scripts n'accèdent qu'au DOM auquel l'accès est sûr, je ne pense pas que ce soit mal de mettre des éléments de script dans le corps. En fait, à mon humble avis, mettre des scripts qui initialisent les widgets après les éléments associés peut être plus lisible que de tout mettre au même endroit (et je pense que cela pourrait également les faire fonctionner plus tôt, ce qui fait que les choses sautent moins à mesure que la page se charge).

Answer 17

3

C'est valable!

Vous pouvez utiliser:

<script type="text/javascript">
    //<![CDATA[

    // Some JavaScript code that perfectly validates in the W3C validator

    //]]>
</script>

Je ne pense pas que vous puissiez dire si c'est une mauvaise pratique en général. Vous devez dire dans l'affaire. Mais c'est sûr qu'il est bon d'avoir tout votre code JavaScript au même endroit. C'est un peu compliqué si vous avez de petits morceaux de code JavaScript partout dans votre fichier HTML.

moi
la source

2

c'est une mauvaise pratique en général.

Jason

ok viens de lire ton message, bon à savoir. Je ne le fais jamais de toute façon, mais je n'ai jamais pensé que ça pourrait faire bloquer votre navigateur ... ... comment ça se passe?

meo

1

N'importe quel JavaScript peut bloquer votre navigateur (parfois, je reçois toujours ces boîtes d'alerte dans Firefox avec une option «Abandonner le script» et une option «Continuer le script»).

Marcel Korpel

c'est vrai, n'importe quel JS peut bloquer votre navigateur. cependant, si vous allez le suspendre (évidemment jamais recommandé), mieux vaut le faire une fois que la page est entièrement rendue avec le contenu et que l'utilisateur peut commencer à lire / interagir avec la page. la raison pour laquelle JS bloque votre navigateur est qu'il s'exécute de manière synchrone, ce qui signifie que le navigateur doit attendre que le JS soit complètement exécuté avant de continuer le rendu, car il ne sait pas ce que le JS va faire. Pendant qu'il attend, il n'est pas rendu, ce qui donne l'impression qu'il est suspendu.

Jason

N'utilisez pas ce truc CDATA - c'est un non-sens. Seuls les analyseurs de validation XML comprennent les sections CDATA, donc si vos pages sont servies au format HTML, cela ne fait aucune différence fonctionnelle. Cependant, si vos pages sont servies au format XML, alors il affichera le "//" avant la balise d'ouverture.

Brothercake

Answer 18

2

c'est une mauvaise pratique en général.

Jason

Answer 19

ok viens de lire ton message, bon à savoir. Je ne le fais jamais de toute façon, mais je n'ai jamais pensé que ça pourrait faire bloquer votre navigateur ... ... comment ça se passe?

meo

Answer 20

1

N'importe quel JavaScript peut bloquer votre navigateur (parfois, je reçois toujours ces boîtes d'alerte dans Firefox avec une option «Abandonner le script» et une option «Continuer le script»).

Marcel Korpel

Answer 21

c'est vrai, n'importe quel JS peut bloquer votre navigateur. cependant, si vous allez le suspendre (évidemment jamais recommandé), mieux vaut le faire une fois que la page est entièrement rendue avec le contenu et que l'utilisateur peut commencer à lire / interagir avec la page. la raison pour laquelle JS bloque votre navigateur est qu'il s'exécute de manière synchrone, ce qui signifie que le navigateur doit attendre que le JS soit complètement exécuté avant de continuer le rendu, car il ne sait pas ce que le JS va faire. Pendant qu'il attend, il n'est pas rendu, ce qui donne l'impression qu'il est suspendu.

Jason

Answer 22

N'utilisez pas ce truc CDATA - c'est un non-sens. Seuls les analyseurs de validation XML comprennent les sections CDATA, donc si vos pages sont servies au format HTML, cela ne fait aucune différence fonctionnelle. Cependant, si vos pages sont servies au format XML, alors il affichera le "//" avant la balise d'ouverture.

Brothercake

Answer 23

Je n'avais jamais vu ça auparavant. Cela semble fonctionner dans les quelques navigateurs que j'ai testés. Mais pour autant que je sache, il n'est pas valide de mettre des balises de script dans des endroits comme celui-ci.

C'est une pratique valide, mais pas une bonne (ou recommandée).

Ai-je tort? À quel point est-ce que nous mettons des balises de script dans des balises div comme ça? Y a-t-il des problèmes de compatibilité du navigateur dont je devrais être conscient?

Il n'y a aucun problème à placer un <script>sous d'autres éléments (mais il devrait être à l'intérieur <head>ou <body>). Il n'y a pas non plus de problème en termes de compatibilité du navigateur, cependant, l'intégration de scripts JS sur des pages Web présente de sérieux inconvénients (comment / pourquoi ils sont considérés comme mauvais) :

Ajoute du poids à la page
Difficulté (ou probablement impossible) pour la minification
Ne peut pas être migré ou utilisé pour d'autres pages
Ne peut pas être mis en cache (doit être téléchargé à chaque fois que la page est chargée)
Pas de séparation des préoccupations (plus difficile à maintenir)

Answer 24

Cependant, il est également bon que vous sachiez que le code JavaScript nécessaire à une section HTML sera là pour cela. Plutôt que d'avoir à affirmer et à construire une inclusion en haut du fichier.

Donc, plutôt que "si vous allez utiliser ce HTML, assurez-vous d'importer xyz.js", vous pouvez simplement inclure le HTML et en finir avec lui.

Donc, ce n'est pas nécessairement un mal horrible. Peut-être pas spectaculairement génial, mais pas vraiment terrible non plus. Cela dépend en quelque sorte de l'intention.

Answer 25

2

Consultez l'interface utilisateur de Yahoo pour les meilleures pratiques: http://developer.yahoo.com/performance/rules.html (JavaScript au bas de la page)

Jonathan Lebrun
la source

grand +1! Autant de réponses, mais aucune d'entre elles ne mentionne que les scripts dans HEAD peuvent bloquer d'autres éléments (comme des images! Qui peuvent gâcher la mise en page sur une connexion lente)

David J

Answer 26

grand +1! Autant de réponses, mais aucune d'entre elles ne mentionne que les scripts dans HEAD peuvent bloquer d'autres éléments (comme des images! Qui peuvent gâcher la mise en page sur une connexion lente)

David J

Answer 27

C'est certainement légal; Je l'ai vu sur quelques pages ici sur Exforsys par exemple.

Maintenant, c'est un site de tutoriel montrant les bases de HTML et JavaScript donc dans ce contexte c'est parfaitement compréhensible. Cependant, je n'aimerais pas le voir dans le code de production pour autre chose qu'une simple déclaration ou deux. Sans voir ce que vous avez remplacé, // Some JavaScript code hereje ne voudrais pas commenter.

Il ne devrait pas y avoir de problèmes de navigateur avec cela.

Answer 28

Il est valide d'ajouter <script> body, mais Internet Explorer ne l'aime vraiment pas. Donc, pour être plus sûr, assurez-vous d'avoir vos scripts dans la balise <head>.

Cela a vraiment fait des ravages (en particulier pour Internet Explorer) dans le projet sur lequel nous travaillons.

Answer 29

Je suppose que votre équipe fait cela soit parce qu'elle souhaite insérer un script de manière dynamique, soit parce qu'elle écrit un script qui se déclenchera au chargement de la page.

Je ne dirais pas qu'il y a quelque chose de mal à faire cela quand ABSOLUMENT NÉCESSAIRE (tant que c'est dans un bloc CDATA), mais en dehors de cela, je recommanderais à votre équipe d'utiliser une bibliothèque de scripts comme Prototype ou jQuery, et de garder les scripts externes à la page. C'est généralement plus propre, et les bibliothèques forceront parfois un peu de propreté au code, ce qui, je parie, ne se produit pas actuellement.

Je n'exécuterais pas non plus de fonctions chronophages dans les balises de script en ligne, car elles se produisent lors du chargement de la page et, comme Jason l'a déclaré ci-dessus, pourraient ralentir le chargement de la page. Toutes les bibliothèques de scripts ont des fonctions intéressantes qui vous permettent de faire des choses au chargement de la page, et vous donneront la possibilité de les lancer dans la page, par exemple après le chargement du DOM.

Answer 30

C'est l'une des nombreuses meilleures pratiques qui visent autant à améliorer les performances qu'à améliorer votre approche de la programmation.

En fin de compte, dans le développement Web, c'est la sortie du produit qui compte le plus!

Answer 31

C'est parfaitement valable, même si cela pourrait nuire à la maintenabilité. Voir aussi Où dois-je mettre les balises <script> dans le balisage HTML? et Pourquoi l'appel à cette fonction jQuery échoue-t-il dans Firefox? .

Answer 32

La recommandation souvent formulée selon laquelle les scripts doivent être conservés dans l'en-tête est de s'assurer que le script est chargé avant d'être appelé. Ce problème concerne uniquement certains gestionnaires d'événements. Pour d'autres types de script, cela n'a pas d'importance, et pour certains types (comme document.write), cela n'a aucun sens.

Answer 33

0

Si vous disposez d'un éditeur capable de gérer simultanément la syntaxe HTML et JavaScript. Et si vous aimez d'abord lire quelques lignes de HTML puis JavaScript cpde ... bien sûr. Fonce.

Gai
la source

Cela ressemble à des vues Visual Studio et rasoir qui peuvent gérer les deux. Cela peut être assez pratique dans certains cas (tout le code que vous devez éditer au même endroit). Bien sûr, trop de javascript dans la vue peut rendre la lecture et la compréhension du code difficile et il y a aussi le problème de gonfler le html de sortie.

jahu

Answer 34

Cela ressemble à des vues Visual Studio et rasoir qui peuvent gérer les deux. Cela peut être assez pratique dans certains cas (tout le code que vous devez éditer au même endroit). Bien sûr, trop de javascript dans la vue peut rendre la lecture et la compréhension du code difficile et il y a aussi le problème de gonfler le html de sortie.

jahu

Answer 35

0

Quelques choses:

C'est complètement valide au niveau du code.
C'est complètement déconseillé.

Cela ralentit considérablement le chargement de votre page car le code JavaScript doit s'exécuter avant que le reste de la page puisse être rendu. Si vous travaillez beaucoup avec ce code JavaScript, votre navigateur pourrait se bloquer. Vous devriez essayer de charger (dans la mesure du possible) votre code JavaScript dynamiquement et à la fin de votre page (de préférence avant la </body>balise).

Achetez et lisez du JavaScript haute performance . Cela changera la façon dont vous écrivez le code JavaScript.

Jason
la source

3

Pas mes votes négatifs, mais quand je pense à Yahoo, je pense que YAHOO.util.Event.addListenerjavascript n'est pas efficace / concis. Je ne lirais pas un livre et ne le traiterais pas comme un évangile, parfois vous devez avoir du javascript dans la page elle-même, par exemple une variable rendue dynamiquement, quelque chose que vous ne pouvez pas faire dans un externe .js.

Nick Craver

2

Avez-vous lu le livre? si vous aviez, vous sauriez qu'il enseigne des techniques d'optimisation. des choses comme YAHOO.xx.xx.xxsont mises en cache localement. à l'occasion, oui, il est correct de rendre une variable sur la page, mais cela peut généralement être fait de toute façon en externe si vous venez de définir une valeur d'entrée masquée depuis le serveur. mais j'ai dit que ce n'est pas recommandé, pas mal . aussi, nicholas zakas, l'auteur, connaît sa merde, quel que soit son employeur.

Jason

2

«Chargement dynamique» et «chargement à la fin de la page» sont des choses différentes, et il est hautement improbable qu'il y ait des gains de performance à les utiliser tous les deux. "Avez-vous lu le livre?" et «J'ai raison» ne sont pas non plus la meilleure façon d'entamer une conversation constructive. De plus, la question originale peut être répondue par "parce qu'il finit par s'étouffer avec IE", car certaines opérations ne sont prises en charge que si le script est un enfant direct de body.

Nacho Coloma

Answer 36

3

Pas mes votes négatifs, mais quand je pense à Yahoo, je pense que YAHOO.util.Event.addListenerjavascript n'est pas efficace / concis. Je ne lirais pas un livre et ne le traiterais pas comme un évangile, parfois vous devez avoir du javascript dans la page elle-même, par exemple une variable rendue dynamiquement, quelque chose que vous ne pouvez pas faire dans un externe .js.

Nick Craver

Answer 37

2

Avez-vous lu le livre? si vous aviez, vous sauriez qu'il enseigne des techniques d'optimisation. des choses comme YAHOO.xx.xx.xxsont mises en cache localement. à l'occasion, oui, il est correct de rendre une variable sur la page, mais cela peut généralement être fait de toute façon en externe si vous venez de définir une valeur d'entrée masquée depuis le serveur. mais j'ai dit que ce n'est pas recommandé, pas mal . aussi, nicholas zakas, l'auteur, connaît sa merde, quel que soit son employeur.

Jason

Answer 38

2

«Chargement dynamique» et «chargement à la fin de la page» sont des choses différentes, et il est hautement improbable qu'il y ait des gains de performance à les utiliser tous les deux. "Avez-vous lu le livre?" et «J'ai raison» ne sont pas non plus la meilleure façon d'entamer une conversation constructive. De plus, la question originale peut être répondue par "parce qu'il finit par s'étouffer avec IE", car certaines opérations ne sont prises en charge que si le script est un enfant direct de body.

Nacho Coloma

Est-ce une mauvaise pratique d'intégrer JavaScript dans le corps du HTML?

Réponses: