Abandon de Object.observe : le projet ne fera plus partie des propositions ES7

Abandon d'Object.observe : le projet ne fera plus partie des propositions ES7
Cette méthode observait les changements apportés aux objets

La méthode Object.observe() est utilisée pour l'observation de façon asynchrone des modifications apportées à un objet. Elle fournit un flux des changements dans leur ordre d'apparition. C'est une technologie expérimentale, qui fait partie des propositions de ECMAScript 2016 (ES7). Ou bien devrais-je dire "faisait partie".

Car aujourd'hui, le projet risque d'être abandonné : O.o' (si je puis me permettre).

Il y a déjà plus de trois ans que Rafael Weinstein, Erik Arvidsson et Adam Klein ont implémenté ce qu'ils pensaient être une primitive dans le système de data-binding des MDV (model-driven views). Ils ont d'ailleurs conçu un prototype dans une branche du moteur V8, avec l'accord de l'équipe V8, et ont travaillé avec l'équipe de Polymer pour qu'ils construisent leur système de data-binding par-dessus.

Le monde du JavaScript étant en perpétuel changement, des projets comme Ember et AngularJS ont pris de plus en plus de place. Mais ils ne sont pas compatibles (ou bien difficilement) avec la méthode Object.observe. De plus, Polymer a réécrit son code et il ne se base plus sur cette méthode. De son côté, le modèle de traitement de React semble fort apprécié. La méthode n'aurait donc plus un grand intérêt ou avantage.

C'est donc après de longues discussions que le projet va être retiré du moteur V8 et des propositions du TC39 (bien qu'il soit actuellement en stage 2). C'est ce qui a été envisagé jusqu'à maintenant. Peut-être que le vent peut encore tourner.

:fleche: Source.


Et vous ?

:fleche: Que pensez-vous de cet abandon ?
:fleche: Quelle technique utilisez-vous à la place ?

Je trouve ça vraiment dommage j'utilisais cette méthode ... Utiliser une bibliothèque comme Polymer ou Angular c'est assez horrible pour juste une méthode.

Je crois que tu a mal compris, la plupart des framework JS utilise cette méthode, et non les développeurs qui utilise les frameworks juste pour cette méthode.
C'est pas plus mal quelle disparaisse...

Citation:

---

Envoyé par vermine

Polymer a réécrit son code et il ne se base plus sur cette méthode.

---

Et ils utilisent quoi à la place ?

@beekeep : polymer/observe-js

C'est indiqué:

Citation:

---

It exposes a high-level API and uses Object.observe if available, and otherwise performs dirty-checking.

---

Citation:

---

Envoyé par steel-finger

la plupart des framework JS utilise cette méthode, et non les développeurs qui utilise les frameworks juste pour cette méthode.
C'est pas plus mal quelle disparaisse...

---

Je vois pas en quoi c'est pas plus mal.
Object.observe a toujours été la promesse "long term" d'angular qui allait résoudre les problèmes de performances inérant au dirty checking...
Alors on fait quoi maintenant?

J'ai de plus en plus l'impression que le JS en train d’évoluer plus pour aux répondre aux besoin des gros framework plutôt qu'au besoin de tous les développeur...

C'est quoi cette logique de proposer de nouvelle fonctionnalité plus pour répondre aux besoin de certains framework qu'autre chose, puis de sens débarrasser puisque finalement ils en veulent plus... Et les autres dev qui était eux aussi intéressé il font quoi?

Twitter est en feu sur ce sujet... Plusieurs personnes dont Brendan Eich s'en réjouissent, je ne comprends pas pourquoi. On a toujours besoin d'une solution de détection de changement viable en JavaScript ! Angular, Ember, Polymer, tous ces frameworks ont fait leur propre tambouille. J'ai moi aussi bricolé de mon côté pour ObjectModel. Les solutions actuelles sont inefficaces :
- les getters/setters ES5 ont beaucoup trop de contraintes
- tout comme les proxies ES6 qui obligent à perdre la référence à l'objet initial
- se baser sur les DOM events comme Polymer et Riot ? Un coup dans le mille, un coup dans l'eau...
- dirty checking ? Trop complexe, performances médiocres, et on perd la synchronicité des changements.

