Why not NodeList#forEach :\?

Aymeric Vitte vitteaymeric at gmail.com
Tue Jun 19 09:46:41 PDT 2012


When I made that one : https://github.com/Ayms/node-dom it was supposed 
to be a fast and minimal implementation of the DOM, so it works in 
almost all real cases and do not crash in other situations.

The result is not bad but not as fast as expected neither minimal. Not 
minimal because I had to adapt to plenty of frameworks or sites's 
specific stuff but widely used. Not as fast as expected because I think 
property access is too slow (styles lookup for example for this project, 
it seems that the problem increases exponentially when trying to access 
undefined properties), I thought maybe it would be possible to implement 
virtual rendering but I had to surrender, no way today to do this in js 
I believe, it would be too slow, but maybe tomorrow if I read correctly 
this thread.

Regarding NodeLists, it's not an ES subject but I would say :

1- the "world" thinks it is an array
2- the "world" does not know it is updated dynamically (in an "ordered" 
way in addition ...)

As everybody I made my own NodeList (and other things such as 
CSSStyleDeclaration), not exactly w3c, which is to make it look like an 
array (like everybody again and future DOM specifications), so 1) is solved

But 2) (which is the dynamic "ordered" update of NodeLists) still 
continues to look useless to me and a huge handicap for performances, I 
suppose plenty of people will disagree, probably a question of 
experience, unlike jquery for example I never or rarely uses/used 
NodeLists and probably jquery users or just normal developers recall 
several time $('xx') or document.getElement(s)Byxxx, the question here 
has nothing to do with ES but is it really fundamental ?

Le 19/06/2012 17:37, Allen Wirfs-Brock a écrit :
> On Jun 19, 2012, at 5:29 AM, David Bruant wrote:
>
>> Le 19/06/2012 14:11, Alex Russell a écrit :
>>> ...
>>> is to give us a chance to fix this (among other) errors in DOM's design. Yes, it's up to DOM to fix it, but we need ES to adopt things like Allen's Object Model Reformation to help enable it:
>>>
>>> http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation
>> I guess knowing what the elem.find() API is will help me understand this part better, because I'm not sure I see the link between the object model reformulation and fixing the DOM API. Can you elaborate further on that? (if this discussion already happened somewhere else, a link to that discussion will be enough,  of course)
> Actual API "design" is probably an orthogonal issue.  What the "Object Model Reformation" proposal (which is probably better understood by its subtitle "Decoupling [ ] and Property Access") does is permit the existing behavior of DOM collections to be directly expressed in JavaScript without having having to resort to host object magic.  It supports the general principle of: If the DOM needs to do it then it should be doable in pure JavaScript.  There are lots of reasons why for some objects it makes sense for "indexed access" to have different semantics than "property access".  The DOM does this today. In an improved DOM API design it will probably also be the case.  The Object Model Reformation provides a semantic basis for designing such improved APIs rather than just making up host object magic that has no foundation in core JavaScript semantics.
>
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-- 
jCore
Email :  avitte at jcore.fr
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com



More information about the es-discuss mailing list