L’actualité récente du RIA (Rich Internet Application) a connu des remous (cf. La mort annoncée de Flex ?), et cela n’est pas probablement pas terminé. Ce marché s’appuie sur l’émergence de nouveaux langages et cadres de développements innovants autant que sur celle de nouveaux supports très hétérogènes (smart phones, tablettes, etc.) dont les capacités ne cessent de progresser. C’est tout l’enjeu des technologies qui proposent de l’adresser. Aujourd’hui, même si certaines plateformes ont pris ou prennent le dessus (Flex, SilverLight1, etc.) d’autres ont l’ambition de les remplacer (HTML5, JavaFX).
Introduction aux RIAs
D’abord, définissons rapidement ce qu’est une RIA. Il s’agit, comme son nom le laisse présager, d’une application Web. La particularité étant que son interface et son expérience utilisateur ainsi que ses performances se rapprochent des applications de bureau locales. Pour cela, un certain nombre de fonctionnalités sont attendues, comme le mode off line ou la possibilité de rafraîchir uniquement les parties actives des écrans sans avoir à les recharger à chaque manipulation.
Mais la particularité principale du RIA est de proposer littéralement l’exécution des applications sur le poste client, au contraire des applications Web « traditionnelles » dont le fonctionnement implique principalement un traitement sur le serveur au travers d’un dialogue permanent avec lui. Par ailleurs, s’exécutant localement, l’application RIA voudra naturellement s’affranchir de tout navigateur Internet, afin entre autres de pouvoir même redémarrer sans qu’une connexion ne soit disponible. Une fois le produit installé, il pourra garder une relation forte avec son origine distribuée, lui permettant notamment de se mettre à jour ou d’accéder à des services partagés, à distance.
Par rapport aux applications Web, les applications RIA ont un paradigme inversé. Dans le premier cas, le serveur reçoit une requête (HTTP ou autre) et construit en réponse une page à afficher, en fonction des paramètres renseignés et des données internes stockées. L’application RIA est aussi une sorte de page, mais qui va s’adresser (pull) à un ou plusieurs (pourquoi pas) serveurs pour collecter les informations (le contenu) nécessaires à son affichage qu’elle va elle-même, par un traitement local, agencer. Certaines technologies peuvent également ouvrir des canaux de communication avec un serveur pour lui permettre de signaler des événements à ses clients (push). Cette architecture s’appuie idéalement sur une forte orientation dite services, elle promouvra donc la création de multiples clients.
Cette approche implique de nouvelles contraintes, notamment en termes de sécurité. Vous ne voudriez pas que n’importe quel produit téléchargé sur le Web puisse démarrer à distance et accéder à toutes les ressources de votre ordinateur personnel… si ? Non !
Les solutions existantes de développement adressent tout ou partie de ces besoins en donnant plus ou moins la priorité à certains d’entre eux. La problématique principale étant de proposer une IHM (Interface Homme-Machine, GUI en anglais) qui soit la même sur toutes les plateformes d’exécution. En effet, quoi de plus désagréable que de pouvoir ouvrir sont application favorite depuis n’importe où… mais sans pouvoir la reconnaître ? C’est tout l’enjeu, au fond, du RIA.
Qu’est-ce que HTML5 ?
À tout seigneur, tout honneur, HTML (pour HyperText Markup Language) est le langage historique du Web (il date de 1989). L’organisme qui le contrôle est le W3C. Il permet la mise en forme et, surtout, la mise en relations de pages au travers du réseau internet. Au départ prévu pour des contenus statiques (textes, images, sons enregistrés à la rigueur), il a rapidement été complété à la fois par des langages de script permettant de modifier le comportement (JavaScript, etc.) et l’apparence (CSS) des pages une fois chargées sur le poste client ; mais également par de nombreuses technologies destinées à construire dynamiquement les pages depuis leur serveur Web (PHP, JSP, etc.) en se basant sur les paramètres des liens hypertext, ou le contenu des formulaires de saisie, appelés requêtes.
Entre temps, une nouvelle forme de structuration des contenus textuels est apparue. Le XML (pour eXtended Markup Language). À côté HTML faisait figure de patois, tant il était possible d’omettre de symboles sans heurter la sensibilité des plus anciens navigateurs comme des plus récents. Mais le ver était dans le fruit ; la structuration forte de XML permettant de solides contrôles (DTD, XML Schema) et de nombreux traitements (XSLT, etc.) en chaîne, son adoption n’a pas tardé. Ainsi est né X-HTML (pour, heu… je vous laisse deviner) ; c’était en 2006-2007, à peu près.
Par ailleurs, les nouveaux besoins multimédia suscités par l’amélioration des performances à la fois des réseaux et des postes clients ont mécaniquement amené la communauté à envisager une évolution du vénérable langage. En effet, le nombre croissant de navigateurs disponibles et, surtout, de variantes possibles dans le développement des sites ont exponentiellement augmenté le risque pour les utilisateurs de se retrouver tôt ou tard confrontés à une incompatibilité quelconque ou, pire, à toutes sortes de failles de sécurité. Internet AIME les standards, qu’on se le dise !
HTML5 est l’aboutissement de ce cheminement. Souhaitant influer sur les travaux du consortium, les éditeurs de navigateurs Web créèrent le Web Hypertext Application Technology Working Group (WHATWG ; standard ouvert). Ils mirent leur nez dans la spécification de X-HTML et donnèrent l’impulsion pour une nouvelle refonte, HTML5, destinée à intégrer les nouvelles pratiques de l’Internet, et en particulier le RIA, au tout début de 2008 (Working Draft). Aujourd’hui, en 2012, HTML5 est toujours en développement2.
Tour (rapide) des frameworks en vogue
jQuery, jQuery Mobile, Twitter Bootstrap, Node.js, Lime.js, PhoneGap, Less…
Qu’est-ce que Flex ?
À l’origine (1996), la société Macromedia a racheté puis développé une technologie capable de mettre en ligne des composants Web animés, un peu comme des dessins animés (les nostalgiques s’en souviendront) qui ont permis de donner un peu de vie aux tristes écrans statiques de l’ère 1.0 du Web. Outre son dynamisme visuel, Flash incorpore un mécanisme d’interactivité avec les éléments affichés, leur permettant de réagir aux actions des utilisateurs. Rapidement, nombre d’artistes et d’informaticiens (parfois les deux) ont proposé des jeux en ligne. Il suffisait d’installer dans son navigateur fétiche (il y en avait alors relativement peu de différents) le plugin de Macromedia pour pouvoir afficher, et donc interagir, avec toutes sortes de concepts excitants sans aucune autre installation locale.
Très vite, des agences Web ont proposé à leurs clients de tirer partie à la fois de ces innovations et, surtout, de la fulgurante prolifération du plugin Flash3 sur le parc des ordinateurs connectés. Moins lourde à télécharger qu’une vidéo, l’animation Flash s’est révélée idéale à la diffusion de messages publicitaires ou de films informatifs efficaces. De plus, la possibilité d’incrustation dans les pages HTML permettent bien des clins d’œil d’infographistes.
Mais bien vite également, les programmeurs ont eu l’idée de s’appuyer sur l’interactivité avec les éléments, pour développer des interfaces de saisie avec effets graphiques divers et variés. Las, les problèmes ont commencé ! Prévus pour l’animation, les outils d’édition de Flash sont basés sur un modèle de timeline, avec la possibilité d’avances et retours rapides, pas sur un modèle événementiel souple et dont les redirections seraient centralisés (type MVC 2). de nombreuses difficultés (des bugs, quoi) sont apparues aussi bien dans les jeux que dans les interfaces de saisie dont les ambitions ont très vite dues être revues… à la baisse.
En 2004, Macromedia réagit et crée Flex. Cette plateforme orientée composants propose enfin un cadre événementiel de développement de « modules » Flash (appelés par les initiés des « swiff », comme c’est charmant). Ouf ! En 2006, Adobe (prononcez « Adobi », pour être dans le coup) rachète Macromedia et continue à investir dans Flex en le dotant d’un environnement complet de développement, en maintenant les librairies de composants, et en encourageant la diffusion de nouveaux composants évolués en permettant notamment leur commercialisation.
Les applications Flex peuvent prendre deux formes : Web ou Desktop. Dans le premier cas, elles sont exécutées au sein du plugin Flash du navigateur utilisé (au sein de son bac à sable 4), tandis que dans le second elles sont exécutées dans une machine virtuelle appelée AIR qui permet de faire résider les applications distribuées sur le bureau du poste client et d’accéder à certaines ressources du système.
Tour des frameworks en vogue
Cairngorm, Parsley, Spark components, BlazeDS, GraniteDS…
La mort annoncée de Flex ?
Bref, tout cela est bel et beau. Mais pourquoi opposer HTML5 et Flex ?
Fin 2011, Adobe a proposé de remettre le SDK, la spécification, le compilateur Flex ainsi que BlazeDS5 sous licence Open Source (MPL) aux bons soins de la Fondation Apache, tout en gardant le contrôle du Flash Player et de FlashBuilder (l’IDE dédié à Flex, basé sur Eclipse). La raison invoquée ? À terme, l’essentiel des efforts d’Adobe vont se porter sur HTML5 ! Victime de son succès, Flex est devenu trop lourd à porter pour Adobe seul, qui espère qu’en élargissant sa base de contribution la feuille de route pourra être respectée. Parallèlement Adobe a annoncé travailler sur des outils de migration de Flex vers HTML5… « A long terme, nous croyons que HTML5 sera la meilleure technologie pour concevoir des applications d’entreprise »6, sans compter son activité autour de DreamWeaver.
Dans la foulée, Adobe a mis sur le marché la version 4.5 de Flex, très rapidement suivie de sa version 4.6, qui se concentrent sur les aspects mobile. Il est désormais possible de publier une même application sur plusieurs plateformes mobiles (iOS & Android principalement, mais pas que) simultanément, tout en bénéficiant d’un environnement WYSIWYG complet (smart phone, tablet) et d’habillages contextuels des composants qui s’adapteront donc à leur hôte. MAIS Adobe abandonne les plugins sur les platesformes mobiles, notamment à l’issue d’un refus sans concessions de la part d’Apple de l’autoriser sur l’iOS, prédominant. Dorénavant, les applications Flex/Flash sur mobile seront uniquement autonomes sur un socle AIR permettant (si vous avez suivi) de s’affranchir des navigateurs Web.
Il y a de quoi rester perplexe, n’est-il pas ? La question se pose donc bien, pour les développeurs Flex, de considérer la possibilité de migrer leur compétences vers HTML5… à terme, bien sûr ! À condition que l’ensemble des fonctionnalités de Flex puissent être reproduites entièrement, ce dont même Adobe semble douter, soit dit en passant7. Voici donc le débat qui est posé. Après cette (longue, mais nécessaire) introduction, nous entrerons dans le vif du sujet pour essayer de définir les caractéristiques de Flex et de HTML5 et tenter de les comparer.
La suite de ce post demain, toujours sur le blog d’Ippon !
1. Certains le disent déjà mort… Oh mon Dieu : un zombie !
2. Pour le détail des changements : http://www.w3.org/TR/html5-diff/
3. cf. http://www.adobe.com/products/flashplatformruntimes/statistics.html
5. Transfert des données entre une application Flex et un serveur Java EE.
6. cf. http://blogs.adobe.com/flex/2011/11/your-questions-about-flex.html
7. Même référence que ci-dessus (UPDATE – 11/15/11 ; « Will Adobe provide migration tools to enable existing Flex applications to be converted to HTML/JavaScript? »).
