Cette semaine je suis tombé sur deux articles de deux toulousains bien connus qui parlaient de GWT. Je n’ai pas un très grand recul sur GWT, mais les articles sont intéressants, alors autant vous les faire partager et donner mon humble avis en quelques mots.
Le premier article, écrit par Florent Garin de la société DocDocku (et membre du ToulouseJUG of course), a un titre des plus explicites : « GWT est-il toujours pertinent ? » Bon, qu’est ce qu’il veut dire par là ? En quelques mots, en mettant en avant une abstraction totale du Javascript, GWT est un frein à la mise en avant des fonctionnalités HTML5 innovantes des navigateurs. Bref, pour le côté métier c’est bien, mais pour l’innovation pure, non. Quid des bibliothèques de Widget ?
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…
Donc, pour Florent Garin, GWT a ses atouts, mais une complexité grandissante (activities / place), ne permet pas d’abstraire le CSS, et est un frein à l’innovation HTML5. Bref, c’est « imparfait ».
Pour répondre à cet article, Sami Jaber (auteur d’une des bibles de GWT )a écrit ceci : « Oui, GWT est plus que jamais pertinent« .
Au moins c’est clair 😉 Si je devais résumer en quelques mots ses arguments:
- Au moins GWT offre un socle HTML 5 solide, et indépendant des frameworks Javascript à la mode et non pérenne. Et d’un point de vue stratégie d’entreprise, c’est important.
- » 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 insensé
Je vous encourage à lire les articles qui sont bien évidemment plus nuancés que NON / OUI. Par exemple, Sami Jaber ne nie pas la complexité du pattern Activities / Place. Pour l’avoir découvert au cours de ce dernier mois, j’avoue qu’il n’est pas si simple de l’appréhender, et que ça demande un peu de pratique et beaucoup de rigueur. Je doute de son utilisabilité dans une équipe de niveau un peu trop hétérogène… Pour le reste de mon expérience, j’avoue que l’abstraction du Javascript m’a fait énormément plaisir! UiBinder par exemple, pour dessiner ses widgets et leurs donner vie, un vrai super outil! Sans compter l’énorme plus : le débuggage…
Et puis c’est un peu hors sujet, mais la facilité de déploiement sur l’AppEngine avec le plugin Eclipse, c’est quand même énorme… Adieu tous mes scripts ANT ! 🙂
A vrai dire, je pensais que GWT serait plus simple à appréhender dans sa globalité. En effet, la documentation est chouette mais peut-être un peu floue à certains moments (toujours sur A&P, j’ai pu voir différentes implémentations sans en comprendre les nuances et les intérêts.) Mais une fois passés les premiers tâtonnements, j’ai vraiment apprécié utiliser GWT au jour le jour grâce à sa multitude d’outils très chouettes (RPC, UiBinder…)
Et puis si on se projette beaucoup plus loin, ne peut-on pas imaginer que nos deux auteurs vont faire converger leurs avis si Dart arrive à s’imposer comme un langage natif dans nos navigateurs, et comme socle de GWT ? N’est ce pas le chaînon manquant ? (pour se tenir au courant sur Dart, ça se passe ici…)
LB.
Merci pour l’argumentaire tout fait 😀
« est un frein à la mise en avant des fonctionnalités HTML5 innovantes des navigateurs » => ah merde j’aurai pas le dernier truc à la mode ???
« est dans sa capacité à diviser le code (énorme) JavaScript en plusieurs fragments à la manière d’un ClassLoader Java » => pourquoi se contenter d’une contrefacon :p
« de débogguer comme en Swing », Swing c’est mort !! et est ce que support le hot-code replacement ???
« 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 insensé »
Ben pourquoi ne pas utiliser du Java alors ??
on peut même affirmer que Chrome est en train de devenir le nouveau IE … ca va dériver cette affaire
bref j’en passe … de quoi me conforter dans mon choix 😀 (mais chut je troll pas)
Il y a des gens pour qui « avoir le dernier truc à la mode », c’est le coeur de métier. Des solutions innovantes, visionnaires, qui mettent en avant les standards de demain. Du son, de la vidéo, de l’intéractivité…
Oui, ça supporte le hot code replacement ! 🙂 (pour 90% des choses…)
Le principe est justement de ne faire utiliser que du Java au développeur! On arrive à l’argument fatal : Quoi qu’il se passe, un utilisateur n’aura jamais besoin de plus qu’un navigateur pour afficher un site fait en GWT. Que ça soit sur n’importe quelle plateforme, y compris Mobile ! Alors que JavaFX…
A noter la réponse de Thomas Broyer, d’Atol Conseils et développements.
http://blog.atolcd.com/?p=971
Juste pour enlever toute ambiguité, GWT n’est pas inaccessible, mais demande un peu de formation et un petit encadrement pour démarrer.
Ou simplement du temps pour se former…
J’ai eu la chance de découvrir GWT en stage, seul et sans encadrement aucun. C’est en effet loin d’être inaccessible mais je peux comprendre (non, en fait j’ai du mal) que lorsque que l’on a ses habitudes, apprendre quelque chose de nouveau n’est pas forcément plaisant. Aussi, certains seront rebutés par la documentation très touffue qui va avec GWT et te répondront que l’intérêt est discutable si tu connais JavaScript ou au moins une ou deux librairies… Je ne vais pas m’étendre là dessus une Nième fois.
Pour reprendre ce que tu dis sur Dart, je en suis pas sûr de comprendre ce que tu entends par « socle de GWT ». Le but ultime est tout de même d’avoir ça des deux côtés: une VM Dart aussi dans le navigateur que sur le serveur.
Nous n’y sommes pas encore mais à terme et si adoption il y a, nous pourrons alors rediscuter de l’intérêt de GWT.
Je crois savoir qu’un certain nombre d’ingénieurs chez Google qui travaillaient sur GWT, planchent maintenant sur Dart et je ne crois pas que ce soit une coïncidence.
Pour l’heure, GWT reste pertinent selon moi.
Comme tu le remarques, l’industrialisation sur App Engine, ou ailleurs d’ailleurs, est tout de même très facilitée et je pense que cela a été une des clés du succès. Démarrer un nouveau projet et l’amener en vitesse de croisière est devenu plus amusant qu’autre chose (bien sur pas uniquement grâce à GWT).
Ce que je veux dire, c’est que résumer l’esprit de GWT est plutôt simple : un langage unique pour du web, des outils pour faciliter la vie du développeur (genre le plugin!). J’ai du mal à croire qu’ils veuillent développer un langage pour remplacer Javascript, et repartir de 0 alors qu’ils ont créé de supers outils. Et si dans un premier temps ils faisaient un GWT qui compilait du Dart au lieu de faire du Javascript ? Si Dart est aussi prometteur que ça, ça pourrait être intéressant… (j’attends les benchmarks moi). Puis dans second temps la possibilité de coder en full Dart mais avec les mêmes fonctionnalités ? Un peu comme Play! avec Java / Scala…