Java Barcamp #4 : compte-rendu (1/2)

Barcamp_small.pngLe 31 mars dernier, Google France nous faisait l'honneur de nous accueillir pour le 4° Java Barcamp. Leurs locaux place de l'Opéra sont superbes, et correspondent bien à l'image que l'on peut s'en faire, à la fois sérieux et un brin déjantés : couleurs vives, salles communes avec des poufs douillets aux couleurs de la société, et bien sûr les fameuses fiches "Tech on the toilet". J'ai même croisé un panda géant dans les couloirs !

Au niveau des sujets, on a réussi à sortir des marronniers habituels et à s'aventurer sur des sujets plus exotiques comme le Domain Driven Development (DDD), les avancées de HTML5 ou le Cloud Computing.
Pour ma part, j'ai assisté à la séance HTML5, auquel je m'intéresse, puis à celle sur le DDD, dont j'ignorais tout.

(Attention : la plupart des liens ci-dessous pointent sur la spécification HTML5, uniquement disponible sous la forme d'une sympathique page web de 3.8 Mo qui risque de stresser quelque peu votre navigateur...)

HTML5

Pour cette séance, une petite dizaine de personnes étaient présentes, dont Philippe Antoine, qui suit le sujet de près et a donc organisé le débat.

Actuellement, deux groupes de travail s'opposent dans la course aux standards : HTML5 et XHTML2.
L'approche XHTML2 vise à forcer les éditeurs de contenu (webmasters, outils de design...) à produire du code 100% correct, respectant la norme XML et donc facilement manipulable par les API standard SAX et DOM. Mais cette approche s'est rapidement révélée irréaliste : d'après l'outil d'analyse MAMA développé par Opera, moins de 50% des pages sur le net possèdent un Doctype, et parmi celles-là, seules 4% sont effectivement valides...

Le W3C a donc décidé de prolonger la vie du vénérable format HTML, et réuni autour de la table de travail les plus grands acteurs du marché pour le faire évoluer : Microsoft, Opera, la fondation Mozilla, Apple... On peut donc s'attendre à un excellent support de ce standard dans les prochaines versions des principaux navigateurs.
De plus, la rétrocompatibilité devrait s'avérer excellente, puisqu'il suffit de modifier le doctype des pages pour activer le mode HTML5.

Les nouveautés se répartissent en deux groupes : celles ayant trait aux balises, et celles relatives à Javascript.

Les balises

Du côté des balises donc, on note une forte inspiration RIA :

  • Les balises <audio> et <video> font leur apparition. Aucun codec n'est encore officiellement défini :

It would be helpful for interoperability if all browsers could support the same codecs. However, there are no known codecs that satisfy all the current players: we need a codec that is known to not require per-unit or per-distributor licensing, that is compatible with the open source development model, that is of sufficient quality as to be usable, and that is not an additional submarine patent risk for large companies.

Personnellement, je reste dubitatif quant à l'utilité de ces balises : Flash est actuellement le codec audio/vidéo universel pour le web, est disponible sur tous les navigateurs (d'accord, sauf lynx...), est amplement outillé et offre des performances satisfaisantes... C'est une sorte de dénominateur commun, un consensus qui empêchera Microsoft et les autres de s'entre-déchirer pour imposer leurs formats (WMV...).

  • Menus contextuels et barre d'outils : la réflexion est en cours sur ces composants. L'idée générale semble être l'implémentation d'un framework de commandes avec gestion de l'annulation ; à voir comment tout cela interagira avec les événements propres aux navigateurs.
  • Canvas : cette balise devrait vous permettre d'exprimer vos talents artistiques directement en HTML et Javascript. SI l'on peut s'attendre à voir fleurir une multitude de casse-briques ou Tetris développés ainsi, et sûrement aussi quelques "proof of concept" très impressionnantes (notamment grâce à des ponts Canvas-OpenGL), je doute de l'utilité réelle de la chose : encore une fois, Flash semble être bien mieux adapté. Enfin, pour les courageux, voici à quoi devrait ressembler la chose :
  1. var context = canvas.getContext('2d');
  2. context.fillRect(0,0,50,50);
  3. canvas.setAttribute('width', '300');
  4. context.fillRect(0,100,50,50);
  5. canvas.width = canvas.width;
  6. context.fillRect(100,0,50,50);
  • Balises sémantiques additionnelles : <article>, <section>, <header> et <footer>, <nav> (collection de liens de navigation) et <aside> (notes en marge) devraient permettre de mieux structurer les documents HTML ruby.png et d'améliorer leur description sémantique, et donc la pertinence de leur référencement par les moteurs de recherche.
    On notera également la balise <ruby>, qui ne sert pas à insérer du code source Ruby (à ce propos, pourquoi ne pas ajouter une coloration syntaxique élémentaire à la balise <code> ?), mais autorise la représentation d'un texte additionnel à côté ou au-dessus d'un texte de base, généralement utilisé pour indiquer la prononciation de certains symboles (notamment asiatiques). Si elle est utilisée, cette balise évitera le recours à des images, non référençables et non accessibles aux personnes handicapées.
  • Du côté des formulaires, de nouveaux types de champs de saisie vont voir le jour : search, url, email, number, range, color, ainsi que différents champs pour exprimer les dates et heures. Evidemment, en fonction du type du champ, des propriétés additionnelles pourront être précisées ou redéfinies, comme le pattern de reconnaissance d'un email ou les valeurs minimale et maximale dans le cas d'un nombre.
    Si l'intention est louable et simplifierait effectivement le développement des formulaires de saisie, je pressens que ces nouveaux champs seront un nid à problèmes et incompatibilités diverses.
  • Enfin, on note la présence d'un composant datagrid, même si sa spécification est encore en travaux. Il devrait permettre une représentation dynamique d'un jeu de données sous une forme structurée (tableau, arbre...). Les données seraient fournies par l'intermédiaire d'un dataprovider, respectant clairement le modèle MVC.

