Experimental implementation of Object.observe & JS Utility library now available

Brendan Eich brendan at mozilla.org
Fri Aug 17 19:30:15 PDT 2012


Tab Atkins Jr. wrote:
> On Fri, Aug 17, 2012 at 6:49 PM, Brendan Eich<brendan at mozilla.org>  wrote:
>> All praise to Raf et al., my concern is that something synchronous, plus
>> event loop concurrency and setImmediate, would suffice to bootstrap the
>> rather more elaborate proposal on top of the simpler O.p.watch like
>> fundament.
>>
>> This is not to say we shouldn't standardize higher-level APIs, and instead
>> push that off on library authors to write, and users to download. There's a
>> delicate balance here. We often screw up higher-level abstractions in
>> annoying ways, but perhaps that risk is worth taking.
>>
>> What I'm really getting at is this: why not expose the synchronous primitive
>> and e.l.c. building blocks as well?
>
> For the same reason we're killing MutationEvents, rather than just
> promoting MutationObservers as a better alternative - synchronous
> change notifications slow things down considerably,

Rgr that.

The idea I am promoting is opposed by not only janky browser code (all 
browsers, some are better than others), but janky JS. Still, someone has 
to write the sync stubs and defer the real programmable work via an 
async API. Sounds like your argument is "let the experts [browser 
vendors] do the sync stubs."

>   and they're *very*
> prone to making the browser crashy. Get the slightest thing wrong in
> your implementation, and suddenly the user is holding onto a null
> pointer.

This you'll have to explain more. What pointer, to what point-ee? Why 
nulled?

/be


More information about the es-discuss mailing list