Google a toujours mis en avant la puissance de JavaScript pour proposer ses nouveaux services. On a pu le constater très rapidement au travers des applications web telles que GMail ou GMaps qui ont initialement jeté un pavé dans la mare des interactions offertes aux internautes et des possibilité offertes par JavaScript. Puis Google a lancé son propre navigateur, Chrome, tout en portant un soin particulier à son moteur d'interprétation open-source ECMAScript nommé V8 qui se veut un des plus performants .
Avec Closure Tools, c'est une nouvelle fois JavaScript qui est à l'honneur grâce à différents outils, notamment Closure Compiler sur lequel nous allons nous attarder. Notez que ceci n'a rien à voir avec un magazine people.
Closure Compiler
Initialement, Closure Compiler est un outil en ligne de commande programmé en Java (qu'il vous faudra posséder pour exploiter l'archive compiler.jar). Rappel : Java n'est pas JavaScript. Pour faire simple le premier est un langage de programmation compilé à l'instar du C++ pour concevoir des applications classiques (telles qu'OpenOffice) créé par Sun dans les années 1990; tandis que le second est un langage interprété par les navigateurs web pour enrichir l'interactivité des pages HTML créé en 1995 par Netscape.
Quel est le but de Closure Compiler ? L'efficacité : il réduit la taille des fichiers JavaScript, donc le temps d'interprétation et de chargement. Il vérifie le code, affichant des erreurs détaillées pour des instructions qui pourraient être mal rédigées ou mal interprétées, pour produire un script d'autant plus propre et conforme. Remarque : il a été ajouté à l'extension Page Speed pour évaluer le gain qu'il est possible de réaliser en appliquant ce service sur les scripts.
Une extension pour Firefox muni de Firebug, nommée Closure Inspector, ajoute différentes fonctionnalités à l'onglet Script pour faciliter la lecture et le débogage des scripts compressés avec Closure.
Un service en ligne est également disponible. Closure Compiler Service demeure le plus pratique pour optimiser rapidement les scripts. Soit par copier-coller dans le formulaire prévu à cet effet, soit en indiquant directement l'url d'un fichier, puis en cliquant sur Compile. Il suffit de récupérer le code source alors généré pour le remplacer dans votre application (veillez cependant à toujours conserver l'original, car il vous sera très difficile de revenir en arrière vers un code lisible).
Notez qu'il y a 3 modes d'optimisation :
- Whitespace only, qui retire les commentaires et les espaces inutiles.
- Simple, qui est le mode par défaut d'optimisation, n'interfère pas avec les autres scripts et librairies qui pourraient être présents sur la page.
- Advanced, qui prend des libertés avec les noms de fonctions et de variables pour les compresser elles aussi. Attention, ceci modifiera en profondeur votre code qui risque de ne plus être correctement interprété, notamment s'il fait appel à d'autres frameworks (par exemple jQuery).
La documentation de Closure Compiler est bien fournie à ce sujet. Il est également possible d'exploiter ce service web via une API.
Closure Library
Closure Library est tout simplement une nouvelle librairie JavaScript, à l'instar de jQuery, MooTools, Prototype, Dojo ou Yahoo! UI pour étendre les fonctionnalités du navigateur et écrire des scripts plus rapidement avec une syntaxe et une API spécifique. On retrouve l'essentiel des outils qui peuvent permettre de déployer une application web : manipulation du DOM, widgets UI, événements, animation, json, édition wysiwyg etc, quel que soit le serveur et le navigateur.
Attention : cette librairie est encore jeune, et beaucoup de développeurs pointent déjà du doigt des défauts de performance. N'abandonnez pas vos librairies actuelles, performantes et éprouvées, telles que jQuery.
Closure Templates
L'objectif de Closure Templates est de simplifier la génération de code HTML avec des templates, c'est à dire séparer la présentation du contenu. Vous pouvez ainsi exploiter de petits composants pour générer les pages dynamiquement. La syntaxe est relativement abordable, on y retrouve des opérateurs, des boucles et des structures de contrôle. On peut déployer cette solution autant du côté client avec un JavaScript "précompilé", que du côté serveur à l'aide de Java. Closure Templates est déjà éprouvé par GMail et Google Docs et peut être utilisé en conjonction avec d'autres librairies sans créer de conflit.
Commentaires
Quelle réactivité :-)
La syntaxe de cette nouvelle librairie me fait un peu peur, on est loin de la simplicité de jQuery. Mais le compilateur et l'extension Firefox c'est du lourd !
Pourquoi l'option Advanced de closure compiler empèche-t-elle d'utiliser des frameworks externes, au juste ?
Car elle renomme les symboles (fonctions, variables). Donc un $(document).ready() en jQuery se retrouve transformé en $(document).f(), ce qui ne veut plus rien dire.
Le compilateur est vraiment interessant, je pense que ça va vite devenir mon nouveau copain.
Pour le framework, je vois mal comment il est possible de doubler jQuery.
«le premier est un langage de programmation compilé à l'instar du C++» → Java n'est pas compilé en langage machine comme le C++, il est transformé en byte-code indépendant de l'architecture qui est interprété par une machine virtuelle Java.
En ce qui concerne Closure Compiler ce que fait cet outil ce n'est pas de la compilation mais de «l'optimisation», le nom qu'a choisi Google est donc particulièrement inadéquat.
+1, Skoua : jQuery me paraît également très difficile à double ;)
Par contre, pour l'optimisation et la "compression" du Javascript, j'ai adoré le "Closure Compiler Service". Donc "Copaiiiiiin ! :D"
Ceci dit, il est vrai que "Closure Compiler" est un nom assez inadéquat car, Javascript n'est pas un langage compilé mais interprêté (par le navigateur, dans notre cas). D'autant plus mal choisi que ce service ne fait que compacter/optimiser (et/ou obfusquer) le Javascript.
@Changaco : J'avais commencé ma phrase par "Pour faire simple" ;) Entrer dans les considérations du byte-code était hors contexte.
(ma question n'est pas ironique)
Quoi de neuf (concernant l'optimiseur/compiler) si on compare avec le boulot de l'excellent Dean Edwards?
http://dean.edwards.name/packer/
Si j'ai bien pigé ce service tourne sur son serveur, chez lui. (dans le bouquin "Bien développer pour le web 2.0", l'auteur C. Porteneuve lui rend hommage)
J'aime beaucoup Google, mais honneur aux précurseurs, aux petits, aux passionnés...
Bien-sûr c'est un addon FF, encore un! J'en ai tellement que FF me sort par les yeux tellement il est lent à démarrer. Vivement Chrome pour mac + page speed + un validateur à jour et basta!
Si tu rajoutes N plugins à Firefox, il sera forcément ralenti. En connaissance de cause, il faut se limiter aux plugins qui nous sont vraiment indispensables ;-)
Ouais je sais bien! C'est quand même pas super au point leur système, même avec un "minimum" de addon, devrait y avoir la possibilité de faire plusieurs config. Sans parler de comment FF te sature la RAM de l'ordi (mac, pc j'en sais rien) au bout d'un certain temps... Enfin, c'est pas le sujet ici...
Ton concept de "configuration" pour FF est intéressante :D
En gros, ça serait la possibilité d'avoir N plugins sur Firefox, mais dont certains uniquement seraient activés en fonction de ce qu'on a défini, c'est ça ? S'ils le faisaient, ça serait super.
Et pourquoi ne pas utiliser les profils de Firefox : un par activité, et donc à chacun ses extensions utiles... (un profil pour surfer, un profil pour développer, un pour naviguer sans laisser de traces, etc...)
Avec l'extension profileswitcher, le passage d'un profil à l'autre est en plus très simple !
@dj DMSR : Ça s'appelle les profils. L'inconvénient est que les profils sont monolithiques: un profil regroupe les extensions installées et leur configuration, un jeu de configuration de Firefox lui-même, les bookmarks et mots de passe sauvegardés, etc. Dans certains cas ça peut être gênant.
Beaucoup de développeurs web utilisent un Firefox bardé d'extensions pour le développement, et un autre navigateur pour le surf. Ils concluent à tort que Firefox n'est pas bon pour le surf (alors que ça vient juste du fait qu'ils l'ont bardé d'extensions), mais c'est un autre sujet. Quoi qu'il en soit, si tu tiens à surfer sous Firefox, tu peux:
- soit te limiter drastiquement dans les extensions installées (je reste en-dessous de 10 quoi qu'il arrive);
- soit utiliser deux profils séparés, que tu peux lancer en même temps si besoin (en mode no-remote).
Je lis « il réduit la taille des fichiers JavaScript, donc le temps d'interprétation », ce qui n'est pas du tout vrai avec les YUI Compressor et Dean Edward's Packer, si je ne m'abuse, puisque le code doit d'abord exécuter un "eval()" pour se décompresser, puis seulement s'exécuter.
N'est-ce pas le cas avec Closure Compiler ?