Facebook abandonne HTML5 : explications
Nous annoncions dernièrement l’abandon de HTML5 par Facebook au détriment du développement natif pour des raisons de lenteur. Mais qu’en est-il si l’on regarde l’éco-conception ? L’adaptation aux plateformes matérielles permettent aux langages natifs d’offrir plus de performance et généralement une consommation énergétique moindre. Cependant, les technologies plus abstraites par rapport au matériel comme HTML5 permettent de développer des applications plus portables et donc qui pourront durer plus longtemps.
Analysons précisément les raisons de l’abandon (Pour le moment) de HTML5 par Facebook suite à leur post à destination du W3C.
Manque d’outils
Une des premières raison est le manque d’outil pour analyser le comportement de l’application web. Facebook explique en effet qu’il leur ait difficile de connaître les capacités du matériel. Plus particulièrement pour la mémoire, html5 (comme d’autres technologies du même genre) ne permettent pas d’identifier les limites du matériel en termes de taille mémoire, de buffer GPU… Dans ces cas, difficile d’adapter le comportement de l’application comme par exemple la limitation des images en mémoire.
Quelle analyse devons-nous faire de cette première limitation remontée par Facebook ?
- Tout d’abord, la mesure est primordiale dans n’importe quelle application. Si l’on ne peut pas mesurer le comportement (taille Heap, nombre d’objet…) alors on ne peut pas contrôler la consommation de ressource de l’application. Il en va de même pour l’énergie.
- L’abstraction du matériel est une très bonne chose pour les développeurs (et les utilisateurs) car elle permet plus de souplesse, plus de portabilité… mais cela n’affranchit pas de contrôler ce qui se passe sur le matériel. Abstrait ne veut pas dire inexistant. Cela amène à penser qu’il est nécessaire de mesurer le comportement d’une application web sur différentes plateformes.
Matériel et abstraction
Facebook propose des API pour connaître les capacités du matériel comme par exemple la remontée des données FPS (frame per second) afin d’adapter le comportement (par exemple un pattern de scrolling infini ou alors un pattern de pagination)
- Le développement d’application web par des technos HTML demande d’adapter le comportement et la consommation en ressource de l’application en fonction des plateformes (comme pour les applications natives. Et donc il est nécessaire de remonter des informations des couches basses aux couches plus hautes. On voit poindre ici une complexité pour les applications HTML mais cela est nécessaire si l’on veut optimiser les applications au plus proche du matériel.
- Cette approche montre de plus que les environnements d’exécution (comme les navigateurs) risque de subir potentiellement une certaine obésité. En rajoutant des fonctionnalités, on ajoute en effet un besoin en ressource plus important. C’est ainsi que de nombreuses technologies se sont empâtées. On peut citer par exemple Hibernate sous Java !
Optimisations
Un des plus gros problème de performance subit par Facebook était le scrolling. L’implémentation en JavaScript donnait de plus des performances non égales en fonction des plateformes (et donc de l’implémentation JS sur les plateformes).
- Les applications et sites sont friands d’effets, d’image et de fonctions interactives. Cela nécessite donc (on s’en doutait) toujours plus de ressources. Cela amène une demande toujours plus forte sur les capacités du matériel en plus que sur des technologies efficientes.
- cela renforce l’idée que les complexités de plateforme ne disparaissent pas et seront déplacées vers les frameworks et navigateurs. Rien ne se perd, rien ne crée, tout se transforme comme disait Monsieur Lavoisier.
Facebook lève au final le problème des GPU qui sont des boites noires pour les développeurs. Facebook ne pense pas que la gestion des GPU est plus particulièrement des fonctions d’accélération matérielle ne pourront pas être gérées à moyen terme par les navigateurs.
- Qui peut alors prendre en charge cette gestion ? En effet l’évolution du matériel doit bien être prise en compte. Les frameworks et les applications ont encore du mal à gérer les multi-coeurs sur les PC, la problématique est la même sur les mobiles. Dans tous les cas, cette gestion doit être effectuée (navigateur, framework ou application)
Conclusion
En conclusion, natif ou non, il n’y a pas de solution miracle en terme d’éco-conception. Les langages natifs (en tout cas pour les applications mobiles) sont pour le moment plus optimisées et prennent en compte le mieux le matériel. Encore faut-il que les développeurs ou les frameworks prennent en compte les spécificités de chaque plateformes, OS et navigateurs.
Quant aux technologies non natives comme le HTML5, il reste encore du travail pour obtenir une efficacité optimale.
Cette efficacité viendra avec l’amélioration des environnements d’exécutions comme les OS et navigateurs (par la prise en compte du matériel, l’optimisation) et/ou la fourniture d’API pour les applications donnant des informations sur le matériel pour l’optimisation.
Dans tous les cas, ces évolutions ne seront pas la (seule) solution pour obtenir des applications efficientes. En effet, l’éco-conception n’est pas une chose native dans les logiciels et les optimisations futures du HTML5 risquent que de n’être qu’un patch en attendant des plateformes toujours plus performantes.
