Panel GWT

La dernière !

Arnaud Tournier, le 28-01-2015

Panel GWT

Cette session est la dernière, elle réuni tous les developeurs principaux de GWT (le fameux steering comitee) pour répondre aux questions de la communauté.

Questions

Pouvez-vous nous donner des arguments pour promouvoir GWT ?

Car beaucoup de gens pense que GWT va mourir. De fait, grâce à Inbox, GWT a bénéficié d’un gros buzz, mais…

Une des raisons de l’ouverture de GWT à la communauté a été d’attirer des contributeurs. Par exemple la documentation a besoin de contributions (qui ne seront pas faites par Google). Ou bien encore, des démos d’applications faites en GWT.

Chaque membre du steering commitee se plie au jeu de faire un pitch sur GWT en 10 secondes…

Christian Goudreau: Les raisons principales sont l’efficacité au runtime.

Ray Cromwell: La technologie la plus sophistiquée, qui a permis de faire Inbox, pour le reste, désolé il a parlé trop vite !

David Chandler: Maintenir de grosses applications avec de grandes équipes.

Daniel Kurka: Au lieu d’évaluer le produit à son site web, commencez à mesurer les performances…

Christian Sadilek: Le typage pour des outils professionnels (Type safety for professionnal engeenering tools).

Colin Althworth: Un outil rapide et efficace pour créer des applications Web, et qui n’est pas mort !

Leif Alstrand: Vous pouvez utiliser les bibliothèques Java dans le navigateur.

Joonas Lethinen: Difficile à utiliser. Il faut donc être intelligent. Si c’est le cas, vous allez obtenir de très bonnes performances, et tout le monde saura que vous êtes intelligent !

Quel est le niveau de qualité du trunk ?

Il y a les code reviews avant que les commits n’arrivent sur le dépôt github (réplique du dépôt interne de Google), donc cela apporte un niveau minimal.

En suivant le trunk répliqué avec une semaine de décalage, le projet aura déjà été intégré dans des projets internes de Google et donc on peux dire que c’est d’assez bonne qualité. Entre autres, Inbox, Spreasheet et Google Groups entre autre auront passé leurs test d’intégration avec cette version du trunk.

Que faut il faire pour anticiper la prochaine architecture des Widgets

Les widgets ont été faits au départ pour résoudre le problème des fuite mémoire (entre autres). Les navigateurs modernes n’ont plus ces problèmes de fuite mémoire. Donc une partie de la valeur des Widgets a disparu. Donc depuis 3 ans il n’est pas raisonnable de continuer les Widgets pour commencer une application.

Quel est le dénomiteur commun pour utiliser les différents navigateurs avec GWT :

  • Javascript JsInterop,
  • DOM API,
  • SafeHtml.

On peut se baser sur ces seules abstractions pour faire des applications. Et oublier les Widgets.

De plus en plus on injectera des Web Composant, ou du DOM.

Pour une nouvelle application from scratch : Polymer, Bricks ou Singular… Mais pas avec les Widgets !

Donc basiquement, il y a plein de choses à retirer du coeur de GWT, comme MVP par exemple. Car le mieux est d’avoir plein de gens testant plein de choses différentes. On s’est aperçu que mettre MVP par exemple, formattait un peu trop les gens. Alors que si GWT était réduit à son coeur, l’écosystème autour grandirait surement beaucoup plus.

Tendance d’aller plus vers le metal, comment

En interne, pour Inbox, on utilise GWT plus le compilateur Closure, donc ils ont ce genre de linker. Mais il y a du travail avant de pouvoir l’open sourcer.

ClosureSingleScriptLinker est utilisé en interne. Une seule permutation, avec Closure et GWT.

Ray a patché ce linker pour le faire fonctionner avec le Super Dev Mode.

Mais le problème est que tout cela est lié à des choses internes de Google et donc il faut s’en défaire d’abord avant d’open sourcer.

Ray va pousser ça sur son GitHub, mais laissera à la communauté le soin d’intégrer tout cela à GWT.

Using more DOM elements than Widgets. Nice ways to still have ValueChangeEvent ?

With Java 8 it will be less boiler plate.

