Implement more performant solution for newest browsers

[paulirish]

Using Object.observe() will be far more performant vs the current watch techniques.

[melanke]

This method is from Ecmascript 6? I think you have a good point and we could check if the browser have it.

[richardanaya]

I like this idea!

[mreinstein]

It would be great to use the observe-shim internally in Watch.js: https://github.com/KapIT/observe-shim/

I think this would be great for a few reasons:

• we'd be using the proposed Object.observe interface as currently spec'd. Having a consistent API that follows the spec will help adoption.
• It'll enable the end user to choose if they want to use observe-shim directly, and handle their own object change notifications, or they can use Watch.js if they want something that attempts to do that for them (albeit less performantly)
• less code. Watch.js basically just maintains the logic that detects when the object changes, firing Object.getNotifier(myObject).notify({ type : "updated" , ....}); as needed.

Thoughts?

[melanke]

but the Object.observe interface dont have all options that Watch.JS provide. Watch.JS is extending the possibilities of Object.observe. It would be impossible to put all features of WatchJS in Object.observe interface

observe-shim do almost the same thing Watch.JS to provide Object.observe features, but Watch.JS give more options to observe. So, if you want only Object.observe you should use observe-shim, if you want all the features of Watch.JS forget about observe-shim

[mreinstein]

but the Object.observe interface dont have all options that Watch.JS provide

What I'd do is call them out very explicitly in the docs as "non-standard" extension. I know it's silly calling this a standard when it's really what amounts to an informal proposal at this point, but I think there's value in getting some commonality between what's in the proposal page, @KapIT 's object-observe shim, and Watch.js.

but Watch.JS give more options to observe.

They might make good additions to the existing proposal page: http://wiki.ecmascript.org/doku.php?id=harmony:observe

So, if you want only Object.observe you should use observe-shim

observe-shim does not actually fire change events; you have to do that manually. IMO the biggest value of Watch.js is that it attempts to do that. It would be really nice if I didn't have to choose between following the API that has the best chance of adoption right now (Object.observe) OR choosing an implementation that actually does "auto watching" (Watch.js)

[melanke]

Sorry, I am not fluent in english, let me know if I understand well

Object.observe is the actual draft for observe object changes

Watch.JS is a good implementation for observing in older browsers and for increasing the power, but it dont use Object.observe right now, but will use it in the future (it easy to implement, i am just lazy)

What object-shim have? Sorry, I dont understand why you might want to use it

[mreinstein]

Watch.JS is a good implementation for observing in older browsers ... but it dont use Object.observe right now

If you change the Watch.js API to match the Object.observe spec, it would make it a lot easier to implement the native fallback, which is what I think @paulirish is gettting at with this issue. This would make Watch.js a nice shim for Object.observe until browsers support improves (hopefully.)

[melanke]

I think what @paulirish was proposing is just to implement the new js feature that is much more performatic than Object.defineProp

Watch.JS will have the native fallback by itself, If you look in the code, it already have a fallback to different specs

I will try to implement it this week and you will decide if it is good enough ;)

[melanke]

what I could do is implement the callback with the same spec used in Object.observe

[mreinstein]

what I could do is implement the callback with the same spec used in Object.observe

Exactly what I mean. I suspect it might make the job of falling back to Object.observe easier too, because the API would match. I'd rather write

var obj = { a: 34 };
Object.observe(obj, function(records){ ...  });

rather than

var obj = { a: 34 };
watch(obj, "a", function(){ ... });

so that my code follows the spec, and the shim just fills the missing behavior the best it can.

[melanke]

okay then :D

sorry, I think I should practice more my english, I though you are saying about change Watch.JS to remove features of:

watch(obj, prop watch(obj, [prop1, prop2]

and stuff

[mreinstein]

I though you are saying about change Watch.JS to remove features of:

I definitely think those are valuable features to keep, especially given the performance impact of polling large objects.

sorry, I think I should practice more my english

No worries, your English seems good to me. : )

[melanke]

Thx

here is a preview: https://dl.dropboxusercontent.com/u/786375/github/Watch.JS/src/watch.js

I could not test it because I dont have canary, I will download it at home