Using DOM API versus innerHTML to create/change content on webpage has been in discussion for years. The pain (slow DOM manipulation speed) left by Internet Explorer causes a big concern over DOM API for serious use in practice because the browser is still holding big slice of market share today (about 80%).

We can guess that the browser war (re)started by Firefox and stirred up by Google Chrome lately will result in better IE versions, yet that bright day won’t come any time soon.

Recently, I had reviews on PURE and Chain.js as client-side template engines. Though both libraries take pure, unobtrusive JavaScript approach for implementation, PURE seems more eager about speed when using innerHTML to create elements while Chain.js depends on DOM API for more flexible and direct manipulation.

I cannot say what approach is better. PURE may have some advantage on page with huge number of DOM elements to be created/changed but I think most of projects will be happy with Chain.js for its power. It grows a question: any chance that we can achieve both flexibility and speed in these libs? Probably, LightningDOM donated by Peter Rust will be a right answer.

In the post, Peter places LightningDOM as “a layer between the raw HTML and your templating/data-mapping code, without the slowness of the DOM.” So how it works? Just see the example.

1
2
3
4

var strMarkup = document.getElementById('destination').innerHTML;
var dom = new LightningDOM(strMarkup);
dom.firstChild().innerText("I Love speed!");
document.getElementById('destination').innerHTML = dom.outerHTML();

Not too difficult to understand, right? You give all HTML markups to LightningDOM, do anything you want with familiar getters/setters like you can do with DOM API then assign the result back to real DOM’s innerHTML.

Peter tells more about internal implementation to get both speed and lightness in the library.

The LightningDOM parses the given HTML using Regexes. I have two different parse algorithms (but both using the same regex). IE is much faster at parsing the whole markup by doing a single regex replace to convert the markup into JSON and then to eval the JSON. FF (and I’m guessing Chrome & Opera) is much faster at looping through the markup with a global regex.

All the tags are parsed into a two-dimensional array (well, technically an array of arrays), which represents all the information in the tags. Here’s a pretty look at the internal data structure representing a chunk of HMTL (note that we use a simpler object model inspired by ElementTree to representing the inner-text as a “tail” of the previous tag, rather than a nested “Text Node”).

Array of Arrays (_aMarkup):

Of course, the decision to utilize LightningDOM for PURE or Chain.js depends on leaders of projects but it does not prevent you from taking advantage of the lib if you see true value from it. Personally, I think it’s a good solution though I’ll have more tests/benchmarks to evaluate its stability across browsers.

In previous post, I had a chance to introduce Chain.js with 3 examples and found a few issues due to both bugs in version 0.1 and my unawareness of implemented features. Now version 0.2 of Chain.js has just come out, I’d like to revise the examples to show better implementation we can do with the library in practice.

Basically, we don’t need to call chain() function every time we add or replace items instead just execute it once on DOM ready event, and we can utilize anchor property to define where items to be rendered within table tag.

Example 1: All codes to get it works are here.

1
2
3
4
5
6
7
8
9
10
11
12
13

function render(){
	$.getJSON('json.php', 'lang=' + $('#langList').val(), function(books){
		$('#table_book').items('replace', books);
	});
}
 
$(document).ready(function(){
	$('#table_book').chain({
		anchor: 'tbody' /* defines, where items will be rendered*/
	});
	$('#langList').change(render); 	// handle change event of drop-down list
	setTimeout(render, 100); 		// call render function on load
});

Example 2: Almost the same codes as example 1 plus add, remove and sort functions.

Probably the biggest change in Zend Framework (ZF) 1.6 is about Ajax support with integration of famous Dojo JavaScript toolkit. ZF 1.6 comes with several new helpers, elements and components that help to display/interact with Dojo widgets as announced on Zend’s official site.

• A dojo() placeholder view helper to facilitate Dojo integration in your views, including setting up the required script and style tags, dojo.require statements, and more. In essence, this supports and enhances Dojo’s modularity at the application level.
• Zend_View helpers and Zend_Form elements and decorators that utilize Dijit, Dojo’s layout and widget platform. This simplifies creation of Zend_Form elements that can be rendered as Dijits. For instance, highly interactive widgets such as calendar choosers, time selectors, and combo-boxes are provided.
• Zend_Dojo_Data, a component for creating dojo.data-compatible response payloads. dojo.data defines a standard storage interface; services providing data in this format can then be consumed by a variety of Dojo facilities to provide highly flexible and dynamic content for your user interfaces.
• A JSON-RPC server component: Zend_Json_Server. JSON-RPC is a lightweight remote procedure call protocol, utilizing JSON for its serialization format; it is useful for sites that require a high volume of interaction between the user interface and server-side data stores, as it allows exposing your server-side APIs in a format directly accessible via your client. Dojo has native JSON-RPC capabilities, and Zend Framework provides a JSON-RPC implementation that is both compatible with Dojo and the published specifications.

