Certains le savent bien, pendant les cinq dernières années, j'ai préféré décliner la plupart des invitations à des conférences publiques en tant que speaker pour me concentrer sur les activités de DNG Consulting. Depuis 2007 et les rencontres GWT animées avec Didier, je n'ai quasiment pas approché une scène (sauf en petit comité). Un expert, quel qu'il soit, ne vit et sévit qu'au travers de la réalité du terrain, il se nourrit des projets, des clients et construit son savoir faire sur les expériences concrètes du quotidien. Autrement, son discours s’effrite et il finit par boucler. Après plus de 5 ans de projets, il est temps de montrer au plus grand nombre cette partie de mon activité. Pour mettre en lumière la formidable équipe qui m'accompagne mais aussi et surtout les formidables technologies qui bercent notre quotidien depuis 2007. Devoxx France sera un bel événement, incontournable en ce début d'année. Sans trahir de secret (je préfère laisser la primeur à l'équipe Devoxx d'annoncer le contenu précis de la session), vous devriez être ravi si vous aimez Java (EJB 3 et JPA), .NET, GWT, REst, le Push Web et l'optimisation des performances d'une application Web. Je présenterai à Devoxx France le projet Cobra. Un cas concret d'innovation technologique.

En espérant vous y voir nombreux.

Sami

Il faut une sacrée dose de vulgarisation pour arriver à faire comprendre le sens de cet article technique à des non initiés. Mais je me lance en espérant que tout le monde, techniciens comme érudit, sera en mesure de saisir les enjeux autour de LLVM qui dépassent le simple cadre du projet OpenSource.

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

Depuis quelques jours, la blogosphère GWT est secouée par des voix qui s’élèvent pour annoncer sa mort prochaine et son remplacement par une autre technologie Google nommée Dart. L’idée de ce billet est de vous apporter un éclairage sur ces débats, souvent techniques et pas toujours très factuels.

GWT est une technologie innovante créée il y a de cela 6 ans par Google et permettant de créer une application Web entièrement en Java tout en faisant abstraction de la complexité inhérente à JavaScript et HTML. Côté client, on code en Java avec des composants graphiques de haut niveau (Bouton, Menus, Grilles, etc…) et côté serveur on s’intègre avec n’importe quel serveur d’application (Java ou non d’ailleurs). Principal avantage de GWT : il est possible de partager et donc réutiliser les mêmes types (Java) entre client et serveur. Autre bénéfice de taille, GWT tire partie de tous les avantages des IDE Java modernes (complétion des méthodes, Debug via des points d’arrêt, Refactoring, Testabilité).

Après plusieurs années de développement autour de GWT, Google a décidé il y a quelques mois de créer un nouveau langage de développement Web nommé Dart. Ce langage à la syntaxe très séduisante a été conçu pour être performant (procédé de snapshotting) tout en apportant des réponses aux quelques lacunes de Java (closure, ….). D’un point de vue structurel, Dart s’appuie sur un paradigme orienté objet et propose un mode « compilable » (génère du JavaScript) et interprétable (exécuté directement dans le navigateur via une machine virtuelle).

Le contexte étant posé, où se situe le nœud du problème ? Pour créer Dart, Google a eu la bonne (ou mauvaise pour certains) idée de réutiliser certains talents de l’équipe GWT. Un turn-over s’est opéré qui s’est traduit par l’arrivée de nouveaux développeurs GWT, le changement du leader et le départ de contributeurs historiques, mais non moins charismatiques. Il n’en fallait pas plus à certains pour établir un lien de cause à effet entre Dart et GWT. Dart a été créé pour remplacer GWT.

Soyons clairs, Dart est un nouveau langage, cela signifie en pratique qu’il faudra réécrire un IDE adapté (c’est en cours), mettre en place de nouveaux outils de développement et surtout convertir ou intégrer les innombrables framework qui constituent aujourd’hui la norme JEE (entre autre). Un travail non seulement titanesque mais assez rocambolesque quand on connait la taille et la diversité de l’écosystème Java.

Google, à de nombreuses reprises, par la voix de Ray Cromwell (autre contributeur historique) a réaffirmé sa volonté de poursuivre son investissement dans GWT. L’équipe n’a pas été réduite, l’activité non plus. En interne, les produits les plus stratégiques de Google sont écrits en GWT et la Roadmap de la 2.5 est des plus alléchantes avec de nombreux travaux autour du compilateur (et l’intégration de Closure). GWT a prouvé sa maturité, ses performances (nous l’utilisons au quotidien chez DNG et nos clients en sont pleinement satisfaits) et surtout sa productivité hors pair.

