Comments on: LightningDOM to Balance DOM vs innerHTML

By: Jimmy Vu

Jimmy Vu — Sun, 14 Sep 2008 03:34:19 +0000

@Peter: Thanks for pointing out the typo.

I agree that DOM would be almost useless with “significant” number of elements, yet it’s still OK with less than 100 ones. I wish Rizqi will seriously consider LightningDOM for Chain.js or similar approach for better performance.

By: jonas

jonas — Fri, 12 Sep 2008 17:09:35 +0000

I take it this doesn’t fix IE bugs with .innerHTML though, as it still uses this to set the final result.

E.g. in IE you can’t set the innerHTML of a SELECT element, or TABLE, THEAD, TR etc.

Table issues
http://webbugtrack.blogspot.com/2007/12/bug-210-no-innerhtml-support-on-tables.html

and

Select issues
http://webbugtrack.blogspot.com/2007/08/bug-274-dom-methods-on-select-lists.html

IE also has issues with PRE elements and certain combos of CSS positioning.

I guess this is just a heads up to anyone unaware of these bugs)

By: The DOM is too slow for client-side page rendering « Cornerstone Blog

The DOM is too slow for client-side page rendering « Cornerstone Blog — Fri, 12 Sep 2008 17:08:47 +0000

[...] Jimmy Vu says that PURE (and LightningDOM, by extension) have an advantage when you have a “huge number of DOM elements to be created/changed” and he implies that this is uncommon. I think the appropriate word is “significant”. For a web app that uses client-side templating exclusively, this is standard — as it should be. Take a well-designed app like Basecamp. The average page has 50+ complex items displayed, each requiring a minimum of 3 HTML elements to represent them. [...]

By: Peter Rust

Peter Rust — Fri, 12 Sep 2008 15:41:30 +0000

Thanks for the post, Jimmy Vu!

One slight typo: I think you mean “guess” in the second paragraph, not “guest”.

Please let me know if you find any bugs or instability in your testing.