Librairie de composants Javascript free

February 9th, 2005 par Freddy Mallet

Vous trouverez sur le site de Matt Kruse un nombre intéressant de composants javascript free. Je suis tombé dessus en recherchant des composants de sélection d’une date dans un calendrier et de gestion d’options à partir de deux select box. Mais le site ne s’arrête pas à ces deux standards, allez découvrir de vous même ce beau pâturage.

14 Responses to “Librairie de composants Javascript free”

  1. Franck Says:

    Hou, le javascript c’est caca !
    Enfin c’est ce que j’avais tendance à dire.
    Mais en voyant Google Mail, Google Suggestion, Google Map, on voit vraiment l’intérêt du javascript/DHTML quand c’est utilisé à bon escient.

  2. Freddy Mallet Says:

    comme mon maître à penser, je me disais aussi javascript c’est caca ! Seulement il est vrai que lorsqu’on ouvre un peu les yeux on voit toutes les utilisations professionnelles du javascript par google et encore mieux le langage de scripting au coeur de XUL est bien entendu javascript. Donc la question est pourquoi dans l’inconscient collectif javascript est-il caca ? Je me suis posé la question et ai quelques brides de réponse:

    - tout d’abord c’est un peu comme java, quand on ne connait pas les api c’est le chemin de croix. Donc il faut faire l’effort d’apprendre les api.
    - à ma connaissance pas d’ide open-source très puissant (j’ai commencé à utiliser WTP 1.0 M2 avec eclipse et ce dernier inclus un éditeur javascript avec complétion tout à fait correct )
    - difficilement testable détaché de la page html qui doit l’embarquer car souvent lié aux objets contenus dans cette page. Quand en plus la page est générée dynamiquement ça devient difficile. Et donc pourquoi ne pas faire des tests unitaires sur librairies javascript avec des mockhtml et un framework comme httpunit ?

    je voulais ajouter difficile de debuguer mais avec l’extension firefox JavaScript Debugger ce n’est plus très vrai.

    conclusion, je crois qu’il est temps de se mettre à du javascript professionnel.

  3. Yann Says:

    Je ne suis pas sur que la définition du “caca” du Javascript ait été définie correctement. Je ne pense pas que l’obstacle majeur du Javascript soit le manque d’outils (écriture, debuggeur…) mais plutot le fait que l’on soit toujours dépendant du navigateur du poste client.

    On peut écrire du Javascript “state of the art” qui ne marchera pas car notre utilisateur final n’aura pas un build Firefox de la veille mais un vieil IE installé par défaut sur sa machine achetée il y a 5 ans. Et c’est valable evidemment dans les deux sens… Ne me dite pas, si vous êtes un adepte de Firefox, que vous n’avez jamais du ouvrir un IE parce que le site que vous vouliez consulter était inutilisable autrement.

    En conclusion, tant que tout le monde n’aura pas le même interpréteur Javascript quel que soit son navigateur et sa version, le Javascript restera “caca” car il ne sera pas universel et sera surtout une plaie pour celui qui l’écrit et qui voudra s’assurer que son code est compatible sur les ‘n’ versions de ‘m’ navigateurs sur ‘p’ OS différents.

    Ceci dit, je suis d’accord que la révolution est là !!!

  4. Eric Says:

    A mon sens JavaScript (normalisé par ECMA pour donner l’ecmascript) n’est pas un mauvais langage (d’ailleurs il est complet au sens de Turing). Sa définition est bonne, il y a quelques “tournures” de programmation que je n’aime pas vraiment (je ne les ai plus en tête mais essentiellement c’est sur la gestion des null).

    L’utilisation du DOM est aussi pratique et intéressante (malheureusement une page HTML n’est pas un vrai DOM et l’oubli d’un tag est prévu par les navigateurs ne montrant aucune erreur…).

    Cependant, a l’instar de Java vu à travers une page JSP, le javascript dans dans une page HTML peut devenir un véritable cauchemar : des appels entre include JSP, ou dans des includes HTML, des copier/coller du à labsence d’objet et la notion d’héritage, des fonctionnalités absentes dans différents navigateurs… Bien sûr tout ces problèmes peuvent être au moins minimiser voir régler en s’efforçant d’avoir des règles de codage et des règles de gestion, mais n’est-il pas rageant de chercher pendant quelques heures un problème javascript qui se produit que sous IE 5.5 avec Office 2002 SP1 version française (et sous aucunes autre combinaison) - parce que bien sûr les moteurs de scripting d’IE (VBScript et javascript) sont utiliser dans les outils Microsoft et sont mis à jour par différents programme ???
    Sans doute, tout cela est nettement mieux avec XUL.

    En conclusion, effectivement on peut faire des choses excessivement bien avec JavaScript/DHTML, mais on peut en faire tout autant en Cobol (une paye par exemple :-) ), en Visual Basic, en Fortran… Ce fait ne peut pas être l’unique critère de jugement du JavaScript. Maintenant les outils de dévelopemment s’intéresse aux langages de scripting (javascript, bsh, groovy, etc.) et les debugger sont là (le débugger de Microsoft marcher pas mal avec le Javascript) surtout avec Firefox. Mais en utilisant du javascript du côté client, on commence à faire un nouveau pas vers le client serveur. A mon sens, il ne peut être justifié qu’à certains égards :
    1. look et simplicité d’utilisation (ah le marketing…),
    2. optimisation de la répartition de la charge serveur/client et optimisation du réseau,
    3. optimisation de la vitesse d’exécution.
    Trop souvent le javascript est utilisé à mauvais escient (validation d’un formulaire, par exemple)… Mais j’avoue humblement que les équipes de développmenet de google savent utiliser correctement et à des fins excellents, les nouvelles technos (même si le javascript existe depuis plus de 6 ans !).

    NB. Cela étant dit avec Firefox je n’ai jamais eu de problème sur un site me réclamant de réutiliser Internet Explorer (bon il y a bien un wine avec une installation d’IE sur mon poste au cas où mais en 3 ans j’ai du l’utiliser une fois pour vérifier que l’installation s’était bien passée). Yann tu as un site qui ne fonctionne qu’avec IE ?

  5. Yann Says:

    L’exemple qui me vient tout de suite en tête est le site que nous utilisons au boulot pour visualiser les rapports Webtrends générés par notre hébergeur. (Ceci dit il faudrait que je réessaye mais je ne me fait pas trop d’illusions…)

    Un autre exemple de site, cette fois accéssible par tous : http://www.voyages-sncf.com
    Essayez de cliquer sur le calendrier dans le formulaire par défaut à coté des dates de départ et de retour…

    Ok, dans cet exemple, la limitation ne rend pas pour autant le site inutilisable. Sur d’autres par contre, c’est toute la navigation qui est en Javascript (menus déroulants) ce qui rend le site inutilisable sous Firefox.

    D’autres exemples de sites ne me reviennent pas en tête mais c’est clair que je ne suis pas aussi chanceux qu’Eric : j’ouvre mon IE, disons, une fois par mois…

  6. Yann Says:

    Gros coup de flip sur le site de la SNCF ! Je me voyais déjà me faire chambrer jusqu’à la fin de mes jours : ce n’est pas du au bloquage des popups !!!

  7. Freddy Mallet Says:

    J’allais poser la question de savoir quel organisme était en charge de la normalisation du javascript et eric donne la réponse avec l’ECMA, c’est pas beau ça ? l’évolution du nom javascript en ecmascript c’est quelque chose de sûr ? Sur le fait d’être obligé de basculer sur ie quelque fois je confirme et en même temps je crois que progressivement c’est de moins en moins vrai. Même dans les banques suisses ils tiennent désormais très fortement à la compatibilité firefox…

  8. Eric Says:

    C’est ben vrai ça !
    C’est assez étonnant car il me semblait que cela ouvrait effectivement une popup pour choisir la date, je dois avoir les mêmes problème d’Alzheimer que Freddy… ;-)

    En ce qui concerne le nom l’ECMAScript, c’est en fait une normalisation de JavaScript (Netscape) et JScript (Microsoft) qui date de 1999. Freddy ton absence de confiance en mes propos me blesse, mais bon, comme je dois te le prouver (pfffuttt), je t’invite à télécharge le fichier PDF Normalisation ECMA et de regarder la page 5.

  9. Freddy Mallet Says:

    Rien à redire, t’as oublié cqfd à la fin de ton commentaire. Pour info, j’ai commencé à utiliser httpunit qui se base sur rhino pour l’interprétation du javascript… euh du ecmascript.

  10. Eric Says:

    Cool, tu as choisi httpunit à la place de htmlunit pour des raisons précises (les deux font des tests javascript de ce que j’avais lu) ?
    Euh il y aurait pas un forum/IRC sur WordPress, Franck ? :-)

  11. Freddy Mallet Says:

    Pour la simple et bonne raison que je ne connaissais pas htmlunit.

  12. Eric Says:

    C’est, ma foi, une raison excellente ! ;-)

  13. Franck Says:

    Bon c’est fini ces commentaires, je vais finir par être jaloux !

  14. Eric Says:

    Oh faut pas être jaloux, Franck…
    Et puis c’est juste pour ne pas avoir 13 commentaires: ça porte malheur !

Leave a Reply

You must be logged in to post a comment.