Javascript

Javascript subit également un petit lifting, et se dote de nouvelles fonctionnalités :

  • Local storage : sous la demande sans cesse croissante de pouvoir utiliser les applications web hors ligne, HTML5 devrait se doter d'interfaces spécifiques : ApplicationCache, Storage et même Database. Une méthode isOnline() devrait également permettre de déterminer l'état de la connexion au réseau. Ces fonctionnalités devraient donc remplacer et standardiser celles fournies par fournies par Google Gears ou Adobe AIR.
  • Websockets : voici l'une des fonctionnalités les plus attendues. Elle permettrait d'ouvrir des connexions durables vers des systèmes externes, contrairement au XMLHttpRequest actuel (qui ne fait qu'une requête HTTP). Les possibilités seraient alléchantes : data push en temps réel, communication directe avec des applications externes, etc. Adieu les hacks type polling ou piggybacking et la limite de deux connexions simultanées.
    Evidemment, la question de la sécurité est prégnante, et je pense qu'une certaine forme de sandboxing s'imposera.
  • Javascript history : une interface History donnera accès à l'historique de navigation et permettra même de le modifier. Cela pourrait autoriser une gestion propre du bouton "Back" par les applications écrites en GWT ou en Flash, dont le système de navigation repose sur la modification de l'état d'une unique page plutôt que sur l'enchaînement de pages simples. Et j'ai également travaillé pour un client qui avait une politique de gestion des retours arrière très... spéciale, qui aurait sans doute pu bénéficier de ce système (n'est-ce pas, HollyDays ?).
  • Interaction utilisateur : sous cette rubrique se cachent la gestion du drag'n'drop, le positionnement automatique des ascenseurs pour rendre visible certains éléments, et différentes fonctionnalités jusque-là réservées aux éditeurs de texte, comme la correction orthographique et la sélection de texte.
    A ce propos, quitte à proposer des fonctionnalités d'édition de texte, je me demande pourquoi il n'ont pas amélioré la balise <textarea> (ou défini une nouvelle balise <richtext>) en lui intégrant une barre d'outils et une syntaxe basique de type wiki, définissant les opérations de mise en forme standard (titres, gras, italique, souligné, puces). C'est un besoin récurrent actuellement implémenté par différentes librairies javascript, évidemment incompatibles entre elles...

HTML5 et la guerre des browsers

Compatibilité des browsers

On l'a vu, HTML5 se veut pragmatique et standardise beaucoup de fonctionnalités actuellement réalisées à l'aide de librairies tierces -- ce qui pose le problème de la survie de ces dernières si HTML5 s'impose, car elles représentent tout de même une niche commerciale sujette à compétition (Google, ExtJS, Yahoo...).

En fait, on s'accorde à penser qu'elles s'adapteront et serviront de pont technologique, le temps que les browsers supportant la norme se diffusent sur les postes utilisateurs : si la fonction est supportée nativement par le navigateur, elle sera directement utilisée ; dans le cas contraire, la librairie l'émulera. On retrouve ici le comportement de nombreux toolkits graphiques cross-platform (SWT, Swing...).

