Adamn Klein a annoncé qu'il retirait la proposition Object.observe de l'étude du prochain TC 39.
Dans un article où il décrit sa pensée, Klein explique que "le monde a changé."
Il y a maintenant plus de 3 ans, Raphaël Weinstein, Éric Ardisson et moi-même avons designé et implémenté ce que nous pensions être les prémices d'un système de DataBinding du modèle MDV ("model-driven views"). Trois ans plus tard, le monde à changé de plusieurs façons. Même si certains frameworks de DataBinding comme Angular ou Ember ont montré un certain intérêt, il était difficile de voir comment ils pouvaient faire évoluer leur modèle existant pour correspondre à la spécification object.observe.
Dans une interview, Klein explique à infoQ que "Object.observe est une tentative pour distiller les concepts de plusieurs frameworks dans un modèle bas niveau qui pourraient être utilisés par tous. Malgré tout, il était difficile de trouver un système correspondant à tous les modèles de programmation et de les rassembler en une seule primitive commune".
La promesse de object observe était simple. L'implémentation elle-même s'est avérée difficile. A un moment donné, l'équipe angulaire 2 a tenté d'utiliser object observe pour la détection des changements, mais cette idée a été abandonnée au vu des performances qui en ont souffert. Igor Minar de l'équipe Angular a expliqué à infoQ que "le coût à l'exécution n'était pas négligeable".
Object.observe() désactive de nombreuses optimisations de V8, ce qui fait que les objets observés ont des performances bien moins bonnes que les objets non observés. Le système asynchrone de notification de changement était un vrai challenge car il nécessitait de nombreux contextes switch entre le framework et le navigateur, ce qui rendait difficile les optimisations macroscopiques pour le framework.
Matt McNutty, responsable de l'équipe Polymer chez Google, a exprimé les mêmes raisons pour s'éloigner de cette spécification. Les applications complexes finissent par créer des dizaines de milliers d'appels à Object.observe, a-t-il expliqué à infoQ. "Cela rendait le debug difficile, et avait des conséquences sur les performances étranges. Sur Chrome, le temps de préparation était long, mais l'exécution était rapide. Sur les navigateurs avec polyfill, c'était exactement le contraire".
Avec l'utilisation de structures de données immuables par de plus en plus de développeurs JavaScript, la nécessité d'observer les mutations des objets devient inutile. Minar exprime le même ressenti, en expliquant que "la popularité des structures de données immuables, de la programmation fonctionnelle, et des flux de données unidirectionnels, ont rendu Object.observe moins utile que ce que nous avions initialement pensé".
En ce qui concerne les propositions de standards du TC 39, elles doivent rassembler "un nombre significatif de cas d'utilisation et de retours externes" avant de pouvoir passer en phase 3. Object.observe est actuellement en phase 2. Selon Klein, Object.observe est uniquement utilisé par "0,0169 % des pages vues sur Chrome" et uniquement supporté par Chrome et Opéra, qui sont tous les deux basés sur le moteur Blink. La suppression de cette proposition montre que le processus de standardisation fonctionne. McNulty explique que "lorsque l'on travaille aux limites d'une plateforme, il ne faut pas être effrayé par l'innovation. Des fonctionnalités sont proposées, acceptées, puis recalées, si elles ne conviennent pas".
Klein explique à infoQ qu'il est d'accord :
Le processus TC39 est supposé être un incubateur d'idées, jusqu'à ce qu'elles émergent dans la spécification ECMAScript. Ce processus est prévu pour récupérer des retours à chaque étape. Si nécessaire, ce retour peut être de recaler une proposition qui ne doit plus être considérée pour intégration dans le langage. Retirer Object.observe du TC39 après une étude attentive, plutôt que de déprécier cette fonctionnalité du langage officiel beaucoup plus tard, est considéré comme un succès pour le processus.
Lorsque Object.observe sera retiré de V8, cela forcera un changement cassant dans la LTS, qui dépend du moteur JavaScript. Mikeal Rogers, Community Manager pour la Fondation NodeJS, a expliqué à infoQ que les personnes utilisant la LTS (Long Term Support) de NodeJS n'ont pas à s'inquiéter :
Cela sera un changement cassant pour la prochaine version majeure. Cela ne va pas affecter la LTS car nous ne faisons pas de mise à jour majeure de V8 dans la LTS.
Le TC39 est le comité qui standardise la spécification ECMAScript pour le langage JavaScript.