Dart est un projet encore embryonnaire venant s’ajouter aux innombrables projets R & D de la firme. On peut l’affirmer aujourd’hui sans trop de risques, Dart, pas plus qu’ActionScript d’Adobe, Silverlight de Microsoft ou JavaFX d’Oracle, ne pourra s’imposer sur tous les navigateurs. Pour faire tourner Dart, il faudra, soit une VM, donc un plug-in, chose difficilement concevable aujourd’hui, soit une cross-compilation vers JavaScript (c’est le cas aujourd’hui) et le choix du langage devient alors le seul critère déterminant (difficile pour faire changer la face du monde). Choisir entre Java et Dart, c’est un peu comme choisir entre Java et Ruby ou Java et Scala. On ne cesse de prédire la mort de Java depuis 10 ans, ce langage n’a jamais été aussi fort et populaire qu’aujourd’hui, même sans les closures et les qualités de scripting.

Google nous a déjà habitués par le passé à faire marche arrière sur un grand nombre de projets (Google Go, Google Buzz, Google Wave, …). Google Web Toolkit a été adopté à partir du premier jour où la communauté l’a découvert, que soit au sein de Google ou à l’extérieur.

Malgré tous ces gages, nous ne devons occulter la possibilité qu’un jour Google fasse machine arrière. Dans ce cas, étudions les scénarios qui pourraient découler d’un changement de stratégie :

- Scénario du pire : Google arrête les développements GWT : Dans ce cas, la firme se met une balle dans le pied car la communauté GWT se désintéressera instantanément de son écosystème (Google Apps, GAE, Google Maps, …). Il devra non seulement réécrire des pans entiers de son système d’information (AdWords, Google Reader, …) mais surtout prendre le risque de décevoir une large communauté Java qui lui est très favorable. Malgré ce scénario du pire, nous pourrions assez facilement imaginer un convertisseur Java vers Dart car les deux langages sont finalement très proches (en effet, le périmètre des API Java utilisées côté client par GWT est assez réduit).

- Scénario du meilleur : GWT évolue au même rythme qu’aujourd’hui, Dart s’arrête dans quelques mois faute d’un support plus large des développeurs et végète avant d’être offert à Apache (qui devient de plus en plus le sombre placard de tous les projets Open Source égarés).

- Scénario le plus réaliste : GWT devient le standard de facto dans la communauté Java pour les développements Web applicatifs et Dart, tout comme Google Closure (et d’autres !), devient un projet essentiellement utilisé en interne.

N’oublions pas une chose fondamentale, le cœur de GWT est son compilateur. Le langage n’est finalement pas si structurant que cela, il est déjà possible de coder du GWT en Scala. On peut très bien imaginer faire communiquer du Dart et GWT façon Java côté client.

La marge de progression de GWT est encore énorme. L’avènement des spécifications HTML 5 va dynamiser son adoption. Dans le même temps, les navigateurs seront de plus en plus performants vis-à-vis de JavaScript.
GWT est donc loin, très loin d’être mort. Son principal contributeur et utilisateur, Google, n’a aucun intérêt à le faire. Officiellement, le discours de Google est sans équivoque, GWT et Dart sont des technologies complémentaires et GWT reste un élément clé dans la stratégie Cloud de Google.

Tout le reste n’est finalement que littérature…

Sami Jaber (DNG Consulting)

Il ne se passe pas un jour sans qu'on ne parle d'un fait lié à HTML 5, que ce soit pour encenser ces vertus multiplateformes, enterrer ses principaux concurrents ou annoncer une n-nième spécification. Le dernier en date et non des moindres est la présentation officielle de Windows 8 par Microsoft. Difficile de rester insensible à ce mouvement de fond, que dis-je ce tsunami technologique qui secoue en ce moment la firme de Redmond. Quelle histoire rocambolesque que celle de la stratégie RIA d'un éditeur qui ne sait clairement plus vers quel saint se vouer. Pour bien comprendre l'ampleur du désastre, faisons un petit retour en arrière.

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)

