"What’s wrong with extending the DOM", by kangax (Prototype)

[Pierre]

Hi,

what does the Mootools community think of that :
http://perfectionkills.com/whats-wrong-with-extending-the-dom/ ?

I personally love the way Mootools extends the DOM, it seems really
logical to me, but i don't know what to think after reading this
(performance issues).

Pierre

[Aaron Newton]

The article in question is a really good one and there are a lot of points made in it that hold water. The biggest issue is, of course, IE support, and thus far MooTools hasn't struggled too hard to maintain this. The key is that MooTools doesn't break the DOM by doing this - it fixes it!

But that said, there are some headaches involved in this practice and all I'll say is that MooTools 2.0 will likely have some changes to the way we interact with the DOM that will address many of these criticisms.

Aaron

--
To unsubscribe, reply using "remove me" as the subject.

[mooyah]

I for one request that MooTools implements the "wrapper" idea (in
version 2.0) rather than extending each element. I have noticed the
speed difference with MooTools JavaScript between Firefox (which I
use) and IE (which many users use). When these differences become
noticeable, I often rework the JavaScript to not extend the elements
or events in question using the MooTools extensions.

Obviously we shouldn't have to "work around" the JavaScript framework
integrated, it should provide ease of use in every situation.

-Joel

[Aaron Newton]

If we implement wrappers, it won't speed things up for IE, it'll slow down everything for the other browsers (that allow us to alter the Element prototype as we do currently). 

Obviously we shouldn't have to "work around" the JavaScript framework
integrated, it should provide ease of use in every situation.

That is always our goal. 

[Fábio M. Costa]

Mootools 1.3 will have a new selector engine (Slick) that provides a public API for selecting nodes, so it will be easy to select nodes without the need to extend them, as you need.

--
Fábio Miranda Costa
Solucione Sistemas
Engenheiro de interfaces

[Barry van Oudtshoorn]

Looks like this has made its way to the Ajaxian: http://ajaxian.com/archives/prototype-2-0-will-not-extend-the-dom .

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.

I'd be interested in some sort of "halfway" extension of elements in IE -- that is to say, using document.id() gets you some baseline functionality across all browsers (eg set(), get(), inject(), adopt(), etc), whilst document.uberID() gets you all of the functionality available. I find that there are a few extensions (such as inject()) that I use an awful lot, whilst others I use only rarely. What do you think? Is this a feasible "half-way" solution to the problem?

On 07/04/10 04:14, F�bio M. Costa wrote:

Mootools 1.3 will have a new selector engine (Slick) that provides a public API for selecting nodes, so it will be easy to select nodes without the need to extend them, as you need.

--

F�bio Miranda Costa

Solucione Sistemas
Engenheiro de interfaces

On Tue, Apr 6, 2010 at 4:43 PM, Aaron Newton <aa...@iminta.com> wrote:

If we implement wrappers, it won't speed things up for IE, it'll slow down everything for the other browsers (that allow us to alter the Element prototype as we do currently).�

Obviously we shouldn't have to "work around" the JavaScript framework
integrated, it should provide ease of use in every situation.

That is always our goal.�

-- 
Not sent from my Apple πPhone.

[Perrin Perrin]

Speed up IE when grabbing element for the first time with a $ type method in the sense that it won't need to copy Element.prototype props onto the element.  Possible slowdown in browsers at that same spot in the sense that an extra object will need to be created.

On Tue, Apr 6, 2010 at 7:28 PM, Barry van Oudtshoorn <bvanoud...@gmail.com> wrote:

Looks like this has made its way to the Ajaxian: http://ajaxian.com/archives/prototype-2-0-will-not-extend-the-dom .

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.

I'd be interested in some sort of "halfway" extension of elements in IE -- that is to say, using document.id() gets you some baseline functionality across all browsers (eg set(), get(), inject(), adopt(), etc), whilst document.uberID() gets you all of the functionality available. I find that there are a few extensions (such as inject()) that I use an awful lot, whilst others I use only rarely. What do you think? Is this a feasible "half-way" solution to the problem?

On 07/04/10 04:14, Fábio M. Costa wrote:

Mootools 1.3 will have a new selector engine (Slick) that provides a public API for selecting nodes, so it will be easy to select nodes without the need to extend them, as you need.

--

Fábio Miranda Costa

Solucione Sistemas
Engenheiro de interfaces

On Tue, Apr 6, 2010 at 4:43 PM, Aaron Newton <aa...@iminta.com> wrote:

If we implement wrappers, it won't speed things up for IE, it'll slow down everything for the other browsers (that allow us to alter the Element prototype as we do currently). 

Obviously we shouldn't have to "work around" the JavaScript framework
integrated, it should provide ease of use in every situation.

That is always our goal. 

[Sanford Whiteman]

> 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