Sondage Le Javascript c'est

Posté par .
Tags : aucun
0
4
jan.
2007
  • génial, j'en ai mis partout sur mon blog ! :
    87
    (2.2 %)
  • un outil sympathique :
    437
    (11.3 %)
  • redevenu à la mode avec le web 2.0 :
    855
    (22.1 %)
  • un moyen de faire ramer n'importe quelle machine :
    478
    (12.3 %)
  • pas supporté de la même manière par 2 navigateurs :
    654
    (16.9 %)
  • toujours aussi inutile qu'au début :
    171
    (4.4 %)
  • utile grâce aux libraires protoype & Co :
    136
    (3.5 %)
  • une bouse infame :
    818
    (21.1 %)
  • quoi ? :
    235
    (6.1 %)

Total : 3871 votes

La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.
  • # javascript saibien

    Posté par (page perso) . Évalué à 2.

    Le javascript saibien, ça permet de faire des google maps ou des gmail, et aussi des web-albums qui préchargent les images suivantes et utilisent des raccourcis clavier (malheureusement un truc aussi basique que le préchargement semble totalement échapper à flickr, pour lequel j'ai de plus en plus de mal à comprendre la popularité).
    • [^] # Re: javascript saibien

      Posté par . Évalué à 4.

      Euh... il est possible de créer des raccourcis clavier en HTML pur !

      Il suffit d'utiliser l'attribut accesskey des balises A, AREA, BUTTON, INPUT, LABEL, LEGEND ou TEXTAREA.

      Source : http://www.w3.org/TR/html4/interact/forms.html#adef-accesske(...)
      • [^] # Re: javascript saibien

        Posté par . Évalué à 6.

        J'allais dire qu'en pur, les balises sont en minuscule, mais tu parles bien de HTML et pas de XHTML, donc au temps pour moi.
        Par contre, les balise en majuscule, je trouve ça horrible, j'ai des bouquins ou les exemples de codes sont balisés en majuscules, et je trouve ça vraiment désagréable et illisible.
        C'est tout ce que j'avais à dire à propos de ça.
        • [^] # Re: javascript saibien

          Posté par (page perso) . Évalué à 1.

          J'ai lu des documentations qui expliquaient qu'il valait mieux mettre les balises en majuscule pour les différencier du contenu.
          (mais ça devait être avant l'invention de la coloration syntaxique)
        • [^] # Re: javascript saibien

          Posté par . Évalué à 3.

          En fait, j'ai fait un copier/coller du tableau des attributs dans la spec du W3C. J'ai eu la flemme de tout repasser en minuscules. C'est vrai que j'utilise systématiquement les balises en minuscules, même quand je fais du HTML (même si j'en fais de moins en moins au profit de XHTML).

          Sinon, à propos d'une comparaison entre minuscules et majuscules, il faut savoir qu'un flux HTML avec les balises en minuscules se compresse mieux que le même avec des majuscules... à moins d'avoir un site où la majorité du contenu est en majuscules :-/ (désolé, je ne sais plus à quel endroit j'ai vu cette comparaison)
          • [^] # Re: javascript saibien

            Posté par . Évalué à 2.

            Sinon, à propos d'une comparaison entre minuscules et majuscules, il faut savoir qu'un flux HTML avec les balises en minuscules se compresse mieux que le même avec des majuscules... à moins d'avoir un site où la majorité du contenu est en majuscules
            ...ce qui se comprend au sens d'un codage de Huffman (http://fr.wikipedia.org/wiki/Codage_de_Huffman ) vu que le taux de compression est lié à la fréquence des symboles.

            Si un texte contenant toutes les lettres de l'alphabet est essentiellement en minuscules tandis que les balises sont écrites en majuscules, on a une plus grande diversité des symboles et l'information est dispersée. Le taux de compression restera modéré. En revanche, si toute la page web est écrite à l'aide d'un jeu de 10 caractères, le taux de compression sera fabuleux. Il est plus facile de compresser "aaaaaaaaaahhhhhh" que "uejfuqlndgshfrpt" qui pourtant a une longueur identique.

            ...et sinon... tu codes souvent en te souciant de la compression du flux HTML? si oui, je suis curieux de savoir si c'est dans un but professionnel précis, ou juste par souci de perfection.
            • [^] # Re: javascript saibien

              Posté par . Évalué à 1.

              ...et sinon... tu codes souvent en te souciant de la compression du flux HTML? si oui, je suis curieux de savoir si c'est dans un but professionnel précis, ou juste par souci de perfection.
              Euh... non ! Je disais juste ça sur le ton de la boutade ;-) J'aime voir s'enflammer les gens sur des points de détails qui ne sont pas spécifiés dans la norme à la base...

              Sinon, pour diminuer la taille des pages, il suffit de supprimer tous les espaces et retours chariot, et ne surtout mettre aucun commentaire ! Un instant... on me souffle dans mon oreillette que j'ai utilisé ça dans un de mes précédents projets pro : une appli J2EE avec un filtre qui supprimait commentaires et blancs. Résultat, c'était la galère quand on devait regarder le source généré pour traquer les bugs. Sans compter que la suppression de certains blancs changeait la mise en forme avec IE. Et non on ne pouvait pas désactiver le filtre, le serveur de dev n'était pas chez nous (mais chez le client) et nous n'avions pas accès ni à la classe du filtre, ni à la config de la webapp.
    • [^] # Re: javascript saibien

      Posté par . Évalué à 5.

      Le javascript, c'est le bien si c'est utilisé intelligemment, avec parcimonie et surtout s'il n'est pas possible de faire ce qu'on veut autrement.

      Le javascript c'est le mal si on récupère plein de scripts buggés du web pour faire tout et n'importe quoi, en dépit du fonctionnement et de l'accessibilité de la page.
      • [^] # Re: javascript saibien

        Posté par (page perso) . Évalué à 5.

        Le javascript, c'est le bien si c'est utilisé intelligemment, avec parcimonie et surtout s'il n'est pas possible de faire ce qu'on veut autrement.


        Et je rajoute, si c'est non obstructif (unobtrusive). C'est a dire si le contenu est toujours accessible, meme sans javascript active.

        Il y a encore trop souvent des formulaires dont le bouton submit a ete odieusement supprime en faveur d'un vilain evenement onclick dans le but d'y inclure des verifications de chaine, alors qu'un evenement onsubmit return false applique a la balise form en aurait fait de meme mais en tellement plus propre (oui, ca necessite aussi de verifier les chaines cote serveur, mais ca devrait de toute facon etre le cas).


        P.S. desole si mon francais a l'air etrange, ca fait des annees.... et un clavier qwerty sous les mains.
      • [^] # Re: javascript saibien

        Posté par . Évalué à 3.

        Au début je trouvais ça toupourri, ça faisait des pages web super lentes, c'était utilisé par les boolays pour faire des textes défilants qui servent à rien dans la barre de status et faire des popups "Voté pour mon sit lol", tout en rendant les 3/4 des sites avec du JS incompatibles.

        Maintenant qu'on a DOM, Ajax et plein de frameworks bien codés, on arrive enfin à faire des choses intéressantes et propres avec, et ça c'est kewl.
      • [^] # Re: javascript saibien

        Posté par . Évalué à 2.

        En parlant de Javascript bien géré, non obstructif, avec gestion des navigateurs pour lesquels il est désactivé, voici un bon tuto de la part d'Alsacreation :
        http://css.alsacreations.com/Tutoriels-JavaScript/bonnes-pra(...)
    • [^] # Re: javascript saibien

      Posté par . Évalué à 2.

      Non c'est pas bien, ca empeche de pouvoir naviguer en mode texte.
      Depuis qu'il y a du javascript partout, je n'utilise plus (trop) emacs-w3m.

      D'ailleurs, qu'en est-il de l'accessibilite quand il y a du javascript?
  • # ça pue c'est pas xhtml1 strict

    Posté par (page perso) . Évalué à 1.

    Comment indexer du contenu partiellement ou totalement généré par du js ? Sinon il y a quand même des trucs sympa en js. C'est un langage qui mériterait d'être utilisé hors du web pour donner des cours :) car tous les ordis ont un butineur web. A quand des articles dans linuxmag avec des exemples en javascript bien écrit
    <SCRIPT LANGUAGE="JavaScript">
    function somme_N_entiers (N) {
        for (i=1,somme=0;    i <=N ; somme+=i, 
                document.writeln("Pour i = ", i++,  "la somme est  " , somme, "") );
        return somme
    }
     var nombre=  prompt("Somme des entiers jusqu'à N = ", 10);
    document.write("Somme des ", nombre, " premiers entiers  = ", somme_N_entiers(nombre) );
    < /SCRIPT>
    
    • [^] # Re: ça pue c'est pas xhtml1 strict

      Posté par . Évalué à 2.

      D'un autre côté, le fait qu'il soit compliqué d'indexer du contenu généré par JS peut être un atout.
      Il est ainsi possible de générer des solutions évitant l'indexation des adresses mail par des bots mal intentionnés, évitant du même coup le spam qui va avec.
      • [^] # Re: ça pue c'est pas xhtml1 strict

        Posté par (page perso) . Évalué à 4.

        Pour le codage des adresses mail on peut utiliser http://aspirine.org/emailcode.php
        • [^] # Re: ça pue c'est pas xhtml1 strict

          Posté par . Évalué à 3.

          Pourquoi se casser la tête à ce point ? Parce que bon, avec mon extension NoScript activée sur mon firefox, je ne vois pas les adresses affichées de la sorte.

          Ce que je fais, c'est coder l'adresse en décimal ou en hexadécimal. J'ai une adresse depuis plusieurs années sur un site relativement bien visité (plusieurs milliers de hits par jour) et je n'ai reçu aucun spam dessus.

          Exemple : <a href="&#0109;&#0097;&#0105;&#0108;&#0116;&#0111;&#0058;&#0116;&#0111;&#0116;&#0111;&#0064;&#0101;&#0120;&#0097;&#0109;&#0112;&#0108;&#0101;&#0046;&#0099;&#0111;&#0109;">Ecrivez moi</a>

          Pour ceux qui n'auraient pas envie de copier/coller ça dans un éditeur pour l'afficher dans un navigateur, c'est un lien vers "mailto:toto@example.com". Les navigateurs comprennent, mais pas les extracteurs d'adresses.

          Je vous laisse en exercice l'écriture du générateur ;-)
          • [^] # Re: ça pue c'est pas xhtml1 strict

            Posté par . Évalué à 3.

            C'est pas le genre d'astuces qu'il faut répandre trop largement, sinon les exracteurs d'adresses ils vont vite comprendre.
          • [^] # Re: ça pue c'est pas xhtml1 strict

            Posté par (page perso) . Évalué à 2.

            faut pas le dire mais tu peux aussi doubler avec de l'urlencodage ... %xx pour chaque caractere de l'email.
            Ou alors e créer une DTD rien que pour toi dans laquelle tu définit de nouvelles entités. Mais cela ne marche que avec gecko en mode strict.
            Exemple :

            <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd" [
            <!ENTITY at "@">
            ]>
            ...
            @at;
            ...
    • [^] # Re: ça pue c'est pas xhtml1 strict

      Posté par (page perso) . Évalué à 1.

      Je ne suis pas d'accord... bien préparé, un site avec du JS peut être parfaitement indexable par les moteurs de recherche et accessibles aux gens n'ayant pas javascript activé.

      L'idée est de tout faire clean sans JS, puis de l'ajouter par la suite, pour changer les liens par exemple grâce à des selecteurs CSS. Donc, on utilise JS comme du CSS, tout en gardant les contenus dans le xhtml :-)

      Pour faire cela, une librairie comme MooTools par exemple a tout ce qu'il faut.
      • [^] # Re: ça pue c'est pas xhtml1 strict

        Posté par (page perso) . Évalué à 2.

        En utilisant pas JS qui n'apporte rien d'essentiel a un contenu textuel, on est encore plus certain de faire un truc clean :)

        Faut savoir si le wbe a pour vocation d'etre un outil de partage de la connaissance, ou juste un attrape pigeon pour les entreprise ou le bac a sable des d{veloppeurs.

        Ce qui ne m'empeche pas d'apprecier le JS tant qu'il est utilise avec parcimonie...
      • [^] # Re: ça pue c'est pas xhtml1 strict

        Posté par . Évalué à 0.

        Un exemple de code JavaScript qui passe au validateur XHTML 1.0 Strict / XHTML 1.1 :
        <script type="text/javascript">
        	<!--/*--><![CDATA[//><!--
        	
        	// *** Ajoute le bouton "Generation du lien" ***
        	function fnAddButton() {
        		// Test des methodes
        		if (!document.getElementById || !document.createElement) {
        			return;
        		}
        		
        		// Creation d'un bouton
        		var oButton = document.createElement('input');
        		oButton.setAttribute('id', 'copyButton');
        		oButton.setAttribute('type', 'button');
        		oButton.setAttribute('value', 'Generation du lien');
        		oButton.setAttribute('onclick', 'fnCopyUrl()');
        		
        		// Recuperation du paragraphe du formulaire
        		var oFormP = document.getElementById('formP');
        		if (!oFormP) {
        			return;
        		}
        		
        		// Ajout du bouton au paragraphe du formulaire
        		oFormP.appendChild(oButton);
        	}
        	
        	// *** Extrait l'url a telecharger du cadre de texte ***
        	function fnExtractUrl() {
        		// Test des methodes
        		if (!document.getElementById) {
        			return;
        		}
        		
        		// Recuperation du cadre de texte
        		var oInputText = document.getElementById('inputUrl');
        		if (!oInputText) {
        			return;
        		}
        		
        		// Recuperation de la chaine de caracteres correspondant au lien
        		var sInputUrl = oInputText.value;
        		return sInputUrl;
        	}
        	
        	// *** Definit l'url a telecharger dans le lien ***
        	function fnSetUrl(sUrl) {
        		// Test des methodes
        		if (!document.getElementById) {
        			return;
        		}
        		
        		// Recuperation du lien a definir
        		var oLink = document.getElementById('outputLink');
        		if (!oLink) {
        			return;
        		}
        		
        		// Attribution de la valeur du lien
        		oLink.setAttribute('href', sUrl);
        	}
        	
        	
        	// *** Copie l'url a telecharger du cadre de texte au lien ***
        	function fnCopyUrl() {
        		// Recuperation du lien a copier
        		var sUrl = fnExtractUrl();
        		
        		// Attribution du lien a copier
        		fnSetUrl(sUrl);
        	}
        	
        	//--><!]]>
        </script>
        
        A noter que les codes de protection sont inutiles si on importe le script via un fichier .js....
        • [^] # Re: ça pue c'est pas xhtml1 strict

          Posté par (page perso) . Évalué à 3.

          Il faut quand même noter que du "bon" javascript n'est présent que dans un fichier externe, comme avec du css.
          • [^] # Re: ça pue c'est pas xhtml1 strict

            Posté par . Évalué à 1.

            Oups oui excuse moi, par "pas besoin de code de protection pour du javascript importé", j'entendais effectivement "rien ne sert de casser la tête avec le code de protection puisqu'il sera normalement importé".

            CQFD...
    • [^] # Re: ça pue c'est pas xhtml1 strict

      Posté par (page perso) . Évalué à 4.

      n'y aurait-il que moi pour touver ce code pas très lisible ?
      • [^] # Re: ça pue c'est pas xhtml1 strict

        Posté par (page perso) . Évalué à 1.

        non tu n'es pas le seul :-)

        Je comprends pas pourquoi peu quelquesoit le langage apprécie la beauté du
        for(inits; test ; traitement avec iteration );
      • [^] # Re: ça pue c'est pas xhtml1 strict

        Posté par . Évalué à 2.

        non, mais i ldevait etre ironique lorsqu'il parlait de code bien ecrits :)
        Il y a deja le for que je n'ai jamais trouvé d'une lisibilité formidable (surtout là où la variable testée n'est pas la meme ques la variable incrementé [enfin, je code pas en JS mais je suppose que le somme+=i à le meme sens qu'en C]
        Et la post-ecrementation dan la foulé de l'appel d'une fonction... les seuls fois où j'ai ecris du code comme sa, c'etais pour embeter le profs qui venais voir ce qu'on faisait et que sa embetait de mal reussir à relire ^ ^
        • [^] # Re: ça pue c'est pas xhtml1 strict

          Posté par (page perso) . Évalué à 3.

          à titre perso
          je trouve le
          init
          while (cond ){
          traitement
          }
          toujours plus propre que le faussement concis

          for (init; cond; incrementation) {
          traitement
          }

          et j'utilise deux trucs de sagoin pour montrer que le for est moche :
          - la possibilité en C, et js, (probablement en java)
          de multiplier les opérations à un endroit si on sépare par des virgules
          dans
          for (i=0, somme=0; ...
          les deux init sont fait en même temps

          - et la possibilité d'ajouter le traitement dans la partie incrémentation du for.

          Le for c'est moche, mangez du while :) que ce soit en js, et perl, en C, en C++ ou en java.

          Au final, peut être que la programmation n'est pas foncièrement une question de langage :-)
          • [^] # Re: ça pue c'est pas xhtml1 strict

            Posté par (page perso) . Évalué à 1.

            for (i=0, somme=0; ...

            for (i=somme=0; ...

            * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

            • [^] # Re: ça pue c'est pas xhtml1 strict

              Posté par (page perso) . Évalué à 0.

              On ne connaît pas l'ordre d'évaluation des opérateurs d'affectations.
              En ansi C ça n'était pas précisé dans la norme. Donc un même code pouvait marcher différemment selon les compilos. =>
              fait on i = somme puis i=0 ou i=0; somme=0
              donc à déconseiller :)

              Ok pour faire du goret, pas pour faire un générateur d'erreur aléatoire :)
              • [^] # Re: ça pue c'est pas xhtml1 strict

                Posté par (page perso) . Évalué à 1.

                fait on i = somme puis i=0 ou i=0; somme=0

                Bah, je ne pense pas qu'il y ait un grosse différence sur le coup. Et
                foo=bar=42; est parfaitement standard, même qu'on doit le trouver dans le K&R...

                * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

          • [^] # Re: ça pue c'est pas xhtml1 strict

            Posté par . Évalué à 2.

            Perso je préfère le for, pour la portée de la variable d'indice.
            En utilisant que la forme la plus simple.
            évidemment le must, c'est une collection avec un itérateur.

            Le problème avec le while, c'est qu'il y a toujours un zozo pour t'insérer un truc entre l'init, et la boucle. Et après le premier, un autre ce dit pourquoi pas moi...
            En plus maintenant, en Java au moins, la boucle for est beaucoup plus jolie que le while.

            J'aime bien que mes variable soient déclarée au plus près de l'endroit ou elle sont utilisée.
          • [^] # Re: while / for

            Posté par . Évalué à 2.

            Je ne me l'explique pas, mais à traitements égaux, les itérations basées sur while sont plus un poil plus performantes que celles basées sur for. Je me suis rendu compte de cela en optimisant des fonctions de traitement sur les chaînes en javascript.
    • [^] # J'pinaille

      Posté par . Évalué à 3.

      La syntaxe standard de la balise <script> pour entourer du javascript est, me semble-t-il :

      <script type="text/javascript">
      • [^] # Re: J'pinaille

        Posté par (page perso) . Évalué à -1.

        Non, c'est <script type="application/javascript"></script>
        • [^] # Re: J'pinaille

          Posté par . Évalué à 2.

          Hmm, je me suis basé sur la recommandation W3C pour dire ça :

          http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.1
          • [^] # Re: J'pinaille

            Posté par (page perso) . Évalué à 1.

            C'est un troll que les moinseurs fous n'ont pas compris.

            En ce qui concerne le document normalisant du W3C, on notera que text/javascript est indiqué à titre informatif, et non normalisant, puisque cette normalisation sors du champs d'action de la présente norme.

            Un lien (http://annevankesteren.nl/2005/02/javascript-mime-type) qui résume bien la bêtise du Web. Une vraie poubelle ce Web, j'en ai la larme à l'½il.

            En fait, le fameux attribut peut contenir n'importe quoi. Il suffit que le navigateur sache le prendre en charge. À quand un navigateur supportant le Tcl (comme mis en avant dans la norme), le Perl, le Lisp, le PHP ( :)) ), le Bash !
            • [^] # Re: J'pinaille

              Posté par . Évalué à 1.

              Pas évident à voir quand même ton troll :-).

              L'attribut type renvoi à un type MIME. J'aurais du le préciser. Et comme il s'agit d'une syntaxe HTML et pas Javascript, peut-on dire que ça sort de la présente norme ?
              • [^] # Re: J'pinaille

                Posté par . Évalué à 2.

                1) J'ai répondu à coté de la plaque :)
                2) Ton lien est cassé :-/
  • # XForms

    Posté par . Évalué à 3.

    [x] C'est illisible et chiant à maintenir dès qu'on fait un truc sympa...

    Mais heureusement il y a xforms (éventuellement avec un transcodeur pour générer du javascript pour les navigateurs qui ne le gèrent pas...) ;)

    -> http://www.w3.org/MarkUp/Forms/
    -> http://www.mozilla.org/projects/xforms/
    • [^] # Re: XForms

      Posté par (page perso) . Évalué à 2.

      Tiens à ce propos, si quelqu'un connait un truc qui permet de générer un formulaire HTML avec le JS qui va bien, à partir d'un XForms (pour les navigateurs ne prenant pas en charge xforms), ça serait bien (en php et indépendant d'un quelconque framework).
  • # Pour des applications

    Posté par (page perso) . Évalué à 1.

    Pour des applications métiers multi-platforme, c'est obligatoire.

    Meme si personnelement développer du html/javascript et tout se qui va avec me gonfle terriblement !
  • # Bench pour pc ?

    Posté par (page perso) . Évalué à 4.

    JS c'est pour faire des bench sur pc ? :D
    Quand on voit la lourdeur de FF (firefox) dont l'interface graphique est en JS, on peut se demander légitimement l'utilité d'un tel langage quand on voit (d'une manière générale) la surconsommation abusive de mémoire. Avant avec un 166MHz et 256Mo de RAM il était possible d'aller sur le net et de faire pleins de chose. Maintenant avec des 4GHz On a quoi de mieux ?
    Des langages qui mangent une mémoire pas possible ?
    Des programmes concu avec les pieds ?

    Dans 10 ans pourrais-je toujours aller sur internet sans être obligé d'avoir 5Go de RAM, 20GHz en CPU et 30Go d'espace disque minimum ?
    • [^] # Re: Bench pour pc ?

      Posté par . Évalué à 4.

      Oui en effet, on ne navigue plus sur internet avec un pc qui à dix ans comme c'était le cas il y a dix ans.
      La technologie évolue, l'ergonomie en profite et évolue avec.
      En effet on pourrait faire des sites n'affichant que du texte qui tournerait sur un 486. Mais quel intérêt ?
      Aujourd'hui, on a des ordinateurs qui n'ont rien à voir avec ceux que l'on avait il y a dix ans, autant en profiter.

      Alors est-ce que dans dix ans, ils faudra 5Go de RAM pour naviguer ? c'est possible, mais ce jour là, les ordinateurs premiers prix seront livrés avec 1To de RAM et ça n'aura aucune importance.
      • [^] # Re: Bench pour pc ?

        Posté par (page perso) . Évalué à 3.

        Alors est-ce que dans dix ans, ils faudra 5Go de RAM pour naviguer ? c'est possible, mais ce jour là, les ordinateurs premiers prix seront livrés avec 1To de RAM et ça n'aura aucune importance.


        Pas sùr.
        1°) La loi de croissance des composants semble toucher ses limites
        2°) La disponibilité en éléments chimiques nécessaires pour doper le silicium et autre procédés de fabrication des puces éléctronique peut diminuer pour certains d'entre eux.
        Le nombre d'utilisateurs d'ordinateurs et de composanst électroniques augmente, pas la planète.
        3°) Il est dommage de jeter du matériel polluant qui pourrait en core servir. Changer d'ordi tout les 18 mois, ce n'est pas ce que j'apelle du développement durable.
        http://www.lesdeveloppementsdurables.com/
    • [^] # Re: Bench pour pc ?

      Posté par (page perso) . Évalué à 3.

      Quand on voit la lourdeur de FF (firefox) dont l'interface graphique est en JS,


      Faux. L'interface graphique est en XUL, et scripté en JS.

      M'enfin la (relative) lourdeur de FF n'est pas du qu'à JS, fort heureusement... spidermonkey, l'interpreteur JS, est l'un des plus performant qui existe.

      Ce qui est lent dans Gecko, ce n'est pas JS, mais les manipulations DOM (il y a un mapping assez lourd entre les objets DOM C++ et leur representation javascript...).
      • [^] # Re: Bench pour pc ?

        Posté par . Évalué à 2.

        Je trouve qu'un programme qui tient à faire du multiplateformisme du GUI ça suce un peu. KMeleon se lance instantanément sous windows et n'utilise gecko que pour afficher les pages web.
        http://kmeleon.sourceforge.net/
        J'aimerais bien un programme aussi bon sous linux, Epiphany n'est pas vraiment un démon de vitesse.. (la faute à GTK?)
  • # Ca raaaame (enfin ça dépend).

    Posté par (page perso) . Évalué à 0.

    Enfin ça m'arrive encore parfois de tomber sur du site qui veut faire des choses super belles et super impressionnantes, et qui super rament !

    Mais sinon, j'dois avouer que c'est parfois super pratique, et incontournable pour résoudre certains problèmes de dynamisme quand on fait du web!

    Bref, c'est une infame bouse à coder, et à débugguer aussi, mais bon, y'a rien d'autre pour faire la même chose malheureusement, alors tant qu'on le fait fonctionner pourquoi pas...

    Ceci dit faudrait que j'aille faire un tour du côté des framework googles et autre frameworks plus libre, y'a l'air d'y avoir des choses sympa à exploiter :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.