Que reste-t-il ? La spec Object.observe n'était pas parfaite, mais c'était une vraie solution à ce problème. Simplement parce que d'autres libs comme React ont choisi des voies autrement plus radicales comme l'update général et systématique d'un DOM virtuel, cela ne signifie pas que l'idée de base du data binding était mauvaise. La preuve, elle est encore largement répandue dans la plupart des frameworks populaires.

Bref, très déçu par cette décision qui semble injustifiée et pénalisante (notamment pour Node qui doit en assurer le support pendant 30 mois à cause de la release LTS). Ce n'est pas une décision définitive, mais vu que les pro-React sont en train de parader sur Twitter comme si leur équipe venait de gagner la coupe du monde, je crains fort qu'ils ne fassent pas marche arrière.

Pour ceux qui cherchent une alternative très simpliste à Object.observe à base de getter/setters, voilà la mini-implémentation que j'utilise pour ObjectModel: https://gist.github.com/sylvainpolle...97adb063c53be7

Code:

---

1 2 3 4 5 6 7

var obj = { x:41, y: { z: [] } }; var observed = observe(obj, function(){ console.log([].join.call(arguments, ' ; ')); });   observed.x++; // logs "set ; x ; 42" observed.y.z.push("toto"); // logs "splice ; y.z ; 0 ; 0 ; 1"

---

Citation:

---

Envoyé par frfancha

Je vois pas en quoi c'est pas plus mal.
Object.observe a toujours été la promesse "long term" d'angular qui allait résoudre les problèmes de performances inérant au dirty checking...
Alors on fait quoi maintenant?

---

Oui.
En fait on espère toujours une explication : pourquoi cet abandon ? Des soucis d'ordre technique ?

Bonjour

La mouvance Reactive Programming remonte aux années 90.
On a eu dans le passé des tentatives comme Reactive C ou Reactive C++

Mais si le modèle de programmation est en soit séduisant, on constate toujours qu'il est peu utilisé par les développeurs.
Le plus souvent des frameworks viennent encapsuler le modèle et du coup les développeurs ne l'utilisent qu'au travers du framework.

Une petite recherche de reactive programming donne suffisamment de réponses pour comprendre que le concept est toujours vivant.
Mais il s'agit d'une notion théorique suffisamment large pour englober beaucoup d'approches.
Alors qu'Oblect.observe proposait d'observer les changements d'état d'un objet, NRP propose des réseaux de processus qui réagissent entre eux.

pour JavaScript cet article liste quelques approches
http://blog.getsetbro.com/js/FB-reac...reactiveX.html

d'un point de vue plus théorique, l'INRIA a pas mal travaillé sur le sujet
http://www-sop.inria.fr/mimosa/rp/ge...ion/index.html

Il ressort de tout ça que bien que séduisant le modèle de la programmation réactive n'a pas abouti à une adhésion massive de certaines de ces approches pour amener à un consensus qui ouvre la porte à une généralisation.

Vu que EcmaScript est un langage interprété, une autre approche du développement n'est pas simple à mettre en oeuvre. il s'agit de la programmation orientée aspect POA

Dans cette approche, on se concentre sur divers aspects du produit qu'on va développer de façon séparée.
L’idée c'est qu'une même entité suivant le point de vue n'a pas besoin des mêmes méthodes et/ou données.
D'un point de vue du métier, un employé dans une application RH, n'est vraiment pas la même chose que le point de vue de l'exploitant de l'application.
Pour cela, l'AOP définit des greffons qui seront activés à certains moments dans le code décrit par les aspects. Pour y parvenir dans les langages compilés, on utilise un tissage qui va produire le code exécutable en assemblant tous les greffons.

Dans un langage interprété, il est difficile d'implémenter le tissage. Sauf si on possède un modèle de programmation réactive au niveau des procédures.
lorsqu'on écrit

Code:

---

1 2 3

after () : set() { Display.update(); }

---

cela signifie après l'exécution de la méthode set exécuter Display.update.
Cette simple formulation permet de comprendre qu'avec un événement (reactive programming) qui se produit aux "points de coupe" potentiels des fonctions. On peut facilement mettre en oeuvre une programmation par aspect.

On obtient de fait du code beaucoup plus propre.
l'exemple typique est la classe métier auquel on ajoute des greffons pour la persistance, d'autres pour la supervision, etc.

Inconvénient le code qui s'exécute pour une action est dispersé dans divers greffons.

A+JYT