Mais le javascript, c'est pas facile. C'est un langage de programmation orienté objet qui peut paraître complexe pour certaines opérations comme le drag'n'drop ou les requêtes Ajax. Sans parler des bugs et différences entre chaque navigateurs, on se retrouve facilement avec des scripts de plusieurs dizaines de lignes bugguées pour faire une simple action.

C'est pour ça que des frameworks ont été créés ! Parmi les plus célèbres : Prototype, Script.aculo.us, Open Rico, Yahoo User Interface ou le très fashion jQuery… ces morceaux de code a intégrer dans votre application web propose des classes et des méthodes pour faciliter le développement javascript. Effectuer une animation ne demande plus qu'une ligne de code.

Et donc, ces frameworks sont défendus corps et âmes par leurs communautés respectives. Car c'est bien connu, c'est moi qui ai la plus grosse et la plus productive. Alors certes, les arguments tiennent en général la route : documentation accessible, extensibilité, cross platform… tandis que d'autres sont franchement ridicules : "avec machin, tu fais la même chose que truc mais avec une seule ligne de code au lieu de trois !!", "Ma lib est mieux ! Elle ne pèse que 39Ko alors que la tienne en fait 47 !! Et encore t'es pas obligé de charger tout les fichiers ! Tu peux tomber à 31Ko !!!".

Mais au final, elles sont toute identiques à quelques détails prêt. Ces détails sont plutôt liés à la cible de ces API. Nous avons deux types d'utilisateurs : les webdesigner orientés graphisme, et les web développeurs orientés développement.
La première catégorie n'aime pas le code. Si il peut faire un truc fashion et impressionnant juste en insérant une ligne de code, il est content ! S'il peut insérer une fonction copiée/collée sur un forum d'entraide à l'utilisation du javascript, il est content !! Il utilisera donc des librairies très facile d'utilisation où les résultats sont visible de suite comme Script.aculo.us ou jQuery. De toute façon, s'il ne peut pas faire plus que ce qu'elle propose, il s'en fout car il n'a pas envie de se casser la tête à écrire les algos nécessaire.
La seconde catégorie est à l'antipode. Il aime coder. Il aime écrire ses propres classes. Il préféreras mille fois passer deux heures à écrire soit même sa fonction d'animation que 20 minutes à chercher sur Exalead. Et il déteste aussi voir arriver les limites d'un langages ou d'une bibliothèque. C'est pourquoi il préférera des bibliothèques telles que Yahoo UI où certes, il ne fera pas de drag'n'drop après 5 minutes d'utilisation mais où il sera libre de personnaliser à mort sa propre classe de drag sans pour autant s'embêter avec les problèmes liés aux différence entre les navigateurs.

Tout ça pour dire qu'il n'y a pas de bibliothèque JS plus mieux que les autres. Que chacune à ses avantages et ses inconvénients. Et surtout, que, sûrement en tant que développeur, je conseillerais toujours à tout le monde d'essayer de faire les choses par soi même avant de se jeter sur la facilité en copiant/collant du code sans savoir ce qu'il fait vraiment. On y gagne des connaissances, de l'autonomie et de l'auto-satisfaction. À long terme, c'est quand même plus intéressant que quelques centaines d'€uros soutirés à ses clients.

…

$('#faq').find('dd').hide().end().find('dt').click(function() {
        var answer = $(this).next();
        if (answer.is(':visible')) {
            answer.slideUp();
        } else {
            answer.slideDown();
        }
    });
});