Pourquoi Flex reviendra
Combien de fois n’ai-je pas entendu : “mais Flex c’est mort, non ?”
Force est de constater qu’après l’annonce d’Adobe d’arrêter le flash player mobile il y a de ça plus d’un an, les nouveaux projets web se sont quasi exclusivement construits autour de la pile technique HTML5 (HTML, CSS3, JS). Des projets Flex très visibles ont même fini par y migrer (Deezer, peut-être bientôt grooveshark… ok je viens de griller ma crédibilité sur ma conscience pro et les sites que je fréquente au boulot)
Et pourtant… Flex apportait tout de même une solution quasi parfaite à une problématique antédiluvienne du développement web : le rendu iso cross-browser.
Un rendu identique, partout
Le problème peut s’énoncer de manière simple : “Goodbye, fragmentation. Hello, world.
Inconsistent browsers and fragmented mobile platforms? Not your problem.“ C’est l’argumentaire choc d’Adobe pour inciter à utiliser leur solution … de développement pour les jeux en Flash… on y reviendra plus tard. Mais il faut comprendre que chaque browser possède un moteur de rendu qui lui est propre. Il interprétera donc les instructions de la norme en cours (HTML5) selon l’avancement de son implémentation et le choix stratégique qu’il aura fait. Or, en 2004, il était prévu que la norme HTML 5 arrive en recommandation W3C en 2022… même si les choses ont évolué depuis (http://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2022.3F) avec les avancées du WHATWG et du W3C et le changement de définition de la norme et de son évolution, on peut assez facilement concevoir qu’il est illusoire d’espérer qu’un jour, tous les browsers proposeront le même comportement et cela, ne serait-ce que sur les versions récentes des principaux navigateurs de marché (je ne parle même pas des versions plus vieilles ahhemm… ie6 ? non non, je n’en parlerai pas)
La malédiction de l’hétérogénéité
De plus, les éditeurs de browser n’étant pas le w3c, leur intérêt est principalement de se différencier les uns des autres en proposant des fonctionnalités différentes. Ou du moins en implémentant la norme de manière plus ou moins rapide selon les directions stratégiques empruntées. Et au développeur de tester si telle instruction CSS est disponible pour Firefox 18 et quel mécanisme de fallback utiliser pour les versions ne la prenant pas en charge. On peut citer un site comme caniuse.com qui permet au développeur de s’y retrouver dans cette jungle.
Une solution : le plugin
Dans ces circonstances, la solution simple proposée par Adobe était la suivante : puisqu’on ne peut faire confiance à l’implémentation de la norme, proposons un environnement propriétaire maîtrisé installable sur tous les environnements : un plugin.
Cette réflexion peut-être un peu nuancée par les dernières nouvelles de la part des éditeurs de navigateur. En effet, avec l’adoption récente de webkit par Opéra, ce moteur de rendu est présent sur plus de 40% du marché, loin devant Trident (IE) et Gecko (Firefox). Est-ce que cela est synonyme d’un développement plus facile pour les développeurs ? Pas nécessairement, étant donné que les éditeurs auront encore plus intérêt à se différencier sur d’autres points.
(http://techcrunch.com/2013/02/15/why-mozilla-matters-and-wont-switch-to-webkit/)
Du fait du boom des animations flash il y a quelques années, ce player flash offre l’avantage d’être présent sur plus de 90% des postes, est mis à jour beaucoup plus rapidement par les utilisateurs que leur navigateur, qui plus est, gratuit depuis sa création. Certains argueront que c’est une solution propriétaire, que c’est l’incarnation du mal sur la planète numérique et qu’il faut se flageller 3 fois tous les soirs pour avoir vu tourner une animation flash sous Ubuntu… En l’occurrence je qualifierai cela plutôt comme une qualité (le côté propriétaire, pas la flagellation), étant donné qu’il constitue désormais un environnement d’exécution fiable, uniforme, proche des avancées du développement web et qui en couvre à peu près tous les besoins. On pourrait parler de binding, de présentation de données de manière extrêmement performante dans des listes virtualisées, bref, du fait que Flex adresse avec beaucoup de réussite les problématiques récurrentes du développement web, mais ce n’est pas l’objet de cet article.
A mon sens, la problématique principale que propose de résoudre Flex, c’est de créer des applications web au comportement riche en les développant une fois, et de permettre de les déployer sur n’importe quel navigateur/plateforme.
Sans rentrer dans le détail, Flex est au croisement des technologies web (JS, CSS, HTML/XML) et Java (orienté object, interfaçage simple avec des services java, service web…) et constitue une solution de choix pour quiconque souhaite développer un site web en ayant des connaissances dans ces 2 piles techniques.
Pourquoi Flex va disparaître
Délaissé par Adobe, le web design adopte fortement HTML5
Fin 2011, l’annonce d’Adobe de supprimer le flash player mobile ainsi que d’autres outils et solutions peu utilisées et trop coûteuses à entretenir, est très mal passée. A l’époque et encore maintenant, à peu près tout le monde a compris : Flex est mort. Difficile de combattre cette idée, d’autant qu’Adobe a clairement annoncé qu’ils pousseraient en faveur du développement d’application web en HTML5. Flash restant une solution de choix pour l’animation, le jeux et la vidéo. Le framework Flex est confié à la communauté via Apache, mais pas l’environnement d’exécution (le player flash).
On peut alors se poser la question de la pérennité de l’utilisation de cette technologie pour concevoir des applications métiers, des sites web marchand… sachant que l’entreprise qui adosse le player (propriétaire) va investir quasi exclusivement dans le but d’améliorer le rendu des jeux vidéo. Quel sera l’interaction avec la communauté qui va continuer à faire évoluer le framework flex ? C’est aujourd’hui une grande inconnue.
Parallèlement à cela, on assiste à un boom des framework JS, ce qui renforce la concurrence d’HTML face au Flex.
Enfin, on peut pointer du doigt l’échec d’Adobe à proposer une solution performante pour les environnements mobiles et l’énorme difficulté à pénétrer certains environnement propriétaires (notamment iOS). Aujourd’hui, pour faire tourner du Flex sur un iPhone, il est nécessaire de développer une application AIR. Un site web se contentant d’inclure l’application via un plugin flash ne s’affichera tout simplement pas. Est-ce que tous les clients cibles accepteront d’installer une nième application sur leur smartphone ? Enfin, mi-2012, Adobe a annoncé que le flash player ne supporterait pas les versions d’Androïd supérieur à 4.1. La messe est dite…
Le développement mobile
Le développement mobile a cela de particulier que les ressources sont encore très limitées. Et quand bien même il s’agirait du dernier smartphone avec processeur quadricore, une application qui fait dégringoler l’autonomie a très rapidement mauvaise réputation. On privilégie donc encore les développements natifs à des solutions de type Flex, plus difficiles à maîtriser en terme de performance et de fluidité.
Cependant, pour ceux qui ont déjà eu un client qui leur a demandé : “il faut que ça fonctionne sur toutes les plateformes : desktop, tablette, smartphone (dont blackberry… et windows phone… non là je trolle)”, ils ont certainement dû se tourner vers les alternatives permettant de factoriser au maximum le développement de leur application pour chaque plateforme cible. On peut alors évoquer Phonegap ou Sencha… On pourrait en citer d’autres, mais l’important est de comprendre que ce type de solution va basiquement prendre en entrée un langage largement maîtrisé (HTML, CSS, JS), et produire en sortie un livrable pour iOS, un autre pour Androïd, encore un autre pour Blackberry… sans que le développeur n’ait à recoder toute l’application.
Il faut nuancer ceci par le fait que toutes les plateformes n’offrent pas les mêmes ressources (taille d’écran, présence d’une caméra, d’un GPS, d’un acceléromètre…) et que donc, certaines portions de l’application restent à coder de manière native ou du moins très spécifique.
Le retour de flex ?
Qu’on le regrette ou qu’on s’en réjouisse, vendre un projet en flex relève plus de la gageure que d’une réalité du marché actuel. Ou alors c’est que votre préposé aux réponses aux appels d’offre est un champion et qu’il faut sérieusement penser à l’augmenter.
Quoi qu’il en soit, si on se passe de Flex, quand est-il du rendu iso cross-browser ? Est-ce qu’on continue à faire des tests sur les plateformes les plus représentatives (iphone 4, 5, samsung galaxy III, et sony hello kitty pour faire plaisir à la fille du patron) et “ignorer” les autres, en attendant d’avoir des retours utilisateur (ce fidèle beta testeur gratuit) pour découvrir que tel packaging de webkit ne donne pas le même rendu pour ce composant visuel qui a pris 2 mois à coder ? L’éditeur de logiciel aime l’industrialisation, il aime maîtriser les process de déploiement, il aime l’automatisation, il déteste les surprises, il déteste les surprises, il déteste les surprises… Le client aussi d’ailleurs.
Très bien, mais alors, quelle est la solution ? Compiler du JS en vue de l’exectuer dans une VM ? Du Flex si la communauté persiste et ne diminue pas ? Une autre technologie ?
A lire pour compléter:
https://plus.google.com/109047477151984864676/posts/CVGJKLMMehs
http://www.adobe.com/fr/showcase/pdfs/deezer.pdf
http://www.journaldunet.com/solutions/expert/52435/html5-vs–flash–quel-choix-de-technologie-effectuer-pour-ses-applications-web-et-mobiles.shtml
http://web.appstorm.net/general/opinion/should-all-browsers-use-webkit/
http://www.universalmind.com/mindshare/entry/top-5-considerations-for-transitioning-from-flex-to-html5