The negative side of having a new (and promisingly become popular) browser, no matter how good it can be, is you’ll have to test your web apps with it among many others.

Probably, the first step is to detect the browser from JavaScript code by parsing browser’s user agent, and here is what of Google Chrome.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)
AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13

I guess old JavaScript codes can mistakenly tell it Safari like when running the code snippet below using JQuery’s browser utility.

1
2
3
4

$.each($.browser, function(i, val) {
	 $("<div>" + i + " : <span>" + val + "</span></div>")
		.appendTo(document.body);
});

It may be no problem until you find something wrong when your apps running on Chrome only. So, here is the code line to detect Chrome generally:

1

var is_chrome = /chrome/.test( navigator.userAgent.toLowerCase() );

We’ll have to change the JQuery browser utility to support Chrome detection as follows:

1
2
3
4
5
6
7
8
9
10
11

var userAgent = navigator.userAgent.toLowerCase();
 
// Figure out what browser is being used
jQuery.browser = {
	version: (userAgent.match( /.+(?:rv|it|ra|ie|me)[\/: ]([\d.]+)/ ) || [])[1],
	chrome: /chrome/.test( userAgent ),
	safari: /webkit/.test( userAgent ) && !/chrome/.test( userAgent ),
	opera: /opera/.test( userAgent ),
	msie: /msie/.test( userAgent ) && !/opera/.test( userAgent ),
	mozilla: /mozilla/.test( userAgent ) && !/(compatible|webkit)/.test( userAgent )
};

Now, correct result shows on test screen:

Just one notice: Current version of JQuery (1.2.6) is treating Chrome as if it was Safari and basically no serious problem has been found yet. Modifying browser detection can cause the lib render pages/elements incorrectly for it has no knowledge of Chrome’s rendering engine. To keep compatibility, you can change line 7 back to:

7

	safari: /webkit/.test( userAgent ),

In modern web development, some JavaScript frameworks have made their names like Prototype, Mootools, YUI, JQuery. But if you find them not wholly suitable to your next project there are some other good frameworks out there.

Jacob Gube has given out a nice introduction of “10 alternative and capable JavaScript frameworks/libraries to explore” going over the good of them. Here they are:

1. SproutCore
2. Spry
3. JavaScriptMVC
4. qooxdoo
5. midori
6. Archetype JavaScript Framework
7. June Framework
8. UIZE
9. SimpleJS
10. Fleegix.js

Some of them provide comprehensive solutions that allow you to build a (complicated) desktop-like application with ready-made components (SproutCore, Spry, qooxdoo, UIZE), other focus on DOM selector and effects with minimal weight and, specifically, framework JavaScriptMVC presents the Model-View-Controller (MVC) architectural pattern to JavaScript.

How well JavaScript works is what I highly concern about Google Chrome — the browser on headlines of all tech news today.

The JavaScript engine embedded in Chrome, named V8, is developed by Google which implements ECMAScript 3 and can run standalone as stated on project website.

• V8 is Google’s open source JavaScript engine.
• V8 is written in C++ and is used in Google Chrome, the open source browser from Google.
• V8 implements ECMAScript as specified in ECMA-262, 3rd edition, and runs on Windows XP and Vista, Mac OS X 10.5 (Leopard), and Linux systems that use IA-32 or ARM processors.
• V8 can run standalone, or can be embedded into any C++ application.

Of course, we’ll have to mention the tests given out by Google itself that show JavaScript speed in Chrome  many times faster than in all other major browsers: IE, Firefox and Safari.

Google Chrome Benchmarks

Anyway, they are tests guided by Google and I suspect that they seem be optimized toward the best of V8. So, the better way to see how good V8 perform in action is to run tests with popular JavaScript libraries like JQuery, Prototype, Dojo, Mootools, YUI which are being used in most of web applications in real world.

In a typical web application, JavaScript is mainly used for DOM selection/ manipulation rather than for heavy calculation. That’s why all libraries try to optimize DOM selection speed for (said) faster application.

To have practical view, I decided to run Mootools’ SlickSpeed tests on Google Chrome 0.2 in comparison with Firefox 3.0.1, Safari 3.1 (Windows), IE6, Opera 9.5 and especially on the nightly build of Firefox 3.1b1pre with Tracemonkey — Mozilla’s recent effort to integrate Tamarin tracing into the existing SpiderMonkey JavaScript engine — enabled and disabled. Here are the results:

Chart: Mootools SlickSpeed Test Results

SlickSpeed Benchmarks in details

(All tests were run 10 times for each browser on Windows XP SP3, AMD x64 4400+ with 2GB RAM machine)

