Friday, 14 June 2013 at 10 am

Any developer that deals with a lot of javascript and CSS understands the pain involved in positioning an element exactly right on a page and also have it respond well to window resizes.

A common frustration is creating a "drop-up" menu where a selection menu is displayed above a button on user click. The height of the menu needs to be known to correctly position it above the button. If the menu is dynamically generated, then the height will possibly change everytime the user clicks the button.

The height of the menu can be obtained by getting the element's offset properties (offsetHeight, offsetWidth...). However these properties are only available if the element can be read by the browser screen reader. 

A common technique to hide an element while still making it available to the screen reader is to simply move it off the screen:

element.style.left = -10000;

Versus the CSS methodwhich will not make it available to the screen reader. 

element.style.display = 'none';

A good overview of various DOM hiding methods can be found here.

I don't really like the offscreen method as it is kind of a hack and I can envision a future scenario where new browser versions will ruin web apps that uses this method. However, this method seems to be the only effective way around this problem. 

Is there any performance difference between offscreen and CSS methods? I setup a jsperf test to find out:

http://jsperf.com/offscreen-vs-display-none

I created a new wrapped DOM class and prototyped hide() and offscreen() functions for the CSS and offscreen methods respectively. Then I created 100 wrapped DOM elements as the test setup. 

For the two test cases, I either used hide() or offscreen() on the 100 DOM elements. The offscreen() method performs slower than the hide() method by almost 74%. I expected it to be slower as offscreen elements are still being read by the screen reader, but 74% is a pretty large performance hit considering most modern web apps can easily have a few hundred elements.




  Friday, 07 June 2013 at 09 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:

http://jsperf.com/native-dom-versus-wrapped-dom

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....


update

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.




  Sunday, 01 April 2012 at 11 am

In part 1 of this series of post, I showed you how to graph a simple bar graph. In this post, I will show you how to use Chrome's developer tools to better debug your code. The javascript console in developer tools is an extremely powerful resource that allows you access to access and run javascript within the browser. You can even run all your code in the console to render a figure if you choose to. 

To turn on the developer tools in Chrome, click the wrench icon in the upper right hand corner of the browser window -> tools -> developer tools. Your browser will now have a new partition in the bottom showing the developer tools. The two most useful feature in the developer tools are the 'Elements' and 'Console' tabs.




  Thursday, 22 March 2012 at 2 pm

View the demo here
HTML source is at the bottom of the post

Computers and the internet have changed academia in dramatic ways from greater sharing of data to a larger sense of community. Science journals are now all digitized and available online either through your web browser or downloadble as a .pdf. 

Even with all the technology available for presenting data, most published papers still only contain static figures. I am not undervaluing the importance of having nicely formatted figures and graphs. But I do want to show how data can be presented with all the tools available now. 

Science papers are generally viewed on a computer through a web browser like Chrome, Firefox, or Safari which use javascript/html/css for displaying information. Therefore, browser languages are ideal for ensuring accessibility of your data. Javascript is often touted as the most prevalent programming language in the world since every computer has a browser and most browsers can interpret javascript.

Here are a bunch of examples of interactive figures made using browser technologies, specifically D3.js.







Search

Categories


Archive