> Interestingly, some commenters suggest that *not* extending the DOM
> will result in a faster framework, which I have to say feels
> somewhat counterintuitive; as Aaron points out, surely that would
> just slow non-IE browsers down, rather than speed up the framework
> generally.
Yeah, either we are missing something or nobody is testing this before
deciding that Frameworks 2.0 should wrap even when they could extend.
It's trivial to show that IE is approx 100% faster when you extend
Element.prototype than when you go through the (MooTools) wrapper. And
with IE, 100% is a lot. :)
When you go through the MooTools wrapper in generally well-performing
JS engines, you can *still* see that it is twice as fast to, say, call
a function on a prototype-extended element than to wrap the element
and call the same function. The numbers are all smaller, but the
difference is there.
Or else this is just being poorly communicated. Actually, I _know_ it
is in part being poorly communicated, since the notes in the original
article about host object behavior make as powerful an argument for
prototype extension as against it.
The author is trying to say that, because host objects such as the
ActiveX version of XHR are allowed per ES standard to barf on a basic
property [GET] even if the property appears to exist...
console.log ( new ActiveXObject("MSXML2.XMLHTTP").send )
-> "object does not support this property or method"
... that says something definitive about whether you should [a] extend
host objects with custom properties or [b] extend prototypes of host
objects.
First of all, I don't know if ANYBODY suggests extending the prototype
of ActiveXObjects would be anything but harmful. So it is a frankly
terrible example. But moreover, if you know that doing a built-in
[GET] on property `send` may behave badly on some Elements -- and
let's assume that you also can't depend on a custom getter to change
this -- but you do know that you can add your own `get` method in
modern browsers, either directly or via inheritance, and through
object/feature detection/whatever ensure that get('send') returns
consistent results across browsers, then the unpredictable support for
[GET] has just created a fine _justification_ for extension.
Of course, the [GET] quirkiness equally justifies having a generic
method, not stuck on any host objects or prototypes, into which you
pass the host object and the property you want and all the
case-switching and massaging happens in there. But then you factor in
performance, and having the method right on the object wins.
-- Sandy
--
To unsubscribe, reply using "remove me" as the subject.
