Go check out the release notes.

Related posts:

1. jQuery 1.4 Released
2. jQuery 1.3.1 Go For Launch
3. jQuery 1.4 Alpha 1 Released

View the release notes here: http://jquery14.com/day-01/jquery-14

Related posts:

1. jQuery 1.4.2 Released
2. jQuery 1.4 Alpha 1 Released
3. jQuery 1.4a2 (Alpha 2) Released

1.4 is slated for official launch on January 14th - how cute :)

Related posts:

1. jQuery 1.4 Alpha 1 Released
2. jQuery 1.3 Beta Testing
3. jQuery 1.4.2 Released

Most of the changes seem to revolve around heavy optimization of some core functionality. Installing this alpha and testing in live applications will help get this release out!

Related posts:

1. jQuery 1.4a2 (Alpha 2) Released
2. jQuery 1.4.2 Released
3. jQuery 1.4 Released

"Long polling" is the name used to describe a technique which:

• An AJAX request is made (utilizing a javascript framework such as jQuery)
• The server waits for the data requested to be available, loops, and sleeps (your server-side PHP script)
• This loop repeats after data is returned to the client and processed (usually in your AJAX request's onComplete callback function)

This essentially simulates a continuous real-time stream from the client to the server. It can be more efficient than a regular polling technique because of the reduction in HTTP requests. You're not asking over and over and over again for new data - you ask once and wait for an answer. In most cases this reduces the latency in which data becomes available to your application.

There are a variety of use cases in which this technique can be handy. At the top of the list are real-time web-based chat applications. Each client executes a long polling loop for chat and user events (sign on/sign off/new message). Meebo is perhaps the greatest example of this.

It's important to note some of the server side technical limitations of long polling. Because connections remain open for considerably longer time than a typical HTTP request/response cycle you want your web server to be able to handle a large number of simultaneous connections. Apache isn't the best candidate for this type of situation. nginx and lighttpd are two lightweight web servers built from the ground up to handle a high volume of simultaneous connections. Both support the FastCGI interface and as such can be configured to support PHP. Again, Meebo uses lighttpd.

For similar reasons - it's also a good idea to choose a different sub-domain to handle long polling traffic. Because of client side browser limitations you don't want long polling connections interfering with regular HTTP traffic delivering page and media resources for your application.

Implementation

jQuery makes implementation a breeze.

var lpOnComplete = function(response) {
	alert(response);
	// do more processing
	lpStart();
};

var lpStart = function() {
	$.post('/path/to/script', {}, lpOnComplete, 'json');
};

$(document).ready(lpStart);

Straightforward. When the document is ready the loop begins. Each iteration the returned data is processed and the loop is restarted.

On the server side - just like we discussed earlier:

$time = time();
while((time() - $time) < 30) {
	// query memcache, database, etc. for new data
	$data = $datasource->getLatest();

	// if we have new data return it
	if(!empty($data)) {
		echo json_encode($data);
		break;
	}

	usleep(25000);
}

Actually, a couple points of interest here. We don't actually loop infinitely server side. You may have noticed the logic for the while loop - if we've executed for more than 30 seconds we discontinue the loop and return nothing. This nearly eliminates the possibility of substantial memory leaks. Also, if we didn't put a cap on execution time we would need to print a "space" character and flush output buffers every iteration of the loop to keep PHP abreast to the status of this process/connection. Without output being sent PHP cannot determine if the connection was lost via connection_status() or connection_aborted(). As a result this could lead to a situation where there are an increasing number of "ghost" processes eating up server resources. Not good!

That pretty much sums it up! Not that difficult, right?

As always, questions/comments are welcome, hope this helps!

Related posts:

1. Real-time “AJAX” JavaScript Progress Bar
2. PHP Dynamic JavaScript SCRIPT Insertion for Embedding
3. PHP fast, large (megabyte), data transfer between sessions

function roundTo(number, to) {
	return Math.round(number * to) / to;
}

alert(roundTo(1532, 100)); // 1500
alert(roundTo(26, 10)); // 30

If you want to get fancy, you could also modify the Number prototype for a more "integrated" solution.

Number.prototype.roundTo = function(to) {
	return Math.round(this * to) / to;
}

Related posts:

1. JavaScript Event Handler
2. Real-time “AJAX” JavaScript Progress Bar
3. PHP jQuery AJAX Javascript Long Polling

I achieved this in my framework through, what I call, output format filters. Let's say you have an action "cloud" in a controller "markets". The URL to access this resource in its full glory would be:

http://www.domainname.com/markets/cloud

Pretty standard stuff. Let's say we want to offer an embeddable version of this resource. I can append an "output format filter" on this resource:

http://www.domainname.com/markets/cloud/embed

Alright, again, pretty standard stuff. How on earth does this relate to dynamic javascript SCRIPT insertion?

On the remote partner site, I ask them to place the following HTML fragment in the desired location they want the resource to appear:

<script language="javascript" type="text/javscript" src="http://www.domainname.com/markets/cloud/embed"></script>

One line of HTML.

How does this work under the hood? It simply takes the view's content and prepares it as a valid javascript document.write. It also specifies certain HTML headers, notably:

Content-Type: application/x-javascript

function prepJS($js)
{
	// prepare the output as valid javascript
	$js = str_replace("\\", "\\\\", $js);
	$js = preg_replace("/[\r\n]+/", '\n', $js);
	$js = str_replace('"', '\"', $js);
	$js = preg_replace("/<script/i", '<scr"+"ipt', $js);
	$js = preg_replace("/<\/script/i", '</scr"+"ipt', $js);

	return $js;
}

document.write("<?php echo prepJS($viewContent); ?>");

It should be fairly obvious what the function does. It escapes double quotes, adds slashes, and replaces newlines and carriage returns with their inline equivalent. Additionally and VERY important, it splits SCRIPT tag elements (if your view had inline SCRIPT's) into SCR"+"IPT so that the browser treats these as pure strings and doesn't cause JavaScript parsing errors.

What if the resource you are embedding depends upon the availability of certain JavaScript libraries or external source files? The first response usually is, myself included, to simply document.write more SCRIPT tags!

document.write("
<?php prepJS('<script type="text/javascript" language="javascript" src="http://www.domainname.com/path/to/jquery.js"></script>'); ?>
");
document.write("
<?php prepJS('<script type="text/javascript" language="javascript" src="http://www.domainname.com/path/to/morejs.js"></script>'); ?>
");
document.write("<?php echo prepJS($viewContent); ?>");

The problem is of course that in IE, there's no telling what order those SCRIPT tags will get executed. Furthermore, if your resource depends on them, they need to be executed before you document.write the content.

My solution to this problem was two-fold. For other reasons not worth going into here, it's generally a good idea to concatenate all your JavaScript source files into one larger file, minify (if desired), cache, and serve the result. Taking advantage of this we can reduce the above to a single additional SCRIPT insertion. Tack this snippet onto the end of that file:

if(typeof(embedReady) != 'undefined') {
	embedReady();
}

And we come up with this:

document.write("
<?php prepJS('<script type="text/javascript" language="javascript" src="http://www.domainname.com/path/to/cached_combined_js.js"></script>'); ?>
");
var embedReady = function() {
    document.write("<?php echo prepJS($viewContent); ?>");
}

Now we're only concerned with a single SCRIPT load. We've safely placed our document.write of content inside a function that's called at the end of our dependency SCRIPT. In an elegant, browser agnostic fashion our resource will have it's dependencies loaded before it executes.

Yay?

Related posts:

1. PHP jQuery AJAX Javascript Long Polling
2. Real-time “AJAX” JavaScript Progress Bar
3. JavaScript roundTo Nearest Thousandth, Hundredth, Tenth, *

I waited for the 1.3.1 release of jQuery to make sure all major bugs had been resolved (brand new selector engine). This weekend I decided to go for the upgrade. Flawless. Even the plugins all worked as expected.

Fantastic job.

Related posts:

1. jQuery 1.3 Beta Testing
2. jQuery 1.4.2 Released
3. jQuery 1.4 Alpha 1 Released

Major changes include:

• Selector Engine - The selector code has undergone a complete rewrite - it’s likely that some edge cases still exist here.
• DOM Manipulation (append/prepend/before/after) - This code has also undergone a large rewrite along with some of the logic for executing inline script elements.
• .offset() - Another method that has been completely rewritten.
• Event Namespaces - The logic for handling namespaced events has been completely rewritten.
• Event Triggering - When triggering an event the event now bubbles up the DOM - this is likely to cause some problems.

Go lend a hand!

Related posts:

1. Converting from Prototype to jQuery
2. jQuery 1.3.1 Go For Launch
3. jQuery 1.4.2 Released

Over the years of being a Prototype user I paid close attention to the many posts about why X is a better framework than Y. I had always planned on at least TRYING another framework at some point to see what all the fuss was about.

Initially what attracted me to jQuery was it's compactness. It doesn't have separately defined classes for each component, like Prototype. There's one point of entry and most everything revolves around DOM elements. There's no distinction between selecting a single or multiple DOM element(s) and, because jQuery only uses a selector syntax, you don't get confused whether the parameter passed is an ID, class, etc.

Furthermore, I never really liked having to use $ for single selection and $$ for multiple selections in Prototype. Relatively speaking, with jQuery I find that performing actions on multiple DOM elements is easier.

Chaining is really where jQuery shines. It reminds me of using the 'with' construct in Visual Basic back in the day. "This is the object that I want to perform actions on... do this, that, and this... thanks!".

However, unlike Prototype where one could test for the existence of an object by:

if($('objectID')) {
// do something
}

In jQuery it isn't quite so intuitive. Since all jQuery instances are collections of elements, you test for the existence of an element by checking its length property:

if(jQuery('#objectId').length == 1) {
// do something
}

In jQuery, binding to events is also very intuitive. Combined with the power of chaining adding event handling to multiple objects is ridiculously simple. And, because the code executed in your event callback has the context of the object that triggered the event, you can (more easily than bindAsEventListener in Prototype) just access the object within the callback via 'this'.

This brings me to one issue that did initially cause some conversion conflict. Prototype does a good job of automatically extending standard objects, objects returned, and parameters passed. With jQuery, you have to get used to 'get()'ing the root DOM element if you need to manipulate it and likewise, extending a root DOM element to a full fledged jQuery instance (such as 'jQuery(this)') if you want to manipulate it via jQuery.

Another primary reason why I switched to jQuery is because it has built in support for basic animations. Transitional animations give that extra something to a web app. Having to hand-code them isn't pleasant. Obviously Prototype has scriptaculous, but thats a huge size (and therefor performance) commitment to make for just a simple fade, no?

jQuery was built to be extensible. It seems to me that Prototype intended to be the "be all, end all" solution to your JavaScript woes. jQuery takes a more sensible approach - it provides the fundamental structure and handles the most-desired scenarios. If there's something it doesn't do out of the box there's probably a plugin available that does. Most likely someone has come across the same shortcoming already and written a plugin to fulfill the need.

Some plugins I ended up needing immediately were:

• Date picker
• CSS Extraction from Ajax responses (IE issue)
• Ancestry (to mimic Prototype's descendantOf())
• DOM element creation (to mimic the functionality of Prototype's Element class)

I prefer to create DOM elements in JavaScript programatically without using HTML. jQuery doesn't have a built in solution for creating DOM elements like Prototype does with its Element class. Fortunately, Lukasz Rajchel has written the DOMEC (DOM Element Creation) plugin. It's lightweight and is a drop-in replacement for those familiar with the syntax of Prototype's Element.

During the conversion process I found it to be most helpful to load jQuery side by side with Prototype using jQuery's no-conflict functionality. As I slowly combed through my JavaScript removing Prototype dependencies I would periodically remove Prototype to see if and where I missed any outliers. This also requires you to use the jQuery() syntax as opposed to the traditional $() syntax. In doing so this helps easily identify where Prototype code remains.

How have your conversions to jQuery gone? Have you converted and never looked back? Your thoughts are appreciated...

Related posts:

1. jQuery 1.3 Beta Testing
2. JavaScript Event Handler
3. jQuery 1.4 Released