Re: More Ideas around DOM Constructors

Thanks for your comments, Boris.  I understand your points about the
reflection cost and the document fragment and the apples and the oranges.

I was thinking that the actual DOM calling mechanism cost was not
insignificant, seems I was mistaken.  I probably also shouldn't have dragged
performance into the discussion in an attempt to bolster my proposal when I
know so little about that topic.

You mention it being easier to read, but I think it's just as important that
it's considerably easier to write.

One other thing: people are used to DOM1 and innerHTML.  I prefer to enhance
those techniques rather than inventing new ones to avoid confusion (why does
svg have a different way of creating elements from html?)  I see no benefit
to inventing Element.createElement when a new optional argument to
Document.createElement will do the exact same thing.  I also don't see a
strong need for inserting methods. That just bloats the API in my opinion
unless the intention there is to avoid the reflection cost you mentioned.

Jeff

On Nov 20, 2009 12:10 PM, "Boris Zbarsky" <bzbarsky@mit.edu> wrote:

On 11/20/09 12:17 PM, Jeff Schiller wrote: > > There are a variety of ways
that DOM elements can be ...
Just a a matter of record ... sort of.

Browsers have optimized _parsing_ for obvious reasons: it's used during
pageload.  And it allows some optimizations that DOM manipulation is not
really amenable to right now (e.g. in Gecko when parsing we know how many
attributes the element will end up before creating the element with so
preallocate the memory for them instead of having to realloc as needed on
each attr set).

But at least in Gecko one of the main reasons for the observed performance
difference is that the test is comparing apples and oranges.  Two obvious
instances of that for this test in Gecko:

1)  Insertion into the DOM.  The innerHTML test you link to
   inserts all the new nodes as a single DocumentFragment insertion
   in Gecko; the DOM test you link to does not.  The former is more
   efficient, since it allows coalescing of various work that needs
   to happen on insert.  If the DOM test used a document fragment,
   that would change the numbers somewhat.
2)  Which objects are being created.  In Gecko, the innerHTML test
   you link to creates a strign and a bunch of C++ DOM objects.
   The DOM test creates a bunch of C++ DOM objects and a bunch of
   reflections of these into JavaScript.  This last is a noticeable
   cost.  You can change the test to actually touch all the resulting
   objects in the innerHTML test to be closer to an apples-to-apples
   comparison, but it might be that you don't in fact care about
   those JS reflections; in that case the test is actually measuring
   what you want to measure.

Now obviously innerHTML has the extra overhead of parsing, so the comparison
will always be a little odd; you're trading off some types of extra work for
other types...

> createElement("circle", {cx: 40, cy:40, r:20, fill:"red"})
...

> > This reduces the number of DOM calls by N.
But increases the amount of work the createElement implementation has to do.
 It's not obvious to me where the performance tradeoff here would lie,
actually, even in Gecko.

I do think this API has one obvious thing to recommend itself, which is
being nicer to read than a bunch of setAttribute calls (plus maybe allowing
the attribute-count optimization I noted above, I guess).

-Boris