Re: [webkit-dev] JS bindings: Adding EventTarget to the prototype chain
Thread necromancy! To summarize the original post: Currently WebKit’s JS binding implements EventTarget as a mixin—all event targets have addEventListener, removeEventListener and dispatchEvent methods. I propose WebKit put EventTarget on the prototype chain. There were two basic questions in response: (1) Why? and (2) Where are the specs going? (1) Why? To summarize the rationale from off-list replies, spec mailing list threads, and webapps bug threads: Making event targets inherit from EventTarget simplifies hooking that functionality from a single choke-point. Otherwise, the web developer has to track down all those separate objects hook each one. Why is EventTarget special? What about other mixins? At the TC39 meeting in November, during a discussion about removing multiple inheritance, EventTarget was brought up as the mixin what would probably want to have global hooking done to it the most. (2) Where are the specs going? The momentum for specifying EventTarget as an interface is building. In my original post I noted that many specs (DOM Core, Notifications, Indexed DB, SVG, XHR) already specified EventTarget as an interface; now the specs Hixie edits (HTML5, Web RTC, Workers, Web Sockets) and FileReader do too. Furthermore, there’s a comment from Jonas Sicking http://www.w3.org/Bugs/Public/show_bug.cgi?id=12574#c3 indicating that Firefox is going to implement EventTarget this way, and from Travis Leithead http://www.w3.org/Bugs/Public/show_bug.cgi?id=12574#c15 endorsing implementing EventTarget this way. Which by my rough reckoning of specs implemented by WebKit, leaves just FileWriter and Web Audio. Both of those specs are in a funny place where they don’t specify EventTarget at all, but are event targets in WebKit. I will follow up with Eric Urhane and Chris Rogers about these. As I mentioned in my original post, the performance impact of this change is minimal. So now that the specs are lined up, are there any objections to making this change? If not I am going to work on reworking the prototype I used to measure performance into a proper patch. Dominic On Fri, Jun 10, 2011 at 7:53 AM, Maciej Stachowiak m...@apple.com wrote: I don't have a personal opinion on which way is technically better myself. But I think the key is getting our code aligned with where standards are going, wether by changing he code or the standards. EventTarget in the prototype chain seems neither especially awesome nor especially terrible to me, it is not really clear to me why editor's drafts of the listed specs decided to change. Cheers, Maciej On Jun 9, 2011, at 1:14 PM, Sam Weinig wrote: I don't think we should do this. EventTarget is really just an abstract interface, and changing its implementation globally is of limited utility. -Sam On Jun 8, 2011, at 5:54 PM, Dominic Cooney wrote: [If you don't care about JSC or V8 bindings you can safely ignore this.] TL;DR I want to change the JavaScript bindings to put EventTarget on the prototype chain so it is easier to work with event targets from JavaScript. What do you think? Here is the prototype chain for a button today: HTMLButtonElement-HTMLElement-Element-Node-Object (add/removeEventListener and dispatchEvent are on Node.) Here is how I think we should make it look: HTMLButtonElement-HTMLElement-Element-Node-EventTarget-Object (addEventListener etc. are on EventTarget.) Here’s why I think we should do this: - Specs are moving towards specifying EventTarget as living on the prototype chain. DOM Core*, Notifications, Indexed DB, SVG and XHR already do it this way. (* Editor’s draft.) - Frameworks that want to hook add/removeEventListener will be able to do it in one place: on EventTarget.prototype. In WebKit today they have to hook the prototypes of window, Node, XMLHttpRequest, etc. individually (Because WebKit implements EventTarget as a mixin everywhere, there are 20+ different kinds of event targets to hook if you want to be comprehensive.) If we make this change, it gets easier to tell if a given object is an EventTarget; just do EventTarget.prototype.isPrototypeOf(something). - It will modestly simplify WebKit’s IDLs and bindings. Instead of declaring addEventListener in two dozen places in IDLs, it will be in one place; instead of calling visitJSEventListeners in dozens of places for JSC GC, it will be called in one place; instead of assuming that EventTarget parameters are all Node* under the covers for V8 code generation, we can treat EventTargets uniformly; instead of redundantly specifying EventTarget on Document and Node inheritance will do what you want; etc. Will doing this break the web? I don’t think so: Anyone who calls or hooks addEventListener, etc. will continue to work, just their foo.addEventListener might be resolved at one level higher up the prototype chain than it is today. To really observe the different placement of addEventListener, etc. minutely you need to
Re: [webkit-dev] JS bindings: Adding EventTarget to the prototype chain
I don't think we should do this. EventTarget is really just an abstract
interface, and changing its implementation globally is of limited utility.
-Sam
On Jun 8, 2011, at 5:54 PM, Dominic Cooney wrote:
[If you don't care about JSC or V8 bindings you can safely ignore
this.]
TL;DR I want to change the JavaScript bindings to put EventTarget on
the prototype chain so it is easier to work with event targets from
JavaScript. What do you think?
Here is the prototype chain for a button today:
HTMLButtonElement-HTMLElement-Element-Node-Object
(add/removeEventListener and dispatchEvent are on Node.)
Here is how I think we should make it look:
HTMLButtonElement-HTMLElement-Element-Node-EventTarget-Object
(addEventListener etc. are on EventTarget.)
Here’s why I think we should do this:
- Specs are moving towards specifying EventTarget as living on the
prototype chain. DOM Core*, Notifications, Indexed DB, SVG and XHR
already do it this way. (* Editor’s draft.)
- Frameworks that want to hook add/removeEventListener will be able to
do it in one place: on EventTarget.prototype. In WebKit today they
have to hook the prototypes of window, Node, XMLHttpRequest, etc.
individually (Because WebKit implements EventTarget as a mixin
everywhere, there are 20+ different kinds of event targets to hook if
you want to be comprehensive.) If we make this change, it gets easier
to tell if a given object is an EventTarget; just do
EventTarget.prototype.isPrototypeOf(something).
- It will modestly simplify WebKit’s IDLs and bindings. Instead of
declaring addEventListener in two dozen places in IDLs, it will be in
one place; instead of calling visitJSEventListeners in dozens of
places for JSC GC, it will be called in one place; instead of assuming
that EventTarget parameters are all Node* under the covers for V8 code
generation, we can treat EventTargets uniformly; instead of
redundantly specifying EventTarget on Document and Node inheritance
will do what you want; etc.
Will doing this break the web? I don’t think so:
Anyone who calls or hooks addEventListener, etc. will continue to
work, just their foo.addEventListener might be resolved at one level
higher up the prototype chain than it is today. To really observe the
different placement of addEventListener, etc. minutely you need to
access __proto__ and hasOwnProperty. Other browsers are already differ
from WebKit in this regard, too: For example, Firefox reports
addEventListener is an own property on *every* step in the prototype
chain of DOM objects (until Object.)
Scripts that squirrel up the prototype chain themselves will see one
more link (EventTarget’s) but it is towards the top of the chain, past
most prototypes they care about (every prototype except Object.)
I tried changing half of the EventTargets in WebKit to put EventTarget
in the prototype chain, including Node and XHR (but not window) and
used it to surf the web for a few days. I didn’t notice anything break
:)
There is also the possibility that this could hurt performance,
because accessing addEventListener, etc. will have to search more
prototypes (usually just one more.) Accessing the properties of Object
on an event target via the prototype chain will have to squirrel
through one more prototype (EventTarget’s.) So I prototyped this
change in the JSC bindings and put EventTarget in the prototype chain
of a number of event targets in WebKit, including Node. Here are the
results for Dromaeo’s dom and jslib tests:
http://dromaeo.com/?id=141811,141813
(141811 on the left is the status quo.)
I expect the Prototype and jQuery events benchmarks are of particular
interest, and the result looks particularly bad for Prototype (~3%
slowdown). So I reran http://dromaeo.com/?event half a dozen times,
and couldn’t produce the poor result for Prototype; on average the
prototype was 1.0% slower for Prototype and 0.5% slower for jQuery. I
think Dromaeo is too noisy for measuring something as fine as this.
So I wrote three microbenchmarks:
1. Add/remove click listener on a button.
2. Add/remove progress listener on an XHR.
3. Test property presence with 'in':
if ('dispatchEvent' in target)
n++;
// return n outside of loop
where target is an XMLHttpRequest and n is a local var n = 0.
Here are the results. A brief note on methodology: release build
running in Mac Safari, JSC, averaging 500 samples with 1,000,000
iterations of the inner loop per sample.
1. Add/remove on button
Before (ms): min=409, median=434, mean=434.4, max=472
After (ms): min=410, median=453.5, mean=452.4, max=497 (mean is 1.04x)
2. Add/remove on XHR
Before (ms): min=286, median=298, mean=298.6, max=315
After (ms): min=287, median=300.5, mean=300.7, max=320 (mean is 1.01x)
3. 'dispatchEvent' in XHR
Before (ms): min=85, median=88, mean=87.7, max=91
After (ms): min=89, median=91, mean=91.0, max=95 (mean is 1.04x)
So this shows
Re: [webkit-dev] JS bindings: Adding EventTarget to the prototype chain
I don't have a personal opinion on which way is technically better myself. But
I think the key is getting our code aligned with where standards are going,
wether by changing he code or the standards. EventTarget in the prototype chain
seems neither especially awesome nor especially terrible to me, it is not
really clear to me why editor's drafts of the listed specs decided to change.
Cheers,
Maciej
On Jun 9, 2011, at 1:14 PM, Sam Weinig wrote:
I don't think we should do this. EventTarget is really just an abstract
interface, and changing its implementation globally is of limited utility.
-Sam
On Jun 8, 2011, at 5:54 PM, Dominic Cooney wrote:
[If you don't care about JSC or V8 bindings you can safely ignore
this.]
TL;DR I want to change the JavaScript bindings to put EventTarget on
the prototype chain so it is easier to work with event targets from
JavaScript. What do you think?
Here is the prototype chain for a button today:
HTMLButtonElement-HTMLElement-Element-Node-Object
(add/removeEventListener and dispatchEvent are on Node.)
Here is how I think we should make it look:
HTMLButtonElement-HTMLElement-Element-Node-EventTarget-Object
(addEventListener etc. are on EventTarget.)
Here’s why I think we should do this:
- Specs are moving towards specifying EventTarget as living on the
prototype chain. DOM Core*, Notifications, Indexed DB, SVG and XHR
already do it this way. (* Editor’s draft.)
- Frameworks that want to hook add/removeEventListener will be able to
do it in one place: on EventTarget.prototype. In WebKit today they
have to hook the prototypes of window, Node, XMLHttpRequest, etc.
individually (Because WebKit implements EventTarget as a mixin
everywhere, there are 20+ different kinds of event targets to hook if
you want to be comprehensive.) If we make this change, it gets easier
to tell if a given object is an EventTarget; just do
EventTarget.prototype.isPrototypeOf(something).
- It will modestly simplify WebKit’s IDLs and bindings. Instead of
declaring addEventListener in two dozen places in IDLs, it will be in
one place; instead of calling visitJSEventListeners in dozens of
places for JSC GC, it will be called in one place; instead of assuming
that EventTarget parameters are all Node* under the covers for V8 code
generation, we can treat EventTargets uniformly; instead of
redundantly specifying EventTarget on Document and Node inheritance
will do what you want; etc.
Will doing this break the web? I don’t think so:
Anyone who calls or hooks addEventListener, etc. will continue to
work, just their foo.addEventListener might be resolved at one level
higher up the prototype chain than it is today. To really observe the
different placement of addEventListener, etc. minutely you need to
access __proto__ and hasOwnProperty. Other browsers are already differ
from WebKit in this regard, too: For example, Firefox reports
addEventListener is an own property on *every* step in the prototype
chain of DOM objects (until Object.)
Scripts that squirrel up the prototype chain themselves will see one
more link (EventTarget’s) but it is towards the top of the chain, past
most prototypes they care about (every prototype except Object.)
I tried changing half of the EventTargets in WebKit to put EventTarget
in the prototype chain, including Node and XHR (but not window) and
used it to surf the web for a few days. I didn’t notice anything break
:)
There is also the possibility that this could hurt performance,
because accessing addEventListener, etc. will have to search more
prototypes (usually just one more.) Accessing the properties of Object
on an event target via the prototype chain will have to squirrel
through one more prototype (EventTarget’s.) So I prototyped this
change in the JSC bindings and put EventTarget in the prototype chain
of a number of event targets in WebKit, including Node. Here are the
results for Dromaeo’s dom and jslib tests:
http://dromaeo.com/?id=141811,141813
(141811 on the left is the status quo.)
I expect the Prototype and jQuery events benchmarks are of particular
interest, and the result looks particularly bad for Prototype (~3%
slowdown). So I reran http://dromaeo.com/?event half a dozen times,
and couldn’t produce the poor result for Prototype; on average the
prototype was 1.0% slower for Prototype and 0.5% slower for jQuery. I
think Dromaeo is too noisy for measuring something as fine as this.
So I wrote three microbenchmarks:
1. Add/remove click listener on a button.
2. Add/remove progress listener on an XHR.
3. Test property presence with 'in':
if ('dispatchEvent' in target)
n++;
// return n outside of loop
where target is an XMLHttpRequest and n is a local var n = 0.
Here are the results. A brief note on methodology: release build
running in Mac Safari, JSC, averaging 500 samples with 1,000,000
iterations of the inner loop per sample.
