Friday, 07 June 2013 at 09:25 am

I've been slowly working on my javascript library for visualizing bioinformatics data. I'v decided not to use too many external frameworks or libraries for two reasons: 1) It is a great learning opportunity for figuring out the nuts and bolts of how javascript runs on browsers. 2) There really aren't that many javascript frameworks designed to handle a lot of data simply because browsers were traditionally not seen as a platform for utilizing tons of data.

There are generally two camps among javascript framework developers for DOM creation and manipulation. One camp extends the DOM by using .prototype function, essentially defining new methods on native element/node objects. The other camp wraps the DOM by creating a new object which in itself, creates a native DOM element/node. All methods of the new object are then applied to the internal DOM element/node. 

I prefer wrapped DOM because it offers more flexibility in having private variables and let's me feel secure in not have collisions with native methods. However, the downside to wrapped DOM is the computational overhead that comes with creating every new DOM element/node. How much overhead is it really? 

I've setup a quick javascript benchmark where I compare native DOM creation vs wrapped DOM creation with varying prototype methods:

This test contains 6 cases where the first is native DOM creation with a simple document.createElement(). The other cases are wrapped DOM objects with 1, 5, 10, 15, and 100 prototyped methods. I expected the wrapped DOM to be more expensive than the native object. But do the addition of varying number of prototyped methods matter in object creation? 

I get non-consistent results on multiple runs of the test. At worst cases, I am getting around 30% of the performance when creating wrapped DOMs, on best cases, I am getting similar perforamce between native and wrapped DOMs. I am not exactly sure why. It might have something to do with the browser garbage collector as the node might be marked for collection after every iteration. read the update.

However, the differing numbers of prototyped methods doesn't seem to make much of a difference. In fact the object with 100 prototyped methods seemed to perform the best out of the wrapped DOMs in many cases. 

Even though a possible 75% 25% decrease in performance is quite a lot, that is still equivalent to 300,000 creations per second, which is probably more than enough for rendering application UI elements. The next step would be to see how wrapped SVG elements perform with native SVG elements....


I've updated the jsperf test to append the new node to the DOM after every creation to make sure it doesn't get collected by the garbage collector. After each case, the new nodes are removed for the next case. Now I seem to be getting more consistent results where wrapped DOM is around 75% of the performance of the native DOM at around 300,000 creations and additions a second.