Maintenant que nous connaissons un peu l’historique de HTML5 et de Flex (voir l’article précédent, publié hier), intéressons-nous à leur productivité. La productivité, c’est la capacité pour un ou plusieurs développeurs de produire un logiciel utilisable dans un temps donné. La productivité peut s’appuyer sur différents aspects du développement : d’abord l’environnement de programmation lui-même, mais aussi la structure du langage ainsi que la présence éventuelle de frameworks (SDK) dédiés.
Les IDEs
Les éditeurs de code dont vous vous serviez auparavant pour programmer en HTML4 et JavaScript peuvent tout à fait être utilisés pour HTML5, la prise en compte des nouveautés est bien entendu un plus en termes d’auto-complétion. Il y a pas mal de nouveaux produits, y compris des plugins (Aptana, etc.) permettant de travailler sous Eclipse, pour ceux qui utilisent ce produit par ailleurs. Des éditeurs WYSIWYG sont disponibles (Maquetta, BlueGriffon, Mercury, etc.).
De son côté, nous l’avons déjà dit, Adobe propose un IDE qui, à ma connaissance, n’a pas d’équivalent. Il existe sous deux formes : standalone ou plugin ; les deux solutions s’appuient sur Eclipse, quoi qu’il en soit. Cette solution propose la création de projets (Flash, AIR, mobile), le montage WYSIWYG des interfaces, le débogage et prend en charge la compilation avec les SDKs disponibles.
Les aspects purement rédactionnels sont assez difficiles à départager. Mais bien sûr, le WYSIWYG est très important. Or, je ne crois pas qu’en HTML il soit jamais possible de garantir à 100% la conformité entre les différents navigateurs. Vous devrez effectuer « à la main » les tests de compatibilité à la fois de rendu et de comportement. S’appuyant sur une machine virtuelle, Flex prends la main.
Les langages
HTML5 s’appuie sur trois langages : X-HTML 1 .x qui est le langage de description des documents Web, JavaScript qui est un langage objet permettant d’intervenir sur la structure DOM de ces documents ou d’intercepter les actions de l’utilisateur sur son navigateur, et CSS 3 qui prend en charge l’apparence éventuellement contextuelle des pages. Actuellement, la partie JavaScript est le plus souvent étendue par la librairie JavaScript jQuery qui permet de faire le lien entre les trois langages1 de manière très efficace, tout en prenant en charge une grande partie des disparités entre navigateurs. Par ailleurs, ce module léger peut se voir adjoindre un nombre sans cesse croissant de plugins adressant toutes sortes de particularités, notamment jQuery UI et jQuery Mobile. Le transfert de données s’appuie le plus souvent sur le format JSON. Mais les APIs Node.js et Sencha semblent aussi proposer des choses intéressantes.
Afin de combler le retard de HTML4 et JavaScript sur la question du RIA, HTML5 propose de nouvelles fonctionnalités fort pratiques : history, Drag & Drop, Web Forms, Local & Session Storage, Ajax natif amélioré, support des WebSockets2, extensions media et canvas (SVG), etc.
Flex, quant à lui, s’appuie sur deux autres langages : ActionScript qui est un langage de script orienté objet, et MXML qui est un langage de description des IHM, avec la particularité qu’il est possible qu’un « script » MXML étende (au sens de l’héritage objet) une classe AcionScript (afin d’obtenir une meilleure séparation vue/comportement et une meilleure réutilisation). En fait, MXML est optionnel, étant donné que tout ce qui peut être décrit avec peut l’être également en ActionScript. Il propose cependant une syntaxe beaucoup plus concise et claire dont vous ne voudrez certainement pas vous passer.
Toujours au rayon du langage, on note d’autres points importants concernant Flex : notamment le mécanisme de binding (simple ou double sens) qui permet de lier la valeur d’une variable à son affichage et éventuellement sa saisie. Flex propose également la notion d’états de pages ; ils peuvent permettre d’influer sur leur aspect et leur comportement à partir de valeurs symboliques, limitant ainsi au minimum le code nécessaire aux changements cosmétiques dans les traitements métier. Ces concepts sont très puissants et font toute la différence en termes d’architecture orientée composants.
Flex dispose en plus de cadres de développement (Cairngorm, Parsley, etc.) ainsi que de façades permettant de transférer les données applicatives entre le serveur et le client (format AMF3, GraniteDS, BlazeDS, etc.). Pour HTML5 et CSS3, les frameworks Less (feuilles de style dynamiques et/ou grid layouts), PhoneGap (pour encapsuler les applications mobiles – qui fut un temps entre les mains d’Adobe, d’ailleurs, et s’appelle maintenant Apache Cordova), Gravity (feuilles de style Sass, CoffeeScript) ou encore Boilerplate (qui supporte la technologie Flash !) et Perkins commencent à se faire une place sans que l’on sache vraiment lequel s’imposerait éventuellement. Je ne peux pas prétendre les avoir testés, tout avis est donc bienvenu. Concernant la partie mobile, il apparaît dores et déjà que le développement hybride a toutefois des limites intrinsèques assez fortes (PPDC), sachant par exemple que la norme JavaScript WebWorkers n’est pas supportée par Android.
Le rendu
Avec HTML, le rendu est avantageusement assuré par la partie CSS qui est en elle-même une compétence à part. Son usage peut se révéler abscons, et intervenir dans son code sans de solides connaissances réserve parfois de mauvaises surprises. Mais cela permet de séparer en activités séparées la structuration des documents du rendu final. Les développeurs fonctionnels d’un côté, les infographistes de l’autre.
Flex propose un modèle d’affichage plus simple à la base, mais avec la possibilité de l’étendre… en CSS ! Mais comme la plupart des options de rendu et des effets sont disponibles depuis MXML, il est plus rapide d’obtenir un rendu efficace sans faire appel à des notions trop poussées. C’est-à-dire qu’avec Flex on aboutit à un produit fini, standardisé, beaucoup plus facilement.
Bien sûr, l’écosystème HTML5 évolue très rapidement et on s’appuiera avec profit sur une API comme Twitter Bootstrap ; cependant, aucune standardisation ne vous est garantie quant au rendu sur différentes plateformes (épreuves personnelles à l’appui). [mauvaise-foi ON force=”légère”]Par ailleurs, il reste difficile de localiser et d’évaluer ces nouveaux outils[mauvaise-foi OFF comment=”mais quand même…”].
En face, l’application TourDeFlex permet de « visiter » l’ensemble des composants internes de Flex en situation réelle, c’est une aide précieuse au design des applications. De nombreuses librairies additionnelles de composants sont disponibles pour Flex (Spark, Hero4, flexlib, Eskimo, etc.), et Adobe a très vite pris au sérieux la nécessité de proposer rapidement une plateforme de développement pour les mobiles. Après une hésitation quant au choix du mode de distribution pour les mobiles (plugin Flash contre VM AIR), les outils (FlashBuilder 4.5) et les composants dédiés (FlashBuilder 4.6) ont très vite été mis à la disposition du public.
L’architecture
Bref, les deux techniques sont orientées événements mais là où HTML5 propose une séparation nette des compétences de programmation (X-HTML et JavaScript d’un côté, CSS de l’autre), Flex s’appuie essentiellement sur une architecture composants, ce qui à mon avis fait toute la différence…
HTML5 permet l’inclusion dynamique de fragments de code HTML. Votre interface peut donc être découpée dans des fichiers différents réutilisables. Seulement les fichiers HTML ne sont pas des classes, ils n’ont pas d’état. Par ailleurs, et c’est un « problème » plus inquiétant, les fragments HTML ne peuvent pas embarquer, à ma connaissance, de comportement qui leur soit propre (c’est-à-dire de scripts internes) ; un fragment n’est pas interprété lors de son chargement dans un document, il est simplement injecté dans l’arborescence DOM. Pour animer la structure d’un fragment, vous devrez donc charger à part les scripts lui afférant – éventuellement dans une partie distincte du document parent, ce qui peut poser un problème de maintenance.
Concernant l’accès aux données, AMF, BlazeDS et GraniteDS fournissent un ensemble de solutions largement exploitées du côté de Flex. Cependant il s’agit d’invocations distantes (RemoteObject) et, en ce qui me concerne, je crois que les architectures SOA(P) et notamment le protocole REST ont plus d’avenir. Elles permettent, justement, de s’affranchir de solutions spécifiques aux technologies RIA elles-mêmes. Sur la technologie REST encore plus que sur les services web, HTML5 et jQuery prennent la main avec une facilité déconcertante, via Ajax et le format JSON ; c’est un fait. Pour Flex, il semblerait que HTTPService ait encore un peu de chemin à faire, en particulier pour supporter l’ensemble des « verbes » CRUD HTTP s’appliquant à REST. Mais cela reste exploitable et évolutif (par exemple avec RestHttpService5). Match nul donc, en ce qui me concerne, sur cette question liée aux évolutions du web.
Comment structurer ses applications ?
Alors bien sûr, une API comme jQuery, nous l’avons dit, permet le développement de plugins. C’est-à-dire qu’elle laisse aux développeurs la possibilité de l’étendre. Mais étendre une API n’est pas la même chose que de modulariser son code. Premièrement en étendant un produit tiers, vous vous rendez dépendant de ce produit. Et deuxièmement, surtout, vous vous rendez dépendant de la version du produit disponible au moment de vos développements. En imaginant que vous ayez développé un certain nombre de plugins jQuery pour répondre à vos besoins de réutilisation liés au métier de l’application ; vous n’aurez peut-être pas la possibilité de bénéficier des avancées de ce framework dans deux ans, lorsque vos besoins fonctionnels auront évolué. Il s’agit-là d’un cas typique de création de dette technique.
Les composants, eux, disposent d’un état (stateful) et sont autonomes6. Tout en pouvant s’appuyer sur les APIs disponibles, ils encapsulent à la fois un état et un comportement avec un couplage faible. Figurons-nous qu’un plugin (une fiche électrique, littéralement) est fait pour correspondre à une « prise électrique » (une interface d’injection dans l’hôte), il s’agit d’une contrainte imposée au développement, tandis qu’un composant reste un utilisateur ; c’est toute la différence qu’il y a en conception entre l’héritage et la composition.
Or, là ou Flex conserve un avantage non négligeable, de ce point de vue, c’est dans l’imbrication d’ActionScript et de MXML. Il est possible de créer des widgets en JavaScript (cf. jQuery UI), mais les éléments doivent être instanciés « à la main », si j’ose dire. On y perd grandement en lisibilité, et donc en productivité. Par ailleurs, cette technologie est prévue pour faire des composants graphiques, ce qui peut ne pas être adapté à l’élaboration de composants métier évolutifs.
Comment tester ses développements ?
Si les fonctionnalités de débogage de Flash Builder et FlexUnit pour les tests unitaires ne vous suffisaient pas, l’outil Web Monkey permet des tests d’intégration très complets.
Pour HTML5, plusieurs outils « web », non spécifiques, sont disponibles. Par exemple Selenium. Mais il s’agit là de tests d’intégration. Pour le JavaScript lui-même, les APIs jsUnit (apparemment délaissée, mais disposant d’un plugin pour Eclipse), RhinoUnit et qUnit peuvent rendre pas mal de services limités à cet aspect technologique. Mais il n’existe pas actuellement de norme aboutie de protocole de débogage distant de page Web (HTML + CSS + JavaScript) ; c’est un chantier certes actif mais balbutiant. N’oublions, pas quand même, que les navigateurs permettent l’inspection des pages, ce qui reste utile mais pas forcément pratique.
Pour moi, l’avantage va à Flex, cette fois encore, pace que les solutions sont complètes et centralisées. Cet aspect des développements est tout à fait primordial. Aucune application professionnelle ne peut aujourd’hui se passer d’un minimum de tests de non-régression. Cette contrainte est chronophage et doit donc bénéficier des outils les plus productifs possibles. Pour cela, ils doivent être intégrés (faciles à manipuler), standardisés (faciles à reprendre par de nouveaux équipiers) et intégrables à un processus d’intégration continue (pour pouvoir superviser le niveau de qualité du logiciel).
Flex gagne le match ; quel avenir pour Flex ?
La force principale de Flex est donc sa préséance (voir première partie). Adobe a beaucoup investi depuis longtemps sur cette technologie et sa communauté est très active. Malgré le poids de ses organismes de standardisation, HTML5 est donc bien le challenger, dans cette histoire. Les développeurs JavaScript et CSS le savent bien, le standard n’implique pas l’uniformité en matière de Web. Pour s’imposer, HTML5 devra pouvoir s’appuyer soit sur un parfait support de la part des navigateurs du marché ; et nous avons déjà remarqué combien ils sont nombreux. Soit sur un cadre de développement HTML5 proposant une prise en compte exhaustive des différences entre eux. Ceci reste une gageure, soulignons-le, et ce strictement pour les mêmes raisons !
Flex, de son côté, va profiter de cette inertie pour conquérir toujours plus de marchés, et donc consolider sa position de standard de facto. Par ailleurs, l’implication dans le projet confié à la fondation Apache promise par Adobe permet d’espérer que Flex pourra continuer à bénéficier d’orientations solides et d’une forte cohésion. Ces deux atouts pourraient constamment creuser l’écart, en termes d’adoption professionnelle, aussi longtemps qu’une version complètement supportée (et finalisée) de HTML5 se fera désirer. La plus grande peur de la communauté étant que la division DreamWeaver chez Adobe ne prenne le pas sur celle de Flex…
Pourquoi choisir Flex aujourd’hui, donc ? Si vous avez déjà du Flex, si vous ne pouvez ou ne voulez pas attendre, ou si vous pensez qu’HTML5 ne rattrapera jamais (à l’échelle industrielle) son retard ; vous le ferez. Si, au contraire, vous voulez construire un produit dont le socle technique sera encore vivant dans dix ans, et que vous pourrez toujours faire évoluer, alors… vous attendrez !
1. jQuery propose d’accéder au DOM via des sélecteurs CSS (entre autres), pour le modifier ou lui greffer des comportements dynamiques consolidés.
2. Elles-mêmes très peu/mal supportées par les serveurs, en tout cas pour l’instant.
3. Format binaire inspiré de SOAP
4. Toutes deux intégrées à TourDeFlex
