Le futur de gwt

Le futur de GWT
Ce que nous proposera la version 3.0…
(c) LTE Consulting - Tous droits de reproduction interdits 1
GDG Saint-Quentin, 20 Mars 2014

GWT aujourd’hui
 100.000 développeurs utilisent GWT dans le monde
 En interne chez Google : 1000 développeurs
 Ecosystème dynamique

Les nouveautés prévues pour GWT 3
 Compatibilité avec Java 8
 Les lambdas sont très attendues !
 Amélioration du code JavaScript généré
 Plus adapté aux navigateurs modernes.
 Prise en charge de CSS3 (GSSResource)
 Prise en charge du modèle FlexBox
 JsInterop
 Le vieux DevMode est mort…

Les Lambdas
ok.addClickHandler( new ClickHandler() {
@Override
public void onClick( ClickEvent event ) {
sendChange();
}
} );

Les Lambdas
ok.addClickHandler( (event) -> sendChange() );
Et en javascript…
ok.addClickHandler( function (event) { sendChange(); } );

Retour aux raisons de
GWT

Quelques raisons…
 En 2006, l’écosystème des navigateurs est un enfer
 Problèmes de compatibilité (trop de disparités => JQuery)
 Non respect des standards
 Fuites mémoire entre le DOM et le JavaScript
 Il est difficile en s’appuyant sur le DOM de construire une hiérarchie de
Widgets.
 Pourtant les VM JavaScripts montent déjà en puissance et permettent de
créer de vraies applications (ex : gmail)

Et aujourd’hui ?
 Les standards du Web évoluent très vite,
 Les navigateurs sont beaucoup plus homogènes,
 Plus puissants,
 Avec mises à jour automatiques.
 Le standard des Web Components va permettre de créer de la structure à bas
niveau (DOM).

Les Web Components
Qui sont-ils ?

Ils arrivent, qui sont-ils ?
 En fait un ensemble cohérent de plusieurs standards :
 Shadow DOM :
 Encapsulation de nœuds DOM
 Etanchéité CSS
 HTML Templates
 Des modèles DOM, non parsés avant utilisation
 Custom Elements
 Possibilité de créer de vrais nouveaux éléments HTML
 Possibilité d’ajouter des fonctionnalités à des éléments existants
 HTML Imports
 Importation d’unités HTML + CSS + JavaScript
 Object Observer, etc…

Future tendance du développement Web
 Il est maintenant possible d’encapsuler ses Widgets directement en HTML,
 Ils sont intégrables dans un document, sans pour autant polluer celui-ci.
 On peut donc faire des « Widgets » directement en HTML
 De nouveaux outils de développement vont émerger. Ceux-ci combleront le
vide laissé par les éditeurs Flex entre autres…
 GWT doit donc s’adapter et s’intégrer complètement dans cette mouvance.

Nextgen JSInterop
La nouvelle couche d’interopérabilité GWT / JavaScript

Pourquoi une nouvelle couche ?
 Le code JSNI est trop fastidieux à écrire…
 Le standard Web va offrir nativement un grand nombre de fonctionnalités
haut-niveau proposées par des outils comme JQuery, AngularJS, etc.
 Il sera donc beaucoup plus fréquent d’intégrer des bibliothèques natives
JavaScript (bibliothèques de Web Components par exemple).
 GWT pourra jouer le rôle de « glue » applicative.
 Pour conserver une bonne productivité, GWT se doit donc d’offrir une
intégration avec JavaScript encore plus transparente !

Une petite piqûre de rappel au sujet de
JSNI…
public class DOMImpl {
public native EventTarget getCurrentTarget()
/*-{
return this.currentTarget;
}-*/;
public final native int getKeyCode() /*-{
return this.keyCode;
}-*/;
public native boolean getMetaKey() /*-{
return evt.metaKey;
}-*/;
}

Et au sujet des JavaScriptObject
(représentation Java d’objets Javascript natifs)
public class Element extends Node {
protected Element() {
}
public final native double getScrollTop() /*-{
return this.scrollTop;
}-*/;
public final native double getScrollWidth() /*-{
return this.scrollWidth;
}-*/;
}

Inconvénients principaux des JSO
 On ne peut les construire depuis Java (pas de new…),
 Toutes leurs méthodes doivent être finales (pas de polymorphisme),
 Une interface Java ne peut être implémentée que par UNE seule classe JSO,
 On ne peut étendre des objets JavaScript.
 Lorsque l’on wrappe une bibliothèque JavaScript, la plupart du code écrit est
de la « glue » syntaxique…

Quelques éléments du futur JSNI

@JsInterface
Définit le contrat d’un objet Javascript
@JsInterface
interface JQueryDialog
{
void setProperty( String parameter, Object value );
void show();
}

@JsInterface( prototype = « … » )
Spécifier le prototype Javascript
@JsInterface(prototype = "HTMLElement")
public interface HTMLElement
{
void setAttribute(String name, String value);
<T extends HTMLElement> void appendChild( T element );
@JsProperty void setInnerText( String html );
}
class MyCustomElement extends HTMLElement.Prototype
{
…
}

@JsProperty
Accès aux champs d’un objet Javascript
@JsInterface
public interface HTMLElement {
void setAttribute(String atr, String value);
<T extends HTMLElement> void appendChild( T element );
@JsProperty void setInnerText( String html );
@JsProperty String getInnerText();
}

Et d’autres encore…
 Les méthodes par défaut d’interface de Java 8
 GWT.jsni( « … » ) pour faciliter l’émission de code JavaScript
 @JsExport pour exporter des prototypes dans le scope JavaScript
 @JsConvert pour les conversions de type
 @JsAware, @JsWrapper, JsObject, JsArray, etc.

Et le mode Dev ?
Un candidat remplaçant ?

Disparition du mode dev
 NPAPI, l’api défunte.
 Super Dev Mode :
 Compilation brouillon très rapide.
 Débogage dans le navigateur grâce à Source Maps.
 Perte de productivité énorme.
 Réflexions autour d’une alternative
 Mode Dev en JavaScript,
 SourceMap debugger pour Eclipse

Architecture du SuperDevMode
IDE Compilation Navigateur
Code JavaScript
Info Debug
Code Java
Outil de
débogage du
navigateur

Probable architecture du prochain mode
de développement
IDE Compilation Navigateur
Code JavaScript
Info Debug
Code Java
Debugger
Plugin de
Débogage
API de Débogage
du navigateur

Merci !
Twitter : @ltearno

Le futur de gwt

Contenu connexe

Similaire à Le futur de gwt

Le futur de gwt