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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web : www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
