Comet is not really brand-new (Ajax) term today; however, with most of people how it works remains somewhat mysterious.

I have a little hand-on experience with Comet when creating a hobby game project with DWR Reverse Ajax sometime ago. It (DWR) was simple to start and really worked but required a Java web server (Tomcat, Jetty…) that I found rather expensive (in term of resources) for such small application. I want a small, dedicated and reliable server for Comet apps while don’t like to be deeply sunk in technical terms like “Bayeux” or “Continuation”.

After reviewing the Comet Maturity Guide from Comet Daily I decided to give Meteor Comet server a try for several reasons, especially because it’s built on Perl that can be easily deployed in any server with Perl installed (i.e. almost all Linux servers, no?) and it should be lightweight (up to my experience with Perl). Here is other info about Meteor server:

1. Server daemon will run on any platform for which Perl is available.
2. In live use typically 1,000 clients per node receiving 2 msgs (~400 bytes) per sec each. Tested up to 5,000 clients per node receiving 1 msg/sec each.
3. Nodes exist independently, supports broadcasting for message distribution. Cluster of three Meteor nodes runs FT Alphaville.
4. Transports are completely configurable within simple constraints.
5. Server supports client ‘catch-up’, allowing clients to regulate quality of service themselves.
6. Stable, in production use.
7. GPL v2. Free.

Install & Setup Meteor Server

You can find very good how-to guide for installing Meteor server from Meteorserver.org; actually it’s quite simple to follow. Just download, extract to default location (/usr/local/meteor) and configure daemon service as guided. One notice is on Fedora/Cent OS the start function in init scripts must be changed from:

Read the rest of this entry »

Here are some quick and useful jQuery plugins from Jason Frame’s “jQuery Grab Bag“.

Auto-Grow TextArea

The technique is borrowed from Facebook that uses an off-screen <div> to calculate the required dimensions of the textarea to reveal all texts inside instead of to display vertical scrollbar. Run the following code line to enable auto-grow behavior to all textareas on page.

$('textarea').autogrow();

Online Demo

Input Hint

It’s not always necessary to attach label to every text field in web form, instead you can use hint to tell user what to type in the fields. This plugin will help keeping away from tedious codes to add hints to input boxes.

First, add hint attribute to input fields.

Read the rest of this entry »

There are many examples on creating tabbed navigation with (or without) help of JavaScript frameworks like Prototype, MooTools or JQuery. However, I find that it’s much easier to create draggable tabbed navigation using Chain.js and its great extension: Interaction.js.

Riziq, creator of Chain.js & Interaction.js, already showed an example on how to utilize the libs to build tab interface in a few JS code lines. However, for its own purpose, the example is not SEO-friendly — disabling JavaScript in your browser will result in empty content and search engines will see nothing on your page consequently. Now say, you want to create a tabbed navigation for your blog to show/hide “Latest Posts”, “Latest Comments” etc. and you want the links can be seen no matter if JavaScript is enabled or not in reader’s browser — something looks like this:

Blog's tabbed navigation

Step 1: HTML & CSS

Just create a template in HTML and full links to latest posts, comments and most popular articles:

Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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 ),

Read the rest of this entry »

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.

Read the rest of this entry »

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:

Read the rest of this entry »