W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Custom element design with ES6 classes and Element constructors

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Wed, 14 Jan 2015 12:39:24 -0500
Message-ID: <54B6A9CC.9090800@mit.edu>
To: Dimitri Glazkov <dglazkov@google.com>
CC: public-webapps <public-webapps@w3.org>
On 1/14/15 11:52 AM, Dimitri Glazkov wrote:
> Would like to point out that we're not talking about a general case
> here. The actual proto munging in custom elements spec is minimized to a
> pretty small set.

Pretty small set of which?  Possible mutations, elements, something else.

> Given that most engines use lazily created wrappers

I don't think we should be designing around this.  I believe that this 
is a carryover from the way the engines were initially implemented in a 
C++-first manner.  As a a particular example, Servo doesn't even have a 
concept of "wrappers"; it just has a single memory area that is both the 
JS and Rust representation of the object involved.

> the actual setting
> of the prototype won't even need to happen unless the developer first
> accessed the element, thus creating a wrapper.

What that really means is that the performance cliff is randomly 
unpredictable, right?  That may or may not be better than always being slow.

> Also, the current design doesn't change the prototype chain arbitrarily:

This is the most important point.  It's possible engines could optimize 
such proto chain insertions better than they do now.  Some feedback from 
engine implementors on how feasible that is would be good to have.

> the effect is limited to inserting a sub-chain into the existing chain.

Is it, though?

I don't see that this is always true, though I would be fine with the 
cases in which it's not true falling off performance cliffs: those would 
only happen when proto chains get munged after element registration.

If we ignore those cases, it's possible JS engines could optimize this 
better than they do now.  JS engine implementor feedback would be pretty 
useful on this matter.

Received on Wednesday, 14 January 2015 17:39:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:43 UTC