It turns out that Google Chrome reached 6th place ahead the poor IE6 only, 49% slower than the fastest browser: Opera 9.5. Firefox 3.1 has not proved faster than the previous version in the tests, even enabling JIT engine made the results worse. (I acknowledge that it’s just pre-release beta version and Tracemonkey is not designed for optimizing DOM manipulation).

Some other conclusions we can get out from the above results (ruling out IE6 which falls far behind others in all tests) are:

The redesign of JQuery DOT COM site recently gained a huge amount of comments; unfortunately most of them were not positive. Developers who have come along with the library feel unhappy with new slogan “Be a Javascript Rockstar” that, said, makes them look unprofessional.

Response to a post on Ajaxian, shypht commented:

Hate to say it, but image is everything. If I was trying to sell my manager on using jQuery, Prototype, Mootools or Dojo, and sent them to those sites, I think based on look alone jQuery would be at a disadvantage. “Write less, do more” is a great slogan, “Be a Javascript Rockstar”, not so much.

Strikes me as being an amateur, and more focused on flashy effects than functionality. I love jQuery, it’s helped me loads on my most recent project, but that header just makes me cringe a bit on the inside when I see it.

While Glen Lipka described his feeling in more colorful words on his blog post:

Truthfully, I feel alienated by it.  It doesn’t resonate with me.  It makes me feel old and lame.  My hair is not long and flowing. The rockstar isn’t me.  jQuery is me.  It’s different.

Obviously John Resig & team did listen to the community and decided to kill the “JavaScript RockStar” on JQuery site.

If you are web developer you may have noticed that the latest version of Yahoo’s User Interface toolset and widgets (for web development), YUI 3.0, is now available as a preview release. YUI has long been a popular “Ajax” library both because of its liberal BSD license, and because of the number of features it provides.

The big news about YUI the third are that it changes from the root and (unfortunately) is not compatible with YUI 2.x APIs as Eric and Matt stated on developer blog.

YUI 3.0 builds off of the YUI 2.x codeline, but we’ve evolved most of the core APIs in working toward the five key goals described above. As a result, migrating from YUI 2.x to 3.x will require effort at the implementation level.

However, YUI 3.0 will ship with a limited compatibility layer for the current YUI Core that will allow you to run some of your YUI 2.x-based implementations (Yahoo Global Object, Dom Collection, and Event Utility) on top of YUI 3.0.

These radical changes are toward 5 goals:

• Lighter (less K-weight on the wire and on the page for most uses)
• faster (fewer http requests, less code to write and compile, more efficient code)
• more consistent (common naming, event signatures, and widget APIs throughout the library)
• more powerful (do more with less implementation code)
• more securable (safer and easier to expose to multiple developers working in the same environment; easier to run under systems like Caja or ADsafe)

Rizqi Ahmad from Germany has introduced a nice solution for client-side template based on JQuery. The Chain.js allows you to use any piece of HTML (or embedded HTML string) as template to display data dynamically.

In introductory post, he went through some common approach like server-side data binding, injecting preformatted HTML (into well-known DOM property innerHTML) and directly manipulating DOM, then explained why Chain.js is better way:

1. Easy and compact (as it uses JQuery for manipulating DOM)
2. Preserve event(s) on updates
3. Allow dynamically add/remove data

To use the engine, you’ll need to download JQuery (better the latest version) and Chain.js then add script tags to load them.

<script src="path/to/jquery.js" language="javascript"> </script>
<script src="path/to/chain.js" language="javascript"> </script>

Practical Example on Chain.js

Now, we’ll create a practical example that allows user select a programming language and display recommended reading books accordantly. This is almost similar to another example I created for PURE library.

First, build a template table to display book list:

Mozilla has just introduced a new JavaScript optimization feature to Firefox 3.1 development code base (Shiretoko) that well enhances JavaScript-based web apps performance by a 2x – 20x fold compared to the Firefox 3.0, according to JavaScript performance tests ran and published by Mozilla’s Brendan Eich.

I’m extremely pleased to announce the launch of TraceMonkey, an evolution of Firefox’s SpiderMonkey JavaScript engine for Firefox 3.1 that uses a new kind of Just-In-Time (JIT) compiler to boost JS performance by an order of magnitude or more.

Here are some of the charts from Brendan’s blog:

Assorted benchmarks

SunSpider micro-benchmarks

However the best way to evaluate it is to see it in action via simple JavaScript image editor that lets you adjust a picture’s contrast and brightness with a couple of sliders created by Mike Schroepfer. By default, TraceMonkey is disabled (as it is still buggy), there is a very noticeable delay while sliding. Turn it on (javascript.options.jit.content = true in about:config) and the thing works like charm, very smoothly.

JavaScript Image Editor

Going into significant detail on how all of this came about, Brendan notes some key points: