Le magazine Indexel fait sa une sur le métier d'architecte logiciel avec l'interview de Sami Jaber, à découvrir :

J'animerai une conférence sur GWT (in english please) lors de l'Eclipse Day ce Mardi 24 Mai à l'hotel Palladia (Toulouse). Le programme de la journée est disponible sur le site de l'EDT => http://www.eclipsedaytoulouse.com/. Je compte sur votre présence.
Sami

Je tenais à remercier chaleureusement tous ceux qui ont inscrit la session "GWT à l'épreuve du feu" dans leur agenda de la journée à Devoxx France, la salle était comble. Pourtant, les choses étaient plutôt mal engagées avec une session précédente presqu'entièrement vide. GWT est un des sujets chauds (au sens propre et figuré) du moment, c'est sûr.

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...

L'album Devoxx :


>

La maison d’édition Eyrolles organise Mardi 27 Mars une soirée exceptionnelle destinée à faire rencontrer auteurs (spécialistes du Web) et lecteurs. C’est un événement gratuit et le nombre d’inscrits est déjà important. J’avoue que je n’avais pas prévu de faire le déplacement ce jour là mais pour une fois, je vais privilégier le livre à mes activités professionnelles.

C'est l'occasion pour ceux qui ne pourront pas se déplacer à Devoxx de faire dédicacer son exemplaire de “Programmation GWT 2”, discuter technique ou simplement échanger de manière informelle. Je serai ravi de partager un verre (ou deux) avec vous ce soir là. Rendez-vous dans les locaux d'Eyrolles de 18h30 à 20h 1 rue Thénard dans le 5 ème.

Attention, l'inscription est obligatoire => http://www.editions-eyrolles.com/Evenement/Rencontres_experts/

Sami

Difficile de rester insensible au billet de mon ami Florent dont je ne partage pas la vision même si je comprends tout à fait la problématique dans laquelle il se trouve.

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. 

Sami

PS : J'insiste sur le fait dans cet article que je n'ai jamais dis qu'il ne fallait pas maîtriser un minimum JavaScript pour faire du GWT.