javascript saibien

• [^]Re: javascript saibien

  Posté par François BOTTIN () le 04/01/2007 à 14:14. (lien). É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(...)

  [ Répondre ]

  • [^]Re: javascript saibien

    Posté par seginus () le 05/01/2007 à 07:16. (lien). É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.

    [ Répondre ]

    • [^]Re: javascript saibien

      Posté par Gof (Jabber id, page perso, ) le 05/01/2007 à 17:11. (lien). É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)

      [ Répondre ]

    • [^]Re: javascript saibien

      Posté par François BOTTIN () le 09/01/2007 à 10:47. (lien). É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)

      [ Répondre ]

      • [^]Re: javascript saibien

        Posté par erik_lallemand (page perso, ) le 09/01/2007 à 19:24. (lien). É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.

        [ Répondre ]

        • [^]Re: javascript saibien

          Posté par François BOTTIN () le 10/01/2007 à 08:09. (lien). É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.

          [ Répondre ]

• [^]Re: javascript saibien

  Posté par BlindMan () le 04/01/2007 à 19:35. (lien). É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.

  [ Répondre ]

  • [^]Re: javascript saibien

    Posté par Cedric Malherbe (page perso, ) le 05/01/2007 à 01:17. (lien). É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.

    [ Répondre ]

  • [^]Re: javascript saibien

    Posté par Moogle () le 05/01/2007 à 08:24. (lien). É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.

    [ Répondre ]

  • [^]Re: javascript saibien

    Posté par McAdam () le 05/01/2007 à 21:31. (lien). É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(...)

    [ Répondre ]

• [^]Re: javascript saibien

  Posté par Matthieu Lemerre () le 06/01/2007 à 11:26. (lien). É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?

  [ Répondre ]

ça pue c'est pas xhtml1 strict

<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 BlindMan () le 04/01/2007 à 19:55. (lien). É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.

  [ Répondre ]

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

    Posté par Pierre Jarillon (page perso, ) le 05/01/2007 à 11:37. (lien). Évalué à 4.

    Pour le codage des adresses mail on peut utiliser http://aspirine.org/emailcode.php

    [ Répondre ]

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

      Posté par François BOTTIN () le 05/01/2007 à 13:38. (lien). É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 ;-)

      [ Répondre ]

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

        Posté par Thomas Douillard () le 05/01/2007 à 23:08. (lien). É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.

        [ Répondre ]

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

        Posté par Mildred (Jabber id, page perso, ) le 07/01/2007 à 23:20. (lien). É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;
        ...

        --
        La Roue du Temps

        [ Répondre ]

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

  Posté par Jonathan () le 05/01/2007 à 11:06. (lien). É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.

  [ Répondre ]

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

    Posté par Jul (page perso, ) le 05/01/2007 à 12:48. (lien). É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...

    [ Répondre ]

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

    Posté par McAdam () le 13/01/2007 à 13:20. (lien). É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....

    [ Répondre ]

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

      Posté par Jean-Philippe (page perso, ) le 13/01/2007 à 16:06. (lien). É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.

      [ Répondre ]

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

        Posté par McAdam () le 14/01/2007 à 00:03. (lien). É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...

        [ Répondre ]

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

  Posté par Toufou (page perso, ) le 05/01/2007 à 14:22. (lien). Évalué à 4.

  n'y aurait-il que moi pour touver ce code pas très lisible ?

  [ Répondre ]

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

    Posté par Jul (page perso, ) le 05/01/2007 à 15:33. (lien). É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 );

    [ Répondre ]

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

    Posté par Guillaume Rossignol () le 05/01/2007 à 19:50. (lien). É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 ^ ^

    [ Répondre ]

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

      Posté par Jul (page perso, ) le 06/01/2007 à 01:56. (lien). É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 :-)

      [ Répondre ]

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

        Posté par Thierry Boudet (page perso, ) le 07/01/2007 à 00:14. (lien). Évalué à 1.

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

        --
        ( images )

        [ Répondre ]

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

          Posté par Jul (page perso, ) le 08/01/2007 à 12:45. (lien). É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 :)

          [ Répondre ]

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

            Posté par Thierry Boudet (page perso, ) le 12/01/2007 à 15:56. (lien). É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...

            --
            ( images )

            [ Répondre ]

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

        Posté par Papa Furax (page perso, ) le 09/01/2007 à 09:27. (lien). É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.

        [ Répondre ]

      • [^]Re: while / for

        Posté par locke () le 13/01/2007 à 09:58. (lien). É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.

        [ Répondre ]

• [^]J'pinaille

  Posté par Mounir (page perso, ) le 11/01/2007 à 17:04. (lien). Évalué à 3.

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

  --
  Ce n'est pas sur linux...

  [ Répondre ]

  • [+] [^]Re: J'pinaille

    Posté par LupusMic (page perso, ) le 12/01/2007 à 09:46. (lien). Évalué à -1.

    Non, c'est <script type="application/javascript"></script>

    [ Répondre ]

    • [^]Re: J'pinaille

      Posté par Mounir (page perso, ) le 12/01/2007 à 11:58. (lien). É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

      --
      Ce n'est pas sur linux...

      [ Répondre ]

      • [^]Re: J'pinaille

        Posté par LupusMic (page perso, ) le 15/01/2007 à 10:28. (lien). É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 !

        [ Répondre ]

        • [^]Re: J'pinaille

          Posté par Mounir (page perso, ) le 15/01/2007 à 11:03. (lien). É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 ?

          --
          Ce n'est pas sur linux...

          [ Répondre ]

          • [^]Re: J'pinaille

            Posté par Mounir (page perso, ) le 16/01/2007 à 15:52. (lien). Évalué à 2.

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

            --
            Ce n'est pas sur linux...

            [ Répondre ]

XForms

• [^]Re: XForms

  Posté par Laurent J (page perso, ) le 09/01/2007 à 11:53. (lien). É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).

  [ Répondre ]

Pour des applications

Bench pour pc ?

• [^]Re: Bench pour pc ?

  Posté par seginus () le 07/01/2007 à 17:28. (lien). É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.

  [ Répondre ]

  • [^]Re: Bench pour pc ?

    Posté par CyrrusSmith (page perso, ) le 08/01/2007 à 22:40. (lien). É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/

    --
    Il existe pour chaque problème complexe une solution
    simple, directe et fausse.
    H.L. MENCKEN

    [ Répondre ]

• [^]Re: Bench pour pc ?

  Posté par Laurent J (page perso, ) le 09/01/2007 à 11:57. (lien). É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...).

  [ Répondre ]

  • [^]Re: Bench pour pc ?

    Posté par taratatatata () le 18/01/2007 à 14:11. (lien). É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?)

    [ Répondre ]

Ca raaaame (enfin ça dépend).