Partage
  • Partager sur Facebook
  • Partager sur Twitter

commentaires javascript , interpréteur

    22 mars 2011 à 17:44:32

    Bonjour,

    Je suis débutante en javascript et ai besoin d'une explication.

    D'après mes connaissances, javascript est un langage interprété.

    Cependant, n'y a t-il aucune analyse syntaxique qui est effectuée par l'interpréteur( cette analyse syntaxique est habituellement effectuée par le compilateur).
    Je peux constater que les programmes écrits en javascript bloquent bien quand il y a une faute de syntaxe.
    C'est donc qu'il y a une analyse syntaxique qui se produit à un certain moment

    Ensuite, pouvez vous me dire s'il est possible de debugger un programme écrit en javascript et si c'est le cas, comment.

    J'ai telechargé firebug mais ne sais pas s'il est possible de débugger avec cet outil , comme c'est le cas avec
    l'editeur eclipse , par exemple, pour un programme java.


    -concernant le type MIME: j'apprends sur votre site que le type MIME est un identifiant qui décrit un format de données. Ici, dans text/javascript, il s'agit de données textuelles et c'est du Javascript.

    On peut voir qu'il y a deux informations ( text/javscript)pour décrire ce type MIME.
    Est ce toujours le cas ou pas forcément.

    Je vous remercie de votre réponse.

    -concernant le fait que le code javascript doit se placer entre des balises commentaire :D'après ce que j'ai compris, les commentaires sont là pour les vieux navigateurs qui ne comprennent pas la balise <script> et risquent donc d'afficher le code javascript sur la page web.
    Mais Si l'on n'utilise pas un vieux navigateur, alors à quoi bon laisser les commentaires?!! <!-- -->

    Pr ailleurs , j'ai noté également l'explication suivante que je n'ai pas bien comprise

    "Les commentaires d’encadrement servent à isoler le code Javascript pour que le validateur du W3C ne l'interprète pas..
    Si par exemple votre code Javascript contient des chevrons < et >, le validateur va croire qu'il s'agit de balises HTML mal fermées, et donc va invalider la page. Ce n'est pas grave en soi, mais une page sans erreurs, c'est toujours mieux !".

    Le problème est que les chevrons sont à l'intérieur de balises <script> et</script>, je ne comprends donc pas pourquoi le validateur va croire qu'il s'agit de balises html mal fermées!

    -pb du chargement d'un fichier javascript à la fin du body: pourquoi forcément charger un fichier .js à la fin du body : et si on a besoin du code de ce fichier .js durant le chargement de la page, comment fait on?

    Je vous remercie beaucoup de bien vouloir répondre à mes questions.

    Cordialement.

    Nathalie Harbonne

    • Partager sur Facebook
    • Partager sur Twitter
      22 mars 2011 à 17:59:02

      Je vais essayer de répondre à toutes tes questions dans l'ordre mais je promet rien ^^

      Au niveau des fautes de syntaxes, tu le dis toi même, le compilateur analyse le code pour le compiler ... Donc c'est de là qu'il vienne. Car le navigateur va compiler le Javascript puis l'executer.

      Pour débugger un programme, l'utilisation de la console d'erreur est très pratique, et suffit souvent largement. Je te renvois ici pour plus d'informations : http://www.siteduzero.com/tutoriel-3-3 [...] tre-code.html

      Pour le type MIME, oui il est bien composé de deux choses séparés par un slash. Souvent text/autre_chose.

      Les navigateurs assez vieux pour afficher le code JS ne sont plus utilisés, ou très peu. Mais ce n'est pas la raison principale. Comme le dit ton texte, si tu fais valider ta page par le validateur W3C, il va l'invalider si tu utilises une version du xHTML ou HTML qui ne permet pas l'utilisation de chevrons dans ton code JS du faites qu'ils les prennent pour des balises mal fermés. Mais ce n'est pas indispensable vu que normalement un script JS doit être dans un fichier à part, ça permet de mieux organiser son code et aussi d'éviter ce genre de désagréments.

      Le chargement après body est surtout pour que tous le code HTML soit déjà chargés. En effet, si tu récupéres un div avec son id à partir du JS et que celui ci n'est encore pas chargés ça va pas le faire ... En tous cas, les scripts qui ont besoins de s'executer pendant le chargement c'est vraiment rare, je n'en ai même jamais vu. Mais dans ce cas là tu peux très bien mettre ton code JS avant.
      • Partager sur Facebook
      • Partager sur Twitter
        22 mars 2011 à 18:05:57

        C'est interprété, ce qui veut dire qu'il lit ligne par ligne (en gros) sans connaître la suite et s'il arrive à une incohérence, il envoie une erreur.
        var i;// Préparer une case mémoire pour un nombre
        i = 0;// Y mettre la valeur 0
        while ( i < 5 ) {// Tester si ( i < 5 ) est vrai. Si non, aller ligne 6
            i++;// Ajouter 1 à la valeur de i
        }//retourner ligne 3
        a;// Regarder la valeur stockée dans a | Erreur : a n'a pas de case mémoire allouée
        


        Firebug affiche les erreurs comme celle-ci et permet de regardée le DOM modifié par la JavaScript.

        Le type MIME, c'est inutile maintenant ;)

        Les commentaires aussi. Il faut juste mettre des commentaires CDATA si tu codes en XHTML.

        Pour le fait de mettre après le body, c'est pour éviter de bloquer le chargement du reste.
        Qu'est-ce que les utilisateurs veulent voir ? Le contenu ou le JavaScript qui va avec ?
        Plutôt le contenu donc on laisse se charger le contenu d'abord.
        D'ailleurs, quand tu mets un lien vers une ressource externe (script ou feuille de style), le navigateur s'arrête quand il la lit et attend qu'elle soit téléchargée et interprétée pour continuer, ce qui fait que si tu as un gros script, le contenu risque d'attendre longtemps.
        Enfin, mettre le script à la fin du body permet, sur des pages assez grandes, d'éviter de mettre les scripts qui ont besoin du DOM (que l'on met normalement dans window.onload) de se lancer directement puisque tous les éléments le précédent sont déjà dans le DOM.

        EDIT : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Grilled.
        • Partager sur Facebook
        • Partager sur Twitter
          22 mars 2011 à 18:14:56

          Hum ... Après ton post j'ai un doute sur quelque chose ... Le JS est à ma connaissance compilé par la navigateur, la preuve, TraceMonkey et Crankshaft deux compilateurs Javascript utilisés respectivement sur Firefox et Google Chrome ... Mais tu dis qu'il est interprété ?
          • Partager sur Facebook
          • Partager sur Twitter
            22 mars 2011 à 18:29:21

            A la base, c'est interprété.
            Ensuite, il y a eu des moteurs qui optimisaient le code et maintenant, il y en a qui le compilent.
            C'est pour ça que c'est de plus en plus rapide.
            Mais c'est compilé à la volée, pas à l'avance (peut-être que ça viendra ?).
            • Partager sur Facebook
            • Partager sur Twitter
              22 mars 2011 à 18:30:53

              Oui ça je sais que c'est compilé à la volée ^^
              Après les navigateurs qui interprètent le JS se sont les plus trop récent. La plupart on un compilateur maintenant. Enfin merci de m'avoir indiqué ça :p
              • Partager sur Facebook
              • Partager sur Twitter
              Anonyme
                23 mars 2011 à 1:12:45

                Javascript un langage interprété ou compilé ?
                Le blog d'internet Explorer nous apporte quelques éléments de réponse

                JavaScript est devenu omniprésent dans les applications Web modernes notamment à travers l’utilisation de librairies Ajax ou jQuery par exemple. IE 8 avait amélioré de manière significative les performances de l’interpréteur JavaScript par rapport aux précédentes versions (IE6 et IE7) mais restait malgré tout derrière les concurrents en performance pure.

                IE9 va tirer mieux partie des nouvelles architectures multi-cœurs de nos processeurs. Tout d’abord, lorsque la page commencera à se charger, l’interpréteur “classique” de script démarra sur le 1er cœur. Déjà, ce nouvel interpréteur a été réécrit pour être plus rapide que celui d’IE8. En parallèle, IE9 utilisera un des autres cœurs disponible pour compiler en tâche de fond en code natif le JavaScript contenu dans la page. Dès que cette compilation sera terminée, IE9 utilisera le code natif en lieu et place du code interprété pour des performances nettement supérieures. Le nom de code de ce nouveau moteur est Chakra.


                Ceci dit, il convient de noter que l'incorporation des fonctions dans des objets (et leur interprétation lors de la construction de ces objets) accélère grandement leur exécution. Javascript tend alors à se rapprocher, à cet égard, du java ou du C (deux applications ici et , à ma connaissance, inédites en javascript).

                • Partager sur Facebook
                • Partager sur Twitter

                commentaires javascript , interpréteur

                × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                • Editeur
                • Markdown