Après sept mois de silence sur ce blog (un record !), il était temps d'écrire un minimum sur l'une des technologies qui rythment notre quotidien et qui va très bientôt être célébrée dans le tout prochain Google I/O le 10 Mai prochain.

Nous utilisons GWT depuis ses débuts, dès l'annonce officielle de la licence OpenSource, soit 5 ans déjà. Depuis cette date, il ne se passe un jour sans qu'on bénisse l'équipe de Bruce d'avoir créé ce fantastique framework. Que ce soit pour débugger, tester ou coder, tout a été conçu pour la productivité. Je ne vais pas ré-énumérer ici les 10 points qui font que GWT est une technologie incontournable et pourquoi vous devez convaincre votre Boss d'y aller. Mois après mois, de nombreux DSI d'entreprises cotées ou non décident d'intégrer GWT à leur catalogue technologique. Que ce soit pour remplacer du Struts, JSF ou même ASP.NET et Php. Certains secteurs d'activité, moins enclins à prendre des risques techniques, les banques et assurances, commencent à emboîter le pas au concurrent, qui s'y est mis. Le monde de la santé n'est pas en reste, mais aussi celui de l'aéronautique ou de la distribution. Seul bémol peut-être, celui de l'administration, un peu à la traîne avec un parc applicatif pourtant de plus en plus obsolescent.

Depuis 5 ans, GWT nous a apporté une certaine confiance, notamment dans les estimations de charge. Moins de projets Web avec des dérapages. Des clients souvent étonnés par le degré d'ergonomie et les coûts associés, en baisse constante. Terminé les soupes de balises, les taglibs JSP ou les kilomètres de out.println(..) . On pense désormais écran, formulaire, composant et non plus balises HTML. Les seules limites ergonomiques sont celles de l'imagination. Insérer un menu déroulant dans le noeud d'un arbre lors d'un click sur un onglet, improbable mais tellement facile en GWT. Afficher des grilles de données asynchrones triables, filtrables et paginées, aussi facile. Le développeur est bercé par cet univers Java où seules certaines erreurs de compilation viennent lui rappeler que les voix de JavaScript sont parfois impénétrables.

Malgré cela, nous ne portons pas un regard ahuri sur cette technologie. Avant d'arriver à cette maturité, nous avons, comme d'autres early adopters, essuyé des revers. GWT est une technologie qui paraît simple au premier abord. On ne se prémunit pas suffisamment des pièges. La navigation, la séparation des responsabilités, la modularité pour simplifier le CodeSplitting ou les évolutions effrénées des APIs. Il ne faut pas se risquer à aller tête baissée dans la première API sous prétexte qu'une session de Google IO a cartonné sur le sujet.

Depuis un an, l'équipe GWT s'est focalisée sur plusieurs chantiers. Parmi ces chantiers, la refonte du modèle de widget (CellWidget), il est vrai un peu vieillissant et pas toujours extensible en termes de Look&Feel. Mais aussi l'apparition d'un véritable modèle d'architecture reprenant quelques principes d'Android (La notion d'activité) : Le Modèle Vue Presenteur. MVP est devenu incontournable même s'il est loin d'être indispensable. La nouvelle API RequestFactory et Autobean se destine à intégrer les services CRUD et les nombreux backend disponibles sur le marché (JPA, JDO, .). Quant au framework de DataBinding (l'API Editor), il est encore tout frais. Bref, l'année écoulée a été tellement riche en nouveaux services que bon nombre de développeurs GWT sont aujourd'hui perdus, voire dépassés. Nous aurons l'occasion de revenir sur ces sujets dans les prochains jours. Du côté de DNG, après plusieurs Workshop internes, nous avons enfin livré la nouvelle version de la formation GWT avec les nouveautés CellWidgets, MVP et RequestFactory. Ce cours est certes dense mais toujours passionnant à animer.

Pour ceux m'ayant interrogé sur une éventuelle mise à jour du livre « Programmation GWT 2 », rien n'est prévu à courte échéance. Le contenu reste d'actualité. Je garde constamment un oeil aux évolutions futures et tout changement sera annoncé ici.

Pour finir, je ne saurais trop vous conseiller de suivre attentivement le prochain Google IO. Pour cet évènement, les places se sont écoulées en moins d'une heure. Preuve d'un engouement croissant autour des sujets GWT, AppEngine et Android. 

L'ami Sami