Reste à savoir combien de temps il faudra aux principaux navigateurs pour proposer HTML5 à leurs utilisateurs. Généralement, Opera est à la pointe du progrès dans ce domaine (voir aussi un billet précédent sur Opera), et Firefox le talonne de près. Quant à Internet Explorer, il semble s'engager sur la bonne voie également.
La transition risque donc d'être plus rapide que prévu, surtout si l'on considère les possibilités de mise à jour automatique de ces browsers, et la consolidation du marché autour de Webkit notamment.

Tout au moins, sur les machines des particuliers.
Car à l'inverse, le territoire de l'entreprise reste traditionnellement imperméable au changement, où Internet Explorer 6 (voire 5.5 !) règne encore en maître -- davantage pour des raisons pratiques (il est livré avec les postes) que techniques. Et le refus de la plupart des entreprises de migrer sur les nouveaux OS de Microsoft retarde d'autant l'implantation des nouvelles technologies du web en leur sein.
En attendant la mise à jour salvatrice, il existe tout de même des solutions de contournement, comme le script "ie7.js" qui contrairement à ce que son nom peut laisser croire, vise à corriger les incompatibilités et multiples bugs d'IE6, et à le rendre davantage compatible avec les standards.

Browser et desktop

On le voit, les navigateurs s'enrichissent de nombreuses fonctionnalités traditionnellement réservées aux applications bureautiques lourdes.
La frontière est d'ailleurs de plus en plus ténue, grâce à des technologies comme Adobe AIR, Java WebStart, Mozilla Prism

Il est amusant de prendre du recul et de constater que, la grande roue technologique ayant fait un tour complet, on se retrouve presque au même point qu'il y a 30 ans, où le terminal était un simple afficheur des données traitées par le mainframe -- dont l'équivalent moderne pourrait bien être le fameux cloud computing dont la presse informatique fait actuellement son buzz...

Quelques photos

themes.jpg
google-techtoilet.jpg google-panda.jpg


Commentaires

1. Le lundi 6 avril 2009, 12:55 par HollyDays

Sur la politique de gestion des retours arrière «très spéciale», je n'ai qu'une seule chose à dire : no comment...

Pour le canevas JavaScript, moi, je trouve que c'est plutôt une bonne idée. Aujourd'hui, quand on veut afficher des graphiques à partir de données, la solution la plus simple (et la plus courante), c'est de faire générer une image GIF au serveur (puisqu'en plus, le support de SVG par IE est proche de zéro). Vite galère. Quant à utiliser Flash ou une applet Java, c'est écraser une mouche avec un marteau-pilon. Bref, pour les graphiques simples, à mon avis, cette nouvelle API sera la bienvenue.

Alors évidemment, il ne s'agira pas de développer un outil de dessin vectoriel (ou non) en pur JavaScript (quoique... on peut être sûr que des bibliothèques proposeront ce genre de widgets, comme elles proposent aujourd'hui un widget éditeur riche), mais pour les graphiques simples, ce sera très utile.

2. Le jeudi 9 avril 2009, 09:23 par Philippe Antoine

Je suis impressionné par ce retour sur la session html5 !
Beaucoup de choses intéressantes dans ton billet :

  • Le paragraphe sur l'historique XHTML2/5 est vraiment très bien présenté
  • <video> : mon petit doigt me dit que des nouvelles démos sont dans les cartons de mozilla...
  • <audio> : je n'ai pas vu d'exemple sur le web, c'est peut-être l'occasion pour que j'en fasse une (en modifiant 8tracks.com par exemple ?)
  • framework de commandes : j'étais passé à coté de celui là (et je n'ai pas bien compris le principe), mais le lien que tu donnes n'a pas l'air de pointer vers la bonne partie de la spec
  • Javascript : une précision, ce n'est pas javascript qui évolue, mais les API proposées qui sont nouvelles
  • isOnline() / positionnement des ascenceurs : très intéressant !
  • Websockets : pour l'instant le seul serveur qui les supporte est kaazing.com : http://tr.im/iuDT , à quand le support dans glassfish ?
  • Les nouveautés côté formulaire : elles proviennent de l'intégration de la spec "webforms" qui a été intégrée à html5 http://tr.im/iuEb
  • Tu parles de ie7.js, génial !
3. Le jeudi 16 avril 2009, 16:55 par Mathieu Van Driessche

Pour mieux comprendre l'intérêt de <video> par rapport à flash: http://standblog.org/blog/post/2009...

4. Le vendredi 17 avril 2009, 16:04 par Gabriel K.

Bonjour Olivier,

Cela vient un peu tard mais voilà comme promis deux démos de 3D en javascript. A voir uniquement sur Chrome/Firefox 3.1. La différence de vélocité est assez incroyable entre les deux navigateurs, d'ailleurs

http://kawanet.blogspot.com/2009/02...

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.