Concernant le contenu, il est toujours très compliqué de creuser avec 45 min. Il y a souvent deux options dans ce cas de figure, traiter un aspect très spécifique d'une technologie en ouvrant Eclipse et en parcourant du code (c'est ce que j'ai fait avec le compilateur en 2007) ou montrer un cas concret d'application stratégique tout en énumérant les défis techniques. Vu le type d'audience de Devoxx et le nombre de clients nous demandant au quotidien " qui utilise GWT et comment ?", l'option REX (Retour d'expérience) nous semblait un bon moyen de faire connaitre la technologie.

J'animerai sûrement dans l'année des conférences ou séminaires plus pointues lors de la sortie de la seconde édition du livre, mais sachez que tout ce qui a été dit lors de cette session est un ressenti très personnel de l'équipe de développement. Que ce soit notre regard vis à vis de JavaScript, la productivité de notre environnement ou les choix technologiques du projet, nous ne voulons en aucun cas en faire un projet "référence", chaque client a ses contraintes et ses particularités. En revanche, nous voulions insister sur le fait qu'aujourd'hui, en 2012, de nombreux clients utilisent GWT dans leurs applications stratégiques. Ils en sont tout simplement satisfaits et viennent le dire à la tribune avec nous.

Un dernier mot sur l'organisation, j'avoue que je ne connaissais pas (assez) la marque Devoxx pour n'être jamais allé à la version Belge de l'évènement. Mais la version Française m'a définitivement convaincu que c'était un évènement majeur et surtout incontournable de la communauté Java. L'organisation a été (de mon point de vue) parfaite. Je remercie donc l'équipe Devoxx pour m'y avoir invité et je leur souhaite une longue vie. Pour avoir organisé 5 Symposium DNG (dont un au Mariott), le plus dur est de durer...

Tout d'abord, le support de navigateurs obsolètes, comme Internet Explorer 6 par exemple, n'est plus l'obsession des DSI qui par contre tiennent de plus en plus à ce que leurs applications offrent également un bon rendu sur les dispositifs mobiles et tactiles.

Effectivement, je rejoins Florent sur ce point. IE 6 commence à devenir obsolète. En revanche, pour les périphériques mobiles, la situation est différente. Dans un billet très récent, le responsable de Sencha, une des sociétés leader sur le marché du JavaScript sur mobile s'exprimait au sujet du support de CSS sur les navigateurs. En résumé, leurs applications aujourd'hui ne ciblent que le moteur de rendu WebKit car c'est le plus performant et surtout le plus riche fonctionnellement grâce à ses ... extensions spécifique CSS ! Les fameux -webkit. En d'autres termes, même s'ils cherchent au maximum à créer une abstration au dessus des spécificités des navigateurs, ils maintiennent d'interminables "if (useragent=webkit) use -webkit" un peu partout. Lorsqu'il s'agit d'évoquer IE et les Windows Phone qui vont bientôt submerger le marché, le discours est tout autre. En effet, il faudrait que Sencha convertisse entièrement les styles WekKit de manière spécifique à IE. Economiquement difficile.

Qu'on se le dise une fois pour toute, l'application Web écrite en JavaScript qui tire partie des dernières évolutions d'HTML 5 et de CSS 3 ciblant la plupart des navigateurs du marché de manière unifiée est un leurre. GWT ne cherche pas à remplacer JavaScript, son coeur est assis sur JavaScript, il permet simplement de développer (et surtout) de débogguer une application Java pour générer du code JavaScript optimisé qu'aucun humain ne serait en mesure de coder. C'est aussi pour cela qu'il existe des compilateurs JavaScript vers JavaScript tels que Closure (utilisé intensivement au sein de Google et bientôt intégré à GWT). 

Lorsqu'il s'agit d'utiliser des fonctionnalités "hype" de type CSS Transform, évènements touch, je peux tout à fait comprendre que GWT ne soit pas idéal. Il reste énormément de progrès à accomplir dans ce domaine même si GWT fournit des évènements Touch.

GWT étant avant tout un socle technique, Google laisse à la communauté ou aux éditeurs tiers le soin de bâtir sur son framework. Ainsi Ex GWT, SmartGWT, Vaadin pour ne citer qu'eux disposent de composants de plus haut niveau, prêt à l'emploi. Malheureusement ces bibliothèques n'ont jamais donné pleinement satisfaction : licence peu « business friendly », adhérence importante, problème de qualité. Au final, la sagesse recommande de se contenter de GWT et de tout développer soi-même.

Là encore, sur ce point, je ne partage pas cette analyse. Côté JavaScript, le choix est encore plus abracadambresque. Qu'allez-vous utiliser, Ext-JS ? Il est payant. JQuery ? C'est plus un socle technique que graphique, il ne fournit pas le niveau de richesse d'Ext-JS. DOJO ? Trop limité visuellement pour des applications graphiques complexes. Quant à mustache, Backbone, Node.js ou JavaScriptMVC, où est la pérennité, la maturité ? Et que dire de Bindows, BackBase, Scriptaculous, Prototype, ... il en existe plus d'une centaine !

Est-ce ce monde technique que nous voulons offrir à nos applications Web de demain ? Si on considère qu'une application est jetable au gré du meilleur framework JavaScript du moment, peut-être. Si on considère qu'une application stratégique métier doit être maintenue plusieurs années et subir les évolutions futures d'HTML 5 sans avoir à tout chambouler en permanence, je vote sans hésiter GWT.

Lorsque nos client ont des besoins graphiques complexes, nous leur proposons GXT (Ext GWT). La licence développeur est payante mais largement amortie vu son degré de richesse. Lorsque nos clients souhaitent quelque chose de très "Web" (par opposition à un look applicatif), nous enrichissons les composants de base, c'est coûteux, mais tout développeur JavaScript en aurait fait de même.

Par ailleurs, GWT, au fil des versions, a gagné en complexité, le pattern « activities/places » pour être correctement employé exige que les développeurs soient bien formés ; RequestFactory, CellWidget sont des nouveautés qu'il conviendra à nouveau d'assimiler et qui contraindront la migration d'un bon nombre d'applications.

Concernant Activity&Places et RF (RequestFactory), nous avons plusieurs fois eu l'occasion de nous exprimer sur le sujet (notamment dans les commentaires de ce billet). Chez DNG, nous utilisons A&P avec parcimonie sans l'imposer à nos clients car ce pattern est loin d'être simple (il fait des dégâts irréparables auprès de développeurs non formés) . Il est aussi loin d'être adapté à tous les cas d'école. Quant à RequestFactory, il n'est pas encore mature mais ce framework offre de nombreux avantages. Nous sommes typiquement ici dans un problème de méconnaissance et sûrement aussi de pauvreté de documentation côté Google. Plus que jamais il faut être formé et plutôt que de dire à nos clients "Lisez la doc, c'est facile", nous insistons sur le caractère complexe des API avancées.

Les nouveaux chapitres de la seconde édition de "Programmation GWT 2" évoqueront aussi ces nouvelles fonctionnalités pour démystifier tout cela. Avec GWT vous êtes libres de choisir les API à utiliser en fonction de vos compétences et de votre culture, rien n'est imposé, sachez-le. 

Dans notre société nous n'avons vraiment pas de vision angélique sur cette technologie. Pour l'utiliser au quotidien depuis ses débuts, plus que quiconque nous sommes confrontés à ses désagréments. Mais lorsqu'à la fin du projet nous faisons la somme de tout ce que ce Framework nous a apporté, la question qui revient inlassablement est "Comment aurions-nous fait sans GWT ? ". Une vision pragmatique mais surtout économique.

Pour finir, la richesse de GWT est dans des API telles que ClientBundle qui permet de créer des scripts JS téléchargés avec les spécificités CSS propres à chaque navigateur ou moteur de rendu en fonction des règles du DeferredBinding. La richesse de GWT est dans sa capacité à diviser le code (énorme) JavaScript en plusieurs fragments à la manière d'un ClassLoader Java. La richesse de GWT est dans sa capacité à fournir un environnement de développement hors pair permettant de débogguer comme en Swing, de tester avec JUnit et de refactorer sous son IDE fétiche. Imaginer un instant développer une application JavaScript de 200.000 lignes de code comme on le fait aujourd'hui en Java est tout simplement incensé.

Dans les années à venir, cette question sera au coeur de tous les débats, l'avenir du Web n'est pas JavaScript. Peut-être un nouveau language, peut-être un nouveau runtime mais pas JavaScript. Le marché l'utilise "par défaut" car les navigateurs l'implémentent sans contrainte de runtime ou de plugin. En revanche, je connais peu de développeurs (non chevronnés) qui aiment JavaScript pour ses qualités intrinsèques. 

Lors de la présentation officielle de GAE en 2009, aucun des standards Java (excepté l'API Servlet) n'était supporté. Il faut le savoir, l'immense majorité des applications Java développées aujourd'hui s'appuient sur des standards, que ce soit Java EE, Spring (qu'on appellera un standard de fait) ou Java Persistence API. Mais le plus bloquant durant toutes ces années a clairement été l'accès aux données.

La plupart des applications en entreprise n'ont pas besoin de gérer des centaines de milliers d'utilisateurs simultanés, ni de monter en charge linéairement à l'infini. Le commun des mortels ne s'appelle pas FaceBook, Google ou Microsoft. En voulant imposer à tout prix des bases de données de type BigTable avec un vocabulaire aux antipodes de ce que nos développeurs maitrisent au quotidien, les fournisseurs de Cloud se sont enfermés dans des technologies puissantes mais peu productives. Dans ce monde, si vous ne parlez pas couramment MapReduce, DataStorage, Entity ou Kind, point de salut. Le langage d'interrogation des données est quasi inexistant car complexe. La gestion des indexs se fait bien souvent à la main, l'import et l'export des données est propriétaires, donc inutile. Et que dire de la partie Décisionnel ou du Data mining.

Quoi qu'en en dise, les bases relationnelles sont là pour durer. Le standard SQL est loin d'être obsolète et les serveurs d'application ne disparaitront pas avec l'avènement du Cloud. Microsoft l'avait d'ailleurs bien compris en fournissant bien avant Google le produit SQL Azure aidé par le fait qu'il éditait déjà la base SQL Server. Amazon de son côté, avec ARDS (Amazon Relationnal Database Service) en avait fait de même. Google ne pouvait rester les bras croisés.

Je le dis haut et fort chers amis, l'an 1 du Cloud à la mode GAE (Google App Engine) démarre officiellement aujourd'hui. Cette fois, nous ne parlons plus d'une pseudo API JDO ou d'un support limité de JPA sur une base BigTable mais d'une vraie, d'une pure et d'une belle base de données relationnelle, j'ai nommé MySQL. En réalité, deux évènements majeurs ont modifié cet écosystème de niche. Le premier a été l'annonce de Google en Novembre d'un support béta (voire alpha) de MySQL (dont le nom officiel est Google Cloud SQL). Un choix stratégique qui adosse GAE à une marque qu'on ne présente plus. Le second a été le support des standards JEE pour l'accès aux bases relationnelles, à savoir JPA 2 (Java Persistence API) depuis une très récente mise à jour du SDK AppEngine (1.6.1). Ajoutez à cela le support d'un framework ORM comme Hibernate et de Spring comme alternative aux API Entreprise Java Beans (non supporté, mais prévu) et vous obtenez la plateforme idéale de développement Java pour le Cloud (des contraintes de sécurité prévenait initialement tous outils instrumentant du byte-code de fonctionner correctement sur GAE).

Non seulement Il est désormais possible de développer avec une base de données relationnelle mais l'architecture applicative du Cloud reprend point pour point toutes les briques logicielles proposées par un serveur d'application lambda du marché. Concrètement, cela signifie qu'une application JEE ne nécessitera aucun changement pour s'exécuter sur le cloud de Google.

Cloud SQL, déjà largement utilisé au sein de Google achèvera d'ici peu sa phase béta et proposera un vrai modèle économique. La base est aujourd'hui gratuite avec un quota de 10 Go (au passage largement suffisant pour un grand nombre d'applications).

Enfin, cette nouvelle donne côté Java ouvre la porte à de nombreux cas d'utilisation. Il est désormais possible de maitriser ses données et de porter d'un simple click son application du Cloud Amazon à celui de Google (via des Dump MySQL). Compte-tenu de cette nouvelle portabilité inter-Cloud, les clients vont enfin pouvoir choisir le modèle économique le plus adapté sans avoir à remettre en cause leur architecture applicative.

Pour vous prouver que tout cela est possible dès à présent, nous vous offrons le code source complet de l'application DNGCloudSQL. Cette application est hébergée gratuitement sur AppEngine et fonctionne avec GWT 2.4, GXT 3.0 beta2, Spring 3.1, JPA 2, Hibernate 3.6 et MySQL 5.5. La démo est disponible ici => http://dngcloudsql.appspot.com/ et le code source ici => http://bit.ly/z7JX2W.

Amusez-vous bien !

ps1 : il vous faudra au préalable créer un compte Google Cloud SQL => https://developers.google.com/cloud-sql/docs/before_you_begin#enroll

ps2: il vous faudra également utiliser le plugin GPE pour Eclipse avec le dernier SDK 1.6.X et paramétrer le tout avec votre compte AppEngine

ps3 : ne vous fiez pas aux performances de l'application en ligne lors du première accès, les VM GAE sont parfois en hibernation ce qui engendre un temps de cold start. Le second appel en revanche doit être rapide.

Depuis quelques années, toutes les technologies qui ont émergées n'ont cessé d'abonder dans le sens d'un navigateur universel ou en tout cas d'une machine virtuelle universelle. Pendant longtemps, les VM Java ou .NET ont laissé entrevoir un espoir très vite balayé par le fait que l'intégration de code natif (écrit en C/C++ ou Assembleur) était un obstacle insurmontable.

On le sait aujourd'hui, proposer un programme portable est clairement un voeu pieu. Même si les architectures matérielles restent globalement stables et se concentrent sur les habituels x86, ARM, PowerPC, etc. la dimension 32 bits ou 64 bits vient s'ajouter à l'ensemble. Et ne parlons pas des périphériques qui implémentent des sous-ensembles de spécifications matérielles (tablettes, téléphones mobiles, etc .). Bref, le rêve ultime serait d'avoir en quelque sorte une machine magique capable de lire du code source et de le traduire dans du code machine spécifique au périphérique sur lequel on s'exécute. A part quelques ajustements d'ordre graphique (la taille d'un téléphone mobile n'étant pas celle d'une tablette ou d'un écran de PC), le développeur n'aurait pas à réécrire son programme pour iPhone, Android, Tablette et navigateurs Web.

Pendant longtemps, Google a entretenu ce doux rêve avec NaCl pour Native Client. Une technologie censée exécuter du byte-code universel à partir d'un plugin qui ressemble pour schématiser vulgairement (que les initiés me pardonnent) à une sorte de VMWare embarqué dans le navigateur. Or aujourd'hui, NaCl ne perce pas car le marché ne jure que par HTML 5 et JavaScript. Un langage dont NaCl fait totalement l'impasse. Il en fait même un contre-exemple car on fait du NaCl pour palier aux performances de JavaScript avant tout. Et c'est le noeud du problème car lorsque JavaScript entre en confrontation avec NaCl, il gagne souvent par la simplicité de son environnement d'exécution (un simple navigateur suffit) là où NaCl requiert l'installation d'une couche logicielle spécifique.

Aujourd'hui, tout cela est en train de bouger avec les récents travaux de recherche autour du projet LLVM. LLVM signifie (Low Level Virtual Machine). Pour bien comprendre LLVM, il faut un minimum de pré-requis en théorie de compilation. Lorsqu'on compile un programme source en exécutable machine, il est d'abord traduit dans une structure intermédiaire (appelé encore IR pour Intermediate Representation ou BitCode pour LLVM). Cette structure va ensuite servir à créer un CFG (Control Flow Graph) qui est une sorte de graphe permettant de mettre le générateur de code machine dans les meilleurs prédispositions pour qu'il puisse optimiser le code initial (spécialiser par rapport à l'architecture matérielle, enlever le code mort, inférer les types, inliner, etc .. ). On parle souvent de front-end pour la partie du compilateur qui génère l'IR et de back-end pour la partie qui génère le code machine.

Quel lien entre tout cela et LLVM ? LLVM est issu des travaux de recherche de Chris Lattner, à l'époque assistant chercheur à l'université de l'Illinois et accessoirement génie de l'informatique. LLVM a ensuite été industrialisé à plus large échelle lorsque Chris a intégré Apple. LLVM est devenu au fil des mois une infrastructure complètement innovante proposant un IR très complet et intégrant dans sa structure un CFG basé sur le puissant algorithme SSA pour Static Single Assignment (créé par IBM dans les années 80 !). Sans aller dans les détails techniques, il faut simplement savoir que LLVM adresse non seulement les langages à typage statique mais aussi ceux à typage dynamique (C, Java, Php, Python/Ruby,Fortran .). L'IR de LLVM est en quelque sorte le parfait modèle intermédiaire pour représenter un programme qui va ensuite générer du code machine natif optimisé via le jeu du générateur de code (Just In Time si cela est fait à la volée lors de l'exécution).

Depuis l'année dernière, Google a compris la puissance de l'IR dans LLVM et l'a intégré à NaCl au travers de pinnacle (Portable NaCl). Cela signifie donc qu'un programme NaCl qui utilisera un compilateur LLVM pourra générer n'importe quel type de code machine. Une aubaine pour LLVM et l'ouverture d'un énorme marché pour Google.

Mais quel lien avec JavaScript et le Web de demain ? Souvenez-vous, JavaScript aujourd'hui est l'infrastructure d'exécution plébiscitée pour les années à venir. Si JavaScript a quelques défauts (pas de multi-threading, représentation 64 bits non supporté pour les nombres), il ne se démarque pas plus que cela des autres langages. De là à faire le lien entre LLVM et JavaScript, il n'y a qu'un pas que le génial Alon Zakai a franchi. En créant emscripten, ce développeur Mozilla a prouvé qu'il était possible de coder une application en C++ réalisant des tâches graphiques puis de générer son code machine en JavaScript via LLVM, démo à l'appui. Ammo.js n'est rien de moins que le portage de la bibliothèque « Bullet Physics Engine » originalement écrite en C++.

Evidemment, il y a encore de nombreuses zones d'ombres, notamment sur les performances de JavaScript. Sur son blog, Chad Austin fait un mini benchmark des performances de C/C++ comparés à leur équivalent JavaScript. Si le facteur laisse pantois (multiplié par 140), concrètement, la faisabilité technique a été démontrée. Imaginez un instant la valeur de cette architecture pour les développeurs de jeux vidéo qui s'arrachent aujourd'hui les cheveux avec la portabilité. Nous aurions un seul code source (et peu importe s'il est en C, C++, C#, Java ou Fortran) capable de s'exécuter via un compilateur compatible LLVM. Puis un déploiement complètement lié à l'environnement d'exécution cible. Ce serait NaCl sur les navigateurs avec plugin et JavaScript pour ceux sans plugin.

Il reste encore deux problèmes majeurs à cette infrastructure multi-plateformes. Créer des environnements de développement adaptés (faire en sorte de générer directement de l'IR LLVM et non un pseudo bytecode propriétaire) et démocratiser NaCl sur le marché. Malgré son statut Open Source (http://code.google.com/p/nativeclient/), NaCl est encore vu comme un projet propriétaire créé par Google. Et c'est bien dommage.

Sami Jaber

ps : L'idée de cet article m'est venu en lisant ce billet de Joel s'arrachant les cheveux avec emscripten pour valider les performances des différents scénarios

Nous sommes en 2004, le monde du RIA est dominé par les technologies dites « Smart Client ». C'est la mode du vectoriel, de Flash entre autre, insaisissable. Dans le même temps émerge une approche concurrente plus tournée vers JavaScript et HTML, c'est le règne d'AJAX. Microsoft cette année là, doit faire un choix, soit redonner de l'air frais à sa technologie client lourd maison (Windows Forms) soit jouer sur le même registre que son ennemi juré Google en pariant sur HTML.

2005, le choix est entériné, ce sera du Smart Client Vectoriel façon plugin. Et pour cause, à la même époque, IE est légion et ses performances sont désastreuses, notamment JavaScript. Les fondations de WPF sont posées fin 2005 puis complétées quelques mois plus tard par la petite soeur « Web compatible » : Silverlight. La première version de Silverlight 1.0 est un loupé d'un point de vue technologique, les suivantes seront bien plus cohérentes dans leur intégration du Framework .NET. A cette époque, bien peu d'entre nous auraient parié sur l'éclosion du standard HTML. Pour l'immense majorité des développeurs, le futur se jouait entre Microsoft et Adobe, Sun ayant largement perdu sa place avec JavaFx.

Tout naturellement donc, Microsoft a investi massivement pendant plus de cinq ans dans WPF et Siverlight, au point de refondre l'interface graphique de Visual Studio ou de réécrire de nombreux produits de son portefeuille (l'étau s'étant même resserré à un moment sur la gamme Office)

C'était sans compter le mouvement de fond qui se tramait en coulisse. Dans les années qui suivirent Apple sortait iOS sur iPhone puis l'iPad. Google planchait sur ChromeOS et Android. Difficile d'imaginer à cet instant que Apple et Google encenseraient HTML 5 jusqu'à menacer les smart clients. Quatre années plus tard, Microsoft a renforcé ses équipes WPF et Silverlight au point de délaisser totalement sa stratégie mobile et d'en oublier son navigateur fétiche.

Nous sommes en Juin 2011, l'annonce de Windows 8 et de sa nouvelle interface graphique à base de HTML 5 est un coup de tonnerre. Invraisemblable, ubuesque. Microsoft se voit brusquement remobiliser des équipes ayant pris fait et cause pour une technologie clairement affichée comme l'anti-HTML. Lorsqu'il sont en concurrence, HTML 5 et JavaScript doivent être préférés à WPF et Silverlight dans Windows 8.

Une pilule d'autant plus difficile à passer lorsqu'on sait qu'aujourd'hui HTML 5 n'est pas outillé ! On l'oublie trop souvent, HTML 5 est encore un brouillon, HTML 5 ne sortira (peut-être) réellement qu'à la fin 2014 pour espérer un support uniforme aux alentours de 2015. Il existe encore une myriade de spécifications en cours d'élaboration et de zones non couvertes par l'actuel standard. Que ce soit CSS 3, le support des outils média (WebCam, Micro, Scanner, etc .) ou la gestion du placement (CSS Flexbox, etc.).

Imaginez un instant les équipes WPF habituées pendant de longues années aux vertus de l'intégration Visual Studio, aux délices du databinding via Drag & Drop, aux miracles de la programmation parallèle via les threads, ouvrir un pauvre éditeur texte et commencer à coder en JavaScript la couche IHM de Windows 8. Les dégâts seront considérables.

Attention, bien loin de moi l'idée de dire ici que HTML 5 n'est pas une technologie utilisable aujourd'hui. Bien au contraire. Mais gardez à l'esprit que coder en HTML 5 se résume essentiellement à coder en JavaScript. Je ne peux imaginer un instant écrire un logiciel contenant des centaines de milliers de lignes de code dans ce langage ô combien puissant et dynamique, mais ô combien inmaintenable et indéboggable. Depuis 2006, nous utilisons GWT justement pour pallier aux innombrables lacunes inhérentes à JavaScript et HTML. Les différences de support entre navigateurs, la taille croissante des scripts et des ressources, les fuites mémoire, les performances, . Au fur et à mesure que les spécifications HTML 5 arrivent à maturité, Google les intègre dans GWT et les développeurs en bénéficient en toute simplicité. JavaScript est devenu au fil du temps d'une certaine manière notre assembleur. Imaginer que Microsoft va découvrir les joies du développement . en Assembleur après avoir connu la Rolls Royce VS/WPF est tout bonnement édifiant.

Dans ce contexte abracadanbresque, Il ne reste plus à espérer une chose, que Script#, Volta et toutes ces technologies qui se sont à un moment donné frottées à GWT soient remises au goût du jour, et ce, même si c'est avec 5 ans de retard sur Google. Il n'est jamais trop tard pour bien faire.

Articles à lire absolument (via twitter de Pierre) :

La pari fou de Microsoft (Peter Bright)

HTML 5 vs Silverlight (David Catuhe)