Étiquette : Dart

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.