Le toolkit graphique du futur (rien que ça)
Laurent Caillette
Ca a commencé avec une discussions sur GWT et deux articles dans Ars
Technica. Les questions fusèrent, toujours les mêmes. Pourquoi le
choix d'une plate-forme de développement Web ressemble-t-il à un
numéro de trapèze volant ? Pourquoi faire du Web si c'est si compliqué
? Pourquoi des gens disent-ils que c'est simple ? Pourquoi le Web et
le desktop sont-ils comme l'eau et l'huile ? Et la question qui tue :
quelle plate-forme pour unifier tout ça ?
Disclaimer : je n'ai jamais réalisé d'appli Web en environnement professionnel.
Zoom arrière et retour aux fondamentaux. Le Web, c'est : 1) les URIs
2) le protocole HTTP 3) le modèle de document.
Les URIs fournissent le mécanisme d'intéropérabilité le plus astucieux
du monde. On peut les faire transiter par mail et les imprimer sur des
autocollants. On peut s'en souvenir. On peut les déduire d'autres
URIs.
Le protocole HTTP est le deuxième mécanisme d'intéropérabilité le plus
astucieux du monde. Considérer son incroyable résistance à la bêtise.
Le modèle de document (HTML) est génial parce qu'il est facilement
lisible par un humain. Pas d'effet boîte noire, on voit ce qui sort du
tuyau. Si ça plante on voit d'où ça vient. Informatiquement il est
simple : une structure en forme d'arbre.
Ces trois aspects s'assemblent pour former le Web, qui est une
visionneuse de diapositives comme chez Tonton mais au lieu d'avoir
juste la marche avant et la marche arrière on peut sauter
*directement* d'une diapo à une autre, et d'un chargeur de diapos à
l'autre. Ne pas oublier : ça reste une visionneuse de diapos.
Les applis Web c'est une façon de prétendre que non cette visionneuse
de diapos n'est pas juste une visionneuse de diapos. Les applis Web
sont plus méchantes. Elles contraignent à un modèle de programmation :
une fonction "serveur" reçoit des paramètres en entrée (paires
nom-valeur) et fournit en sortie une structure d'arbre qui correspond
à un document HTML affichable, ou un fragment. L'arbre renvoyé peut
fournir à l'utilisateur le moyen d'appeler une autre fonction, et
ainsi de suite. Des petits malins ont découvert qu'il était possible
de modifier juste une partie de l'arbre en réponses à certaines
actions utilisateur (avec du Javascript s'exécutant dans le
navigateur) mais on reste à travailler sur un arbre qui représente le
document affiché.
Tiens on peut déjà conclure que de "Web" Google Web Toolkit n'a que le
nom puisqu'il ne permet que de fabriquer des applications monopages,
c'est à dire que toute l'information, quelque soit son niveau de
diversité, se retrouve prisonnière d'une seule page. Fini, la magie de
l'URI et donc l'indexation, bien joué les gars, rappelez-moi pour qui
vous travaillez ?
Même critique aux sites en Flash. A partir du moment où l'application
n'est plus un graphe de documents il n'y a plus d'intérêt évident à la
réaliser à partir d'un navigateur Web qui exposera les URIs, une barre
de boutons (dont le "back" très rigolo pour faire criser les sites de
réservation) etc. Les applis Web nécessitent de louvoyer au milieu
d'une mer de standards bordéliques et inégalement implémentés.
Pourtant il y a toujours des gens pour se lancer dans la réalisation
d'applis dites "Web" au sens où l'interface utilisateur tourne dans un
navigateur. Quels avantages y trouvent-ils ?
Je passe rapidement sur la facilité de déploiement parce qu'il s'agit
d'un sujet archi-rebattu. Pareil pour la sécurité (sandboxing du
Javascript). Bien que les navigateurs Web soient loin d'offrir des
solutions optimales dans ces deux domaines, ils en offrent
suffisamment pour permettre aux applications Web d'exister.
Le modèle de programmation constitue un avantage déterminant. Certes
il est souvent transgressé mais diverses tracasseries (comme avec les
sessions) obligent à rester proche de cette vision requête-réponse qui
permet d'appréhender le serveur Web comme un gros tas de fonctions au
sens y=f(x) ('x' étant de préférence une URI, et 'y' juste un arbre
HTML). L'application devient alors beaucoup plus facile à tester, à
debugger et à scripter parce qu'on s'impose une vision
merveilleusement claire des changements d'état côté serveur. Le
contrat entre le client et le serveur est assez restreint pour
implémenter le serveur dans n'importe quel langage.
En revanche les applications desktop reposent sur des effets de bord :
on a également un graphe d'objets représentant les contrôles
affichables et l'application modifie leur état. Dans ce cadre-là
absolument tout est possible niveau spaghettis (et dérapage des coûts,
etc).
Hélas les applications Web demeurent une souffrance majeure dès qu'il
s'agit d'intéropérer avec le reste du système d'exploitation (genre
uploader les 100 fichiers d'un seul répertoire local). Les
applications desktop enfoncent les applications Web lorsqu'il s'agit
d'offrir une expérience "totale" avec notamment des animations.
Grâce à la montée en puissance des cartes graphiques 3D les systèmes
d'exploitation peuvent maintenant offrir des fonctionnalités
d'animation intégrées au desktop, comme Apple avec Quartz. Ça donne :
des fenêtres qui fument en cas d'erreur, des listes qui bougent pour
montrer les résultats d'un changement de structure, et le sentiment
d'une interface plus réactive. L'animation permet à l'utilisateur de
conserver ses repères visuels et donc de ne pas avoir à tout
ré-analyser dès qu'un changement survient. Sans animations, l'iPhone
serait inutilisable.
Certaines applis Web reposent sur d'impressionnants bricolages pour
reproduire des comportements desktop. C'est désolant sur le fond et ça
ne fonctionne que très ponctuellement. Arrêtez de jouer, bande de
neuneus ! Soit vous vous concentrez sur une belle IHM URI-centrique,
soit vous allez hacker la win32 et on aura la paix (au moins ceux qui
sont sur Mac). S'il faut penser des applications dans un esprit
vraiment Web ça implique plutôt des documents en XHTML et de la
syndication pour produire des documents lisibles par des humains *et*
des machines. Bon d'accord on peut aussi avoir des clients desktop qui
se connectent à ce genre de pages et même les affichent, mais on
s'éloigne de plus en plus.
Toujours à propos des animations : les modèles 3D (incluant des
animations) sont définis par des graphes de scène, qui représentent la
structure des objets, leurs propriétés (texture, couleur...), la
hiérarchie, et aussi les animations selon une timeline. Ainsi le
sous-système graphique se charge de l'affichage en procédant à toutes
sortes d'optimisations (par exemple il n'essaye pas d'afficher plus
d'images qu'il ne peut). Tiens, mais les animations impeccables de
Flash reposent également sur un graphe de scène. Et, si on se repenche
sur le modèle de programmation des applis Web, on peut voir l'arbre
HTML comme un graphe qu'on passerait à un moteur de rendu qui procède
à ses propres optimisations. Ah, enfin une tendance qui se dégage.
Reprenons :
- L'engouement pour les applis Web est lié à un modèle de
programmation basé sur :
1) Une interaction type requête-réponse avec un système serveur.
2) La manipulation d'un simili-graphe de scène (arbre HTML).
3) Des facilités minimales pour le déploiement et la sécurité.
- Le contrat d'une URI (permanence) n'aide pas à réaliser des
applications avec des changements d'états irréversibles.
- Conséquence du point précédent : on parle d'applications Web même
quand c'est juste un navigateur qui sert de client de déploiement.
- Les animations offrent un domaine d'interaction encore peu exploré
mais avec un énorme potentiel.
- Les standards actuels sont un innomable fouillis.
- Et la diversité des plate-formes ne fait que croître.
Ainsi je vois le besoin pour un système d'affichage répondant aux
caractéristiques suivantes et que je nomme S++.
- S++ avale un graphe de scène décrivant des widgets, des layouts, des
transformations, des animations selon une échelle de temps.
- L'affichage du desktop de l'OS repose sur S++. S'il existe encore
quelque chose ressemblant à un navigateur Web, il fait le passe-plats
avec S++.
- Pour supporter cela, S++ sait gérer des droits restreints comme
l'affichage limité à une zone, les cycles CPU alloués, etc.
- S++ supporte d'être appelé par n'importe quel langage (tout comme le
SQL est la lingua franca des SGBDR).
- S++ impose un modèle de programmation où la logique client est
traitée sous forme de fonctions qui, sur un stimulus, renvoient une
mise à jour du graphe de scène. S++ vise le mariage d'amour avec un
langage fonctionnel.
Bon, y'a personne qu'a codé ça sur Sourceforge ? En me documentant
pour compléter cet article j'ai vu passer quelques innovations
sympathiques du côté de GTK. L'article cité en annexe pointe sur des
démos et des articles sympas. Par contre le modèle de programmation
m'a semblé bien loin du modèle fonctionnel.
Dans le genre "ça ne s'arrrange pas" Internet Explorer supporterait
(ou supporterait bientôt) l'appel de primitives Direct3D à partir
d'une page Web (pourquoi le mot "sécurité" me vient-il à l'esprit ?).
Si Flex est basé sur un graphe de scène, Air devrait l'être aussi.
Mais le modèle de programmation exposé ressemble plus à des bouts de
scripts greffés sur des structures décrites en XML pour faire des
effets de bord de partout, maaal.
Swing se voit doté de son propre sous-système de scène de graphe mais
on reste dans un modèle de programmation non-fonctionnel.
Jambi est une surcouche en Java à QT. Contrairement à Java2D, le
dessin en 2D s'effectue via un graphe de scène. Mais toute la
bibliothèque n'est pas structurée autour de ça.
J'ai vu passer des API pour réaliser des interfaces fenêtrées en
Haskell, mais elles reposaient sur une syntaxe impérative. Peut-être
qu'il manque encore une base théorique pour ce toolkit dont je rêve et
qu'il faut d'abord valider une approche purement fonctionnelle qui se
résume à :
nouveau_graphe = f( ancien_graphe, evenement )
Enjoy !
c.
Annexe :
http://trolltech.com/developer/downloads/qt/qtjambi-beta
http://arstechnica.com/articles/culture/reinventing-gtk.ars/2
https://scenegraph.dev.java.net
Dominique Jocal
J'aime bien certains points : le viol de la règle du "human readable", dont on voit l'effet de bord par l'impossibilité d'indexer dans un moteur de recherche.
Que j'appelle plutôt le viol de la boucle récursive uri=>html , qui permet l'indexation google (html contient des uri vers d'autres html... tout le monde peut en faire le rendu : ton navigateur, google lui même dans son résumé...).
De manière générale, les Flexistes (byte code) et GWTistes voudraient te rétorquer qu'ils supportent déjà le bookmarking et l'historique, que cette boucle récursive est géniale et adaptable au monde du "client-side", moyennant du boulot.
Vagues promesses, peux tu re-rétorquer.
J'avoue ne pas savoir comment ils font; j'essaye : uri d'appli => xaml ou autre => uri de service => service json ou autre => uri de service => etc. L'appli sait faire le rendu de l'appli, mais Google ? (dans son résumé, son cache ?)
M'enfin on a fait une BOF sur Flex jeudi, suite à une av-vente marquante (carrément pu montrer un proto applicatif, avec un budget d'avvente !!), i et y'a quand même l'aspect super sympa du modèle de programmation : une productivité pour un résultat qui déchire ! (dans un mode client-side, donc anti moteur de recherche... pour l'instant)
Et la productivité, le web "server side" la cherche depuis vachement longtemps... alors ça vaut le coup d'espérer un merge du monde moteur de recherche avec ce nouveau monde client-side...
Bises !
NB: Désolé de te dire que ce qui se rapproche le plus de ton S++, c'est... Flex et Silverlight / XAML !! OK pour ce qui est de la programmation fonctionnelle, je vais un peu vite. Mais regarde, tu seras bluffé.
Doj
Dominique Jocal
OCTO Technology
Inscrivez vous à l'événement SI de l'année http://www.universite-du-si.com
Laurent Caillette
intervenu en avant-vente sur un projet avec un client Flex) et il ne
s'agit que d'un nième GUI builder avec un langage propriétaire (un et
demi si on compte le MXML). J'ai remarqué que //tous// les modèles de
définition statique d'UI finissaient par être contournés dès que le
projet passait le cap de la démo, adieu le builder et la productivité.
Sans parler de l'expérience limitée d'Adobe dans les VM. Est-ce que
j'ai loupé un truc ?
Sur le papier, Silverlight est plus rigolo avec la possibilité
d'envoyer du XAML directement à IE, on se rapprocherait bien de cette
fusion HTML / desktop. Même si Microsoft parvient à ne pas saloper le
truc (DRM et compagnie) le marché a cessé depuis longtemps de leur
faire confiance.
J'ai l'impression qu'Adobe et Microsoft sont prisonniers de leur
vision du marché, ils n'osent pas imposer la rupture dont tout le
monde rêve plus ou moins ouvertement. Donc on en reste aux mêmes
solutions avec leurs compromis et leurs incohérences. Lorsque Borland
a sorti Delphi ça valait le coup de laisser tomber tout le reste pour
un vrai langage objet accessible et une surcouche extrêmement simple à
Win32. Pareil avec Java qui mettait à notre portée les délices du
Garbage Collector. Mais, dans Flex et Silverlight, je ne vois rien de
déterminant. La question du toolkit GUI du futur, c'est : quelle est
la rupture qui nous rendra malades d'envie au point de nous fera
quitter nos habitudes ?
Les problèmes récurrents que je perçois, c'est :
1) Caractériser l'état de l'application (implications : scripting,
testabilité, sauvegarde / restitution...)
2) Amincir les contrats entre les différentes parties.
Pour caractériser l'état de l'application, l'URI n'est plus suffisante
dès que la page a ses propres états. D'ailleurs, les applications GWT
peuvent bricoler l'historique du navigateur, y compris l'URL affichée
pour la page en cours (par exemple en ajoutant une référence interne
"#inbox/198933"). C'est un véritable glissement sémantique de l'URI
qui ne représente plus seulement une ressource distante, mais un état
transitoire de l'application client !
Pour ce qui est d'amincir les contrats, j'estime que passer des objets
par valeur (un graphe en entrée, un autre graphe en sortie) empêche
suffisamment de bugs pour justifier toutes sortes d'inconforts, mais
c'est extrêmement discutable.
J'ai trouvé un argument dans ce sens dans une présentation de
Singularity, un OS expérimental sorti des labos de Microsoft. Un des
points forts de Singularity est justement de définir la communication
interprocess à coups de Channels fortement typés (et avec des
contrats). Page 10 de la présentation : "Singularity's memory
isolation invariant removes the need for shared memory [...]" Pour des
raisons d'optimisation, les infos que s'échangent les processus ne
sont pas recopiées mais une propriété exclusive est assurée par le
kernel. A la fin on devrait éviter les effets de bord. Reste à savoir
si ces belles simplifications sont intégrables à de la programmation
applicative, et je ne parle même pas de faire entrer ça dans le crâne
des développeurs.
En attendant on est condamnés à émuler ces idées avec des design
patterns en espérant que ça fasse moins de mal que de bien.
c.
http://www.research.microsoft.com/os/singularity/publications/OSR2007_RethinkingSoftwareStack.pdf