Sur Elemental 2.0, toutes les interfaces de base sont générées. En cours un meilleur typage pour éviter de passer un string contenant le nom de l’événement. A voir, à faire…

Ray : essayer avec les méthodes par défaut sur des interface @JsType.

Outils de build

L’équipe a passé en revue tous les systèmes de build. Maven est très lent, Gradle aussi (d’après Ray). En fait aucun outil de build n’est suffisamment rapide (et incrémental) sauf un : Buck (ne fonctionne pas sous Windows). C’est celui qui est bien incrémental et rapide.

Maven en particulier est le plus lent.

L’équipe de Gwt cherche un systeme de build qui soit beaucoup plus rapide, et incrémental (ne rien faire si rien n’a changé).

Build systems : séparation de GWT en modules car trop de dépendances sont ramenées et peuvent rentrer en conflit avec les dépendances de nos applications

Le build GWT devrait utiliser de vraies dépendances au lieu de shader les jars des dépendances… Mais c’est difficile car un certain nombre de dépendances ont été patchées.

Un projet de mavenization de Gwt avait été entammé mais sans succès au final.

Si on modularise Gwt en petits modules, certaines dépendances vont disparaitre. Comme par exemple gwt-user a des dépendances utilisées pour les tests JUnit. Donc en explosant gwt-user, le problème va s’amoindrir.

Les émulations JRE

Threading, Concurrency ne seront pas émulées.

Pour la partie Counter et Time : pour faire fonctionner cela sur GWT, ça représenterait 200ko de code Javascript, juste pour gérer les time zones !!

Donc certaines API ne seront pas émulées, c’est sûr.

Quelles sont les fonctionnalités que vous retireriez de GWT ?

Daniel Kurka: Générateurs et permutations.

David Chandler: Les Widgets. L’architecture actuelle des Widgets. Mais en gardant l’idée d’une encapsulation propre. Le pattern appearance pourrait aider. Donc nouvelle définition des Widgtes.

Ray Cromwell: Linkers. Ils affectent le build system, c’est plutôt des plugins post-compilation.

Avec GWT 3 on aura une integration avec des build systeme performatnts. Quand GWT a commencé, Java 1.4. Donc aucun moyen de générer du code pendant le build. Donc GWT a fait sa propre solution (les linkers). Mais dans la compilation incrémentale, on voit que c’est une très mauvaise idée - les développeurs du compilo en témoignent. Donc il faut bouger vers l’écosystème Java (Annotation processor et autres…)

Christian Goudreau: Request Factory, MVP.

Christian Sadilek: UiBinder. Il pourrait vivre en dehors de GWT-core. Les HTMLTemplates sont bien meilleurs.

Colin Althworth: DayTime, Formatting, tous les codes dépréciés.

Leif Alstrand: La syntaxe JSNI.

Que voulez-vous que la communauté fasse pour GWT ?

Christian Goudreau: Parler de GWT le plus possible.

Ray Cromwell: Au sujet de la perception de GWT comme mort. Les gens vont en général voir le site web et pas les commits pour voir si un projet est actif. Il faudrait éliminer les vieux tutoriels, articles. La communauté pourrait faire des applications de démo, des articles, des tutoriaux. Cela changerait la perception du site.

David Chandler: Un bon GWT show case avec des screenshots.

Christian Sadilek: Continuer à promouvoir GWT dans votre entreprise !

Colin Althworth: Faire du code maintenable. Ecrivez des tests pour votre code.

Leif Alstrand: Keep on rocking ! Trouvez des bonnes choses à faire construites au dessus du compilateur.

Joonas Lethinen: Montrez le nouveau SuperDevMode aux sceptiques.

Chandler propose qu’on lui envoie nos démo et il les intégrera

Merci, c’est fini !

Voila GWT.create, c’est terminé pour cette année. Ce fut deux jours pleins de très bonnes présentations. L’intérêt a surtout été de pouvoir se projeter dans un futur plus ou moins proche. Cela donne une idée des directions dans lesquelles s’investir.

Merci beaucoup à toute l’organisation, et bien sûr aux participants ! GWT a une très belle communauté !


Arnaud Tournier, le 28-01-2015