Chrome 74 contient la première participation de Facebook au code du navigateur.
Les développeurs du réseau social sont particulièrement actifs dans le domaine des API et diverses technologies. La plupart sont d’ailleurs open source et conçues pour de multiples plateformes. Beaucoup ont trait aux performances. Un comble quand on sait comment sont développées les applications mobiles Facebook et Messenger.
Pour cette première participation, il est encore une fois question de performances, tout spécialement la réduction du délai entre une action de l’utilisateur et sa réalisation dans le navigateur. Facebook a voulu intervenir dans un domaine précis : la prise en charge des interactions pendant un chargement JavaScript. Le code fonctionnant souvent sur un seul thread, son exécution doit être arrêtée régulièrement pour vérifier qu’une interaction n’a pas eu lieu avec le clavier ou la souris par exemple.
La solution portée par Facebook se nomme isInputPending, en cours de standardisation par le Web Performance Working Group du W3C. avec cette API, plus question d’arrêts : la vérification des interactions (input) se fait en parallèle de l’exécution du JavaScript. Il n’y a donc plus à choisir entre performances de chargement d’une page et réactivité du navigateur face aux actions de l’utilisateur.
Cela ne veut pas dire bien sûr que les performances décollent après installation de Chrome 74. Les développeurs web vont en effet devoir se servir de l’API pour en tirer tout le bénéfice.
Parallèlement, Facebook envisage d’intégrer cette nouvelle API dans le monde concurrentiel de React.
Commentaires (15)
#1
Car c’est bien connu, quand ton site est de la merde, la solution n’est pas de le réparer, mais d’alourdir les navigateurs avec un truc qui rend ton site moins merdique. Le Web en 2019.
#2
Quand ton OS est mal conçu et que t’as les moyens de le corriger, tu le fais. Le problème en question c’est la conception même de JavaScript, pas son utilisation par Facebook.
#3
#4
C’est ce qu’ils font non? (moderniser javascript)
L’erreur est probablement d’utiliser javascript pour ça alors que d’autres outils le faisaient mieux (flash, silverlight) mais les gafam ont arbitré dans le sens de JS donc il faut tout réinventer ce qu’Apple et Microsoft avaient déjà inventé dans les années 80-90 pour gérer des interfaces graphiques un minimum agréables…
#5
J’aime beaucoup le fait de revendiquer de créer de nouveaux standards pour le web et de se cantonner à chrome pour l’implémentation…
#6
#7
Et Firefox ? Et les autres ?
#8
#9
#10
#11
Ils n’en veulent pas
" />
#12
Apple ils nous ont offert Quick Time ! 
" />
#13
L’exécution parallèle d’instructions sur des postes clients est apparue fin des années 80 pour la gestion des interfaces graphiques des OS windows et apple (et d’autres genre amiga mais disparus depuis).
Flash et silverlight implémentaient des mécanismes équivalents (et aussi les applets java le permettaient, RIP) et à l’époque javascript servait juste à faire tomber de la neige sur ton site web l’hiver et tout le monde était bien conscient des limites (voulues) du langage.
Avoir été vers du full js est assez discutable et “ré inventer” quelque chose proche du multitâche préemptif en 2019 est juste le signe que notre industrie est nulle dans sa capacité à capitaliser l’intelligence et les concepts de dev/archi.
Après je râle mais je n’ai aucun moyen de changer ça et s’être affranchis de technos propriétaires (flash et silverlight) qui avaient de gros dysfonctionnements a aussi des qualités mais juste c’est bête d’avoir remplacé ça par javascript qui était pensé pour les interactions locales et limitées avec le DOM.
#14
Tu fais erreur. MacOS était en multi-tâche coopératif jusqu’à la version 9 et Windows n’a eu la préemption qu’à partir de Windows 95. Pas de préemptif dans les années 80 ni chez Microsoft ni chez Apple. Il y en avait sur Amiga, puis massivement sur BeOS un peu plus tard.
Bon, sinon on est d’accord : Flash, Silverlight, et Javascript ont tous des défauts majeurs. Il est logique que le marché ait éliminé les technos propriétaires et qu’au final il reste JS. Le vrai problème vient du fait que HTML 4 soit resté aussi longtemps sans évolution, alors qu’il aurait fallu une gestion événementielle et multithreadée intégrée à HTML dès les années 2000.
#15