Good news everybody! The dates and venue for this year’s jQuery Conference have been determined.

The conference will be held September 12th and 13th at Microsoft Cambridge in Boston, MA.

This will be a 2 day conference with multiple tracks on each day. We’re in the process of planning out the schedule, talking with speakers, and setting up the conference web site.

Watch the jQuery blog or jQuery Twitter feed for notification when registration opens.

While this venue is larger than those that we’ve had in the past (Harvard Law School in ‘07 and the MIT Stata Center in ‘08) we do expect to sell out all the available seats, as has happened every year so far. That being said, the venue is quite incredible, easily one of the best spaces available for a conference:

A brief synopsis of some of the content that you’ll be able to expect:

The annual conference of jQuery users and developers. There will be talks on jQuery, jQuery UI, plugins, complex application development, and more - all from the top jQuery developers. Case studies from some of the leading users of jQuery will be included along with a 3 hour tutorial for those just getting started.

You can see the schedules from past jQuery conferences here: 2008, 2007. There will be a nominal fee (likely around $100-$150) to help us cover to cost of food for both days and shirts.

Looking forward to seeing everyone in Boston this fall!

Note: If you are interested in sponsoring the conference, please contact John Resig.

Update: There have been a lot of questions asking if there will be a conference on the west coast (San Francisco) or in Europe. While we don’t have any immediate plans to hold conferences in those locations, this year, we would like to hold them in the future. In the meantime I recommend checking out Full Frontal (UK, November) and Fronteers (Amsterdam, November) - both of which should shape up to be excellent JavaScript conferences.

Update: Thanks to Jeff for adding the event to Upcoming.

Geoffrey continues his popular Sproutcasts with a new episode on properties, key-value coding and observers.  Check it out on Vimeo.

Also, if you want to be notified of the latest Sproutcasts when they first come available, follow @sproutcasts on Twitter.

One key element of the talk I give on SproutCore is talking about Cloud Applications vs Web Apps and Desktop Apps.  I’ve put some of this material on the wiki.  Check it out:

What is a Cloud Application »

The foundation of every great open source project is its community. The MooTools Team creates the base framework code but its all of you that take the framework and build outstanding plugins. Here are some great plugins that have been released recently.

Slideshow 2 by Aeron Glemann is an outstanding photo / slideshow plugin that offers a plethora of options and features — many more than you’d find with the average slideshow or lightbox. Slideshow 2 features Robert Penner easing transitions, photo delays, duration settings, the ability to make Slideshow 2 a lightbox, and an on-photo control panel.

http://www.electricprism.com/aeron/slideshow/

Created by MooTools Core Developer Christoph Pojer, MooTools FileManager is a MooTools-driven file manager that allows for drag and drop file management, Ajax directory loading, file content previews, and much more.

http://og5.net/christoph/article/MooTools_based_FileManager

Moousture is a MooTools Mouse Gesture library created by Zohaib Sibt-e-Hassan. Moousture allows you to create multiple geture patterns and assign them to any number of elements. http://neofreeman.freepgs.com/Moousture/

Fancy Upload 3 is the newest iteration of Harlad Kirschner’s popular Flash/MooTools upload tool. Fancy Upload 3 features file-specific options, an additional IFrame-based uploader, Flash 9 and 10 compatibility, and the same base features that made Fancy Upload a must-have plugin.

http://digitarald.de/project/fancyupload/

If you spend hours with MooTools and the Coda text editor, you’ll love the MooTools.Mode Syntax Mode add-in. This package created by José Prado is free and easy to install.

http://pradador.com/code/coda/moomode.html

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your future plugins in upcoming posts!

Since the dawn of time, MooTools used a method named $ to get an HTML element by it’s id or direct reference. This method name, being the coolest and shortest you can find in JavaScript, is also used by a number of other javascript frameworks and libraries for similar functionality. Now, we do not think including 2 libraries or frameworks is OK. It’s not. Never. It’s an overhead of duplication you do not want to have. However, you might not have the full control of the page in some circumstances, and we recognize that. That’s why we implemented this: Dollar Safe Mode™. It’s nothing special really, but it should help in those situations where including multiple libraries is not your choice (because if it is, quite frankly, you’re doing everything wrong. Pick one, will you? And make sure it’s MooTools :-)).

MooTools 1.2.3 DOM stuff doesn’t depend on the presence of $ anymore. The method that used to be $ is now called document.id (short for identify). The method $ is still assigned when not already present in the page, and aliased to document.id.

But let me show you how it works:

Let’s say you have mootools.js and a fictional JS library called jLib.js. Both use a method called $.

jLib would “steal” the $ method from MooTools. MooTools doesn’t work unless jLib has some sort of no-conflict mode of its own that will allow you to prevent it from “stealing” $ from MooTools.

MooTools would “steal” the $ method from jLib, which may or may not work without it.

Scenario 1: Include MooTools first:

MooTools checks if a method called $ exists; if not, it defines it. In this scenario, MooTools defines it as it doesn’t find anything named $, being included first. jLib “steals” the $ method from MooTools. MooTools doesn’t care. MooTools now doesnt need $ to properly function. You can regain control of $ simply by reassigning it to its alias ($ = document.id).

Scenario 2: Include jLib first:

MooTools checks if a method called $ exists. It does find it, being included last, therefore it doesn’t define it. You can directly use document.id() or assign your own var to it, or manually assign $ to document.id, if you would like MooTools to have control of it.

As you can see, it’s pretty straightforward. In short, MooTools doesn’t need $ to function anymore, and doesn’t steal it from other frameworks when included after them.

The above applies for MooTools-Core and MooTools-More. However, MooTools plugins use the $ method, therefore, while not breaking MooTools by including jLib, you will break the MooTools plugins. If you desperately need plugins to be multiple-framework compatible, and you the other frameworks to have control of $, there are a few things you can do.

The first, most obvious and recommended option is to replace every call to $() with document.id() by hand. It doesn’t take more than 10 seconds with a simple find and replace. This is probably what plugin authors should do, if they wish their plugin to be dollar-safe.

Another option is to encapsulate the plugin using a closure. This might come handy if you are processing a plugin that isn’t yours:

it should become:

As you can see, we’ve simply assigned $ as a local variable, using a closure. Everything in that closure will use document.id as its $ method. Remember to export the global variables though, as vars defined in the closure will stay private. I like to export globals using this., but you can use window. as well.

Please note that MooTools will probably remain incompatible with other frameworks that modify native prototypes, as there will probably be more name clashes. This isn’t a cross-framework compatible MooTools version by any means, nor does it want to be. The whole point is not to “steal” the dollar function from other libraries.

And that’s pretty much it about the Dollar Safe Mode™ in MooTools 1.2.3.

I’ll be giving a talk and possibly on a panel or two at AJAXWorld in NYC on Tuesday.  My session is at 5:15.  Don’t miss it!  It’s going to rock.

If you are in NYC and want to meetup give me a shout out on twitter (@okito) or email (charles @ sproutit.com)

SproutCore Session at AJAXWorld »

Today we give you what will likely be the final release of the MooTools Core before the jump to 2.0. While MooTools 1.2.3 is primarily a bug-fixing release, MooTools 1.2.3 also introduces an important new feature: Framework compatibility mode.

The value in making this change is allowing developers to use more than one framework within a page (which is NOT something we recommend or endorse, but we recognize this is not always under the developer’s control). Not relying on the dollar function prevents the need for jQuery.noConflict() when using jQuery and MooTools together, for example. If no other framework is detected, however, $ will be assigned to MooTools. This means that all of your current MooTools code WILL NOT break. It does, however, mean that if you want to use MooTools and jQuery together (without using jQuery’s noConflict mode), instead of using $ in your MooTools code, you’ll have to use document.id().

If you want your MooTools plugins to be cross-framework compatible, you’ll have to replace all the instances of $ with document.id().This change only applies if you’re using more than one framework on your pages. If all you use is MooTools, nothing will change for you. Look forward to more details about Framework compatibility mode in a future post.

While we encourage you to browse LightHouse and the histories for MooTools Core and MooTools More to get the most detailed list of changes, the following significant updates were committed in MooTools 1.2.3:

• Element: MooTools compatibility mode: the $ function is only defined if no pre-existing $ function is found. If an existing $ function is found, you can use document.id()
• Element: changed internal instances of $ to document.id
• Core: fix for server-side MS JScript 5.x; makes MooTools more friendly for server side programming
• Class: Class doesn’t require Browser, removed from scripts.json
• Element: Fixes for set/get Property
• Element.Dimensions: fix for webkit body.scrollTop inconsistency, getBoundingClientRect used whenever possible (not just for Trident), renaming element.position to element.setPosition; adding docs for the method; alias is included in-line for compatibility
• Hash: Hash extend no longer uses the window if no arguments supplied
• Request: clearing Request readystate before calling success or failure;
• Selectors: Added :enabled pseudoselector, was in the Docs but not implemented.
• Docs: Fixed docs headers for first-child, last-child, and only-child.
• Internal: UnitTester test suite is now a git submodule
• Numerous small fixes, speed improvements, documentation tweaks, etc.

• Per the change in -core, $ is no longer used (uses document.id instead)
• Element.Measure: trying cssText solution for Element.expose (again).
• Element.Forms: swapping feature detection for browser support per
• Date: Massive refactoring of Date.js and Date.Extras.js
• Drag.Move: Fixing drag with grid issues
• IframeShim: altering zindex assignment in IframeShim to better ensure that it’s always underneath the shimmed element, updating Iframeshim’s empty document creation; fixes https issues in IE6
• FormValidator: reworking formvalidator scroll-to logic to be a little more efficient
• OverText: preventing overtext from focusing on inputs except when they are interacted with (so OverText.update() does not focus an input);now stops polling when elements are hidden (when polling is enabled)
• Fx.Scroll: adding scrollIntoView method - scrolls an element so that it is completely visible; if below the view, scrolls down until it is at the bottom of the screen, if above, scrolls up until it is at the top.
• JSONP: was calling (the deprecated) this.request instead of this.send during retries
• URI: Adding set(‘data’, obj) to set
• Assets: adding error callback for Assets.images
• Tips: removing dependency for Element.Measure for Tips; updating CSS class name in OverText
• Numerous small fixes, speed improvements, documentation tweaks, etc.

As mentioned above, 1.2.3 is likely the last update for MooTools 1.2. MooTools 2.0 will introduce numerous performance improvements and new features. We want to stress that MooTools 2.0 will feature 100% compatibility with MooTools 1.2.x.

Thank you for the bug fixes, feature requests, and support during MooTools’ 1.* lifetime. You, the MooTools community, have helped make this framework better with every bug found and question asked on the forum. We look forward to releasing MooTools 2.0 this summer and getting feedback from everyone in this awesome community.

By default we should always favour asynchronous XHR to help the responsiveness of our Web applications. However, have you ever wanted a way to serialize your XHR calls because you needed to do things in sequence as B relied on what came back from A?

You could call a synchronous Ajax call, but that locks up the browser. Thibaud Lopez Schneider has written up his thoughts here showing the difference between synchronous Ajax:

and async calls with magic to serialize them:

He then went and created a simple example code generator at asynchronous.me. It is interesting to look at the code of the serialized version, and see that it doesn't do anything complex.... just passes in the next function to run as a callback:

1.  
2. function run() { 
3.     request1(function () { 
4.         request2(function () { 
5.             request3(function () { 
6.                 done(); 
7.             }); 
8.         }); 
9.     }); 
10. } 
11. function request1(callback1) { 
12.     // request 1 
13.     print("request1"); 
14.     var xmlHttpRequest1 = new XMLHttpRequest(); 
15.     xmlHttpRequest1.open("GET", "something1?hello1", true); 
16.     xmlHttpRequest1.onreadystatechange = function () { 
17.         if (this.readyState == 4 && this.status == 200) { 
18.             // response 1 
19.             print("response1=" + this.responseText); 
20.             // continue execution in the callback 
21.             if (callback1) { 
22.                 callback1(); 
23.             } 
24.         } 
25.     }; 
26.     xmlHttpRequest1.send(); 
27. } 
28. function request2(callback2) { 
29.     // request 2 
30.     print("request2"); 
31.     var xmlHttpRequest2 = new XMLHttpRequest(); 
32.     xmlHttpRequest2.open("GET", "something2?hello2", true); 
33.     xmlHttpRequest2.onreadystatechange = function () { 
34.         if (this.readyState == 4 && this.status == 200) { 
35.             // response 2 
36.             print("response2=" + this.responseText); 
37.             // continue execution in the callback 
38.             if (callback2) { 
39.                 callback2(); 
40.             } 
41.         } 
42.     }; 
43.     xmlHttpRequest2.send(); 
44. } 
45. function request3(callback3) { 
46.     // request 3 
47.     print("request3"); 
48.     var xmlHttpRequest3 = new XMLHttpRequest(); 
49.     xmlHttpRequest3.open("GET", "something3?hello3", true); 
50.     xmlHttpRequest3.onreadystatechange = function () { 
51.         if (this.readyState == 4 && this.status == 200) { 
52.             // response 3 
53.             print("response3=" + this.responseText); 
54.             // continue execution in the callback 
55.             if (callback3) { 
56.                 callback3(); 
57.             } 
58.         } 
59.     }; 
60.     xmlHttpRequest3.send(); 
61. } 
62. function done() { 
63.     // end 
64.     print("done"); 
65. }
66.  

You can compare that approach to basehttp://feeds.feedburner.com/ajaxian
[Dojo Front Page JavaScript ]
Javascript libraries for web development
View original post|Add to del.icio.us | Share

There are some good engineers working to make IE a better browser. I don't want to belittle their work, but I couldn't let go the recent work of various marketing groups this week.

First up, we had the the chaps from down under try to buy downloads with 10 grand, ripping into other browsers along the way.... as they use all images and no type in their lovely page. I have found Aussies to be a hilarious bunch, but not so much this time? I can see how the idea would seem good in a meeting room.....

Michael Yoshitaka Erlewine quickly realised that tengrandisburiedthere.com wasn't taken so built his fun retort for the Mozilla community.

Then we had the new "get the facts" campaign that showed an angry "we don't suck like you think" angle:

Lately, there's been a lot of talk about Internet Explorer's speed, security, and adaptability. But many of the claims are comparing older versions of Internet Explorer to competitors' newest releases.

These pages somehow manage to claim that IE is more secure, is the only browser with privacy features, is the easiest browser to use, has great Web standards support, fantastic developer tools, is more reliable, and customizable, and on and on. They even use their monopoly baggage to claim that all of those annoying "built for IE" pages of the past make IE more "compatible". Oh, and obviously the performance of IE 8 is vastly superior to other browsers. Sure the "benchmarks" don't tell that story, but that isn't what matters. Of course, anyone who has USED THE DARN BROWSERS can get a decent feeling on performance.

IE 8 is a decent browser, much better than IE 7 and before it. However, it drives me nuts to see the marketing spin and bare face lies that come across here. It denigrates the work that the engineers are doing.

To finish up, I feel like I have to end with the third piece on IE this week:

Robert Nyman has setup a really nice test suite for JavaScript 1.6, 1.7, and 1.8+ features such as getters/setters, Object.defineProperty, Object.getPrototypeOf, new String extras, and JSON.

It includes compatibility tables, and will try to run the tests on your browser to give you feedback. It also includes sample code to check web browser support that you can use in your own projects.

• Introduction to the tests
• Demos of getter and setters in JavaScript
• JavaScript 1.8.1 tests
• Native JSON tests

Nice job Robert!

The intrepid JS hacker Juriy "kangax" Zaytsev has an incredibly detailed post on demystifying named function expressions:

Surprisingly, a topic of named function expressions doesn’t seem to be covered well enough on the web. This is probably why there are so many misconceptions floating around. In this article, I’ll try to summarize both - theoretical and practical aspects of these wonderful Javascript constructs; the good, bad and ugly parts of them.

In a nutshell, named function expressions are useful for one thing only - descriptive function names in debuggers and profilers. Well, there is also a possibility of using function names for recursion, but you will soon see that this is often impractical nowadays. If you don’t care about debugging experience, you have nothing to worry about. Otherwise, read on to see some of the cross-browser glitches you would have to deal with and tips on how work around them.

He then goes into a ton of examples of weirdness in different browsers, and fun code like this:

1.  
2.     var f = function g() {
3.         return 1;
4.     };
5.     if (false) {
6.         f = function g(){
7.             return 2;
8.         }
9.     };
10.     g(); // 2
11.  

and

1.  
2.   var f = function g(){
3.     return [
4.       arguments.callee == f,
5.       arguments.callee == g
6.     ];
7.   };
8.   f(); // [true, false]
9.  

Finally, he shows a couple of techniques for using these correctly in the real world need of shimming:

1.  
2. // 1) enclose declaration with a separate scope
3.   var addEvent = (function(){
4.  
5.     var docEl = document.documentElement;
6.  
7.     // 2) declare a variable to assign function to
8.     var fn;
9.  
10.     if (docEl.addEventListener) {
11.  
12.       // 3) make sure to give function a descriptive identifier
13.       fn = function addEvent(element, eventName, callback) {
14.         element.addEventListener(eventName, callback, false);
15.       }
16.     }
17.     else if (docEl.attachEvent) {
18.       fn = function addEvent(element, eventName, callback) {
19.         element.attachEvent('on' + eventName, callback);
20.       }
21.     }
22.     else {
23.       fn = function addEvent(element, eventName, callback) {
24.         element['on' + eventName] = callback;
25.       }
26.     }
27.  
28.     // 4) clean up `addEvent` function created by JScript
29.     //    make sure to either prepend assignment with `var`,
30.     //    or declare `addEvent` at the top of the function
31.     var addEvent = null;
32.  
33.     // 5) finally return function referenced by `fn`
34.     return fn;
35.   })();
36.  

 "When the heck are you guys going to open registration for The Ajax Experience this year!?"

Over the last 3 months that is, without question, the most frequently received email we've had from Ajaxian members like you. The good news is that the wait is finally over! Registration has officially opened for this year's Ajax Experience conference and best of all, we're offering you $300 off when you register by July 31st. Check out our just-launched Web site right here for all the benefits we have lined up for you this year:  The Ajax Experience, September 14-16 in Boston, MA

Please Note: While we'll be adding the bulk of our sessions to our individual conference tracks over the next few weeks, we want to be sure you take advantage of the early-bird discount now. That said, we've once again confirmed today's best and brightest Ajax minds from across the globe and we're featuring a number of these keynote presenters and session experts for your review on the site right now, including:

* Ben Galbraith and Dion Almaer, Co-founders of Ajaxian.com
* Brendan Eich, Creator of JavaScript and CTO of Mozilla
* Douglas Crockford, Creator of JSON and Author of JavaScript: The Good Parts
* Bill Scott, Director of UX at Netflix
* Ross Boucher, Co-founder of 280 North and the Cappuccino & Atlas frameworks
* Joe Walker, Creator of DWR
* Nicole Sullivan, Creator of Object-Oriented CSS
* David Wei and Xiang Chaong, Research Scientists at Facebook
* And more! 

More essential speakers and sessions to be announced in the coming weeks, so stay tuned and start planning. One feature we think you're going to love this year is "session previews." Each morning we're featuring 5-minute lightning rounds where presenters entice the audience to attend their session by giving them a brief synopsis of what they will learn. Now you'll have even more exposure to new, cutting-edge technologies and proven solutions - and a better idea of how to spend your days.

 Don't delay, register now for The Ajax Experience to take advantage of your $300 early bird savings.

There has been a nice discussion H.264-in-<video> vs plugin APIs on the WhatWG list.

This lead to Greg Maxwell posting about his experience with the quality of Ogg Theora with real world examples, and Chris Blizzard linked it up with 35 days offering the following lead in:

The codecs being discussed are the same ones we’ll be including in Firefox 3.5 and are also the same codecs that Mozilla, Wikipedia and others have been investing in.

Recent developer nightlies of Google Chrome support these codecs and a future version of Opera will also support them. Theora and Vorbis also work in Safari if you install the Xiph Qt component. We’re quickly reaching the point where all modern browsers support these open codecs with full support for the video tag.

You’ll note that Greg’s post doesn’t have the tone of a marketing document - it’s not meant to. Nor is this a comparison against HD-sized, high-bitrate video. Instead it’s an attempt to give an honest comparison of how the open codecs fare against commonly-used formats and sizes used on the world’s largest video site. I think you’ll agree with Greg’s conclusions at the bottom of the document, especially with audio where Vorbis really shines.

There is also a discussion on how Quicktime doesn't seem to have a nice way to auto-download codecs these days, and the Xiph Qt folks haven't had an easy time getting someone at Apple to work with them. Hopefully that will change with Quicktime X.

Another hope, is that YouTube will push even harder and test out more and more with open codecs (they did the one HTML5 demo at Google I/O, but that is just a demo). If Google puts its muscle behind the standard, then a lot of the video out there would turn open pretty quickly. That being said, Google is a business, and there are lots of factors into making that happen....

Today we’re announcing Release Candidate 3 of Prototype 1.6.1. Among the highlights of this release are official Chrome support, improved IE8 compatibility, faster generation of API documentation with PDoc, and lots of bug fixes.

Since Google Chrome is a close sibling of Safari, Prototype has had excellent Chrome compatibility ever since the browser was first released. Now we’re making it official: Prototype supports Chrome 1.0 and greater.

If you have Chrome installed on your system (Windows only for now, even though early alphas exist for Mac), invoking rake test will run the unit tests in all locally-installed browsers, including Chrome. To run the unit tests in Chrome alone, try rake test BROWSERS=chrome.

It’s been a long, strange trip for PDoc, the inline-doc tool that will soon be for Prototype and script.aculo.us what RDoc is for Rails. It started as Tobie’s brainchild over a year ago, but key contributions from James Coglan and Samuel Lebeau have helped to carry it across the finish line.

PDoc was a part of RC2, but has since been updated to make doc generation much, much faster. On my machine, a process that used to take 20 minutes now takes only 60 seconds. Furthermore, we’ve solved a couple of minor issues that made it hard to build the docs on Windows.

Ever since Prototype 1.5, we’ve kept our documentation in Mephisto, the same engine that powers the rest of the site (and this blog). It’s served us well, but it meant that updating the docs became a chore that could only be started once we’d released a particular version. PDoc will make it far easier to maintain our documentation — and far easier to keep archival copies of the docs for older versions of Prototype.

Upon final release of 1.6.1, we’ll put the generated docs on this site, just like Rails hosts its most recent stable documentation. Until then, you can generate your own local docs by checking out the full source and running rake doc from the command line.

There have also been a number of bugs fixed since RC2 — including a heinous bug relating to Event#observe — and a number of key optimizations. We’ve further improved IE8 compatibility, solving some edge-case issues that popped up since RC2. Credit goes to Juriy (kangax), our newest team member, for working tirelessly these last few months to make 1.6.1 faster and less reliant on browser sniffs.

• Download Prototype 1.6.1 RC3
• Submit bug reports to Lighthouse
• Get Prototype help on the mailing list or #prototype IRC channel
• Interact with the Core Team on the protoype-core mailing list

Thanks to the many contributors who made this release possible!

Today we’re announcing Release Candidate 3 of Prototype 1.6.1. Among the highlights of this release are official Chrome support, improved IE8 compatibility, faster generation of API documentation with PDoc, and lots of bug fixes.

Since Google Chrome is a close sibling of Safari, Prototype has had excellent Chrome compatibility ever since the browser was first released. Now we’re making it official: Prototype supports Chrome 1.0 and greater.

If you have Chrome installed on your system (Windows only for now, even though early alphas exist for Mac), invoking rake test will run the unit tests in all locally-installed browsers, including Chrome. To run the unit tests in Chrome alone, try rake test BROWSERS=chrome.

It’s been a long, strange trip for PDoc, the inline-doc tool that will soon be for Prototype and script.aculo.us what RDoc is for Rails. It started as Tobie’s brainchild over a year ago, but key contributions from James Coglan and Samuel Lebeau have helped to carry it across the finish line.

PDoc was a part of RC2, but has since been updated to make doc generation much, much faster. On my machine, a process that used to take 20 minutes now takes only 60 seconds. Furthermore, we’ve solved a couple of minor issues that made it hard to build the docs on Windows.

Ever since Prototype 1.5, we’ve kept our documentation in Mephisto, the same engine that powers the rest of the site (and this blog). It’s served us well, but it meant that updating the docs became a chore that could only be started once we’d released a particular version. PDoc will make it far easier to maintain our documentation — and far easier to keep archival copies of the docs for older versions of Prototype.

Upon final release of 1.6.1, we’ll put the generated docs on this site, just like Rails hosts its most recent stable documentation. Until then, you can generate your own local docs by checking out the full source and running rake doc from the command line.

There have also been a number of bugs fixed since RC2 — including a heinous bug relating to Event#observe — and a number of key optimizations. We’ve further improved IE8 compatibility, solving some edge-case issues that popped up since RC2. Credit goes to Juriy (kangax), our newest team member, for working tirelessly these last few months to make 1.6.1 faster and less reliant on browser sniffs.

• Download Prototype 1.6.1 RC3
• Submit bug reports to Lighthouse
• Get Prototype help on the mailing list or #prototype IRC channel
• Interact with the Core Team on the protoype-core mailing list

Thanks to the many contributors who made this release possible!

Opera has been leading us on to a bit product launch, and it came today in the form of Opera Unite a product which extends the Opera browser to contain a Web server inside allowing you to talk P2P between browsers (via a proxy at operaunite.com).

On the one hand, skeptics have argued that this has been done before. We have things like the Plain Old Web server and P2P extensions. However, it is nice to see it packaged cleanly, and we have the advantage of more standard APIs (HTML5 APIs, Widget APIs, etc). At Mozilla (disclaimer: remember I work there ;), we also have something that overlaps with this work in Weave.

If you check out the developer primer you will quickly learn that to create a service you simply whip up some JavaScript, XML, and call it good. It is definitely interesting that the "web server" is a server side JavaScript implementation too!

John Resig noticed that from looking at the examples you miss a decent storage API:

Reading the Opera Unite primer. Opera really needs client-side SQL

I believe that there is room for the browser to do more, and to truly be your "User Agent", thus I agree with some of the core tenants of what Opera is trying to do here. That being said, I worry that for all the talk of freedom, are we locked into Opera? :) It would be great to get this out to the community and work on getting multiple implementations and clear licensing of the protocols behind this.

What do you think?

Billy Lamberta got tired having to get so low-level as you do with the raw Canvas API. So, he create a small abstraction layer:

Doodle.js attempts to create a fun and easy way to interact with the Canvas that is lightweight, flexible, and functional. While it contains a few shape primitives it is not meant to be a full-fledged drawing api, rather a framework that allows you to build sprites and interact with them in an expressive way.

He gives plenty examples, but here is one that animates the spiral that you see:

1.  
2.  var r = 5;
3.  var a = 0;
4.  var frame = 0;
5.  
6.  dot.loop(function(obj) {
7.               obj.modify({x:circle_x(a),
8.                           y:circle_y(a),
9.                           fill:random_color() });
10.  
11.               frame += 1; //update frame count
12.               a += 10; //update angle rotation
13.               r += 0.3; //update radius
14.  
15.               if(a % 15 == 0){ dot.fill = '#000000'; }
16.               else{ dot.fill = random_color(); }
17.  
18.               //clear canvas every 800th frame, reset radius
19.               if(frame % 800==0){oo.canvas().clear(); r = 5;}
20.  
21.           }, 0, '48fps'); //loop indefinitely at 48 frames/sec
22.  

Best part of the framework? How he choose the "oo" convention for the main object:

The “oo” variable was picked because it’s easy to type, easy to remember (d-oo-dle), and easy for our eyes to parse when we look over the code (it only takes a very cursory knowledge of male psychology to understand that).

I was actually surprised that I hadn't already posted on this... or CAKE which I will mention next...

Another week, another collection of links to some of the most interesting and exciting new jQuery happenings around the web.

If you have ever used a regular expression tool to highlight character matches in real time, then you’ll jump for joy when I tell you about the Interactive jQuery selector tester written by Samuli Kärkkäinen. You enter a selector expression, and in real time you get to see the elements in the DOM structure that have been selected. I can see this being very handy for complex expressions or for optimizing expressions down to the simplest solution.

Also, in case you didn’t notice, the second maintenance release for jQuery UI 1.7 is out.

• Setting and clearing Cookies are easy with jQuery. Check out this article that details the use of the jQuery cookie plugin.
• Brian Reindel tells us about Sending an XML document object to PHP with jQuery.
• I’m sure most of us are aware of the new jQuery tools. Here is a short chat with the author, Tero Piirainen.

• Noah Hendrix posted an excellent tutorial on NETTUTS about Using jQuery To Manipulate and Filter Data.
• Back from a small hiatus is Remy Sharp, with a new jQuery for Designers post dealing with scrolling carousels. As usual, he provides an excellent screencast to complement the tutorial.

• A new jQuery mp3 player hit the streets, jPlayer! It’s also Themeroller ready!
• Need to re-skin the browser default UI forms? Check out the uniform jQuery plugin. It might just help you realize the dream of making web forms look the same across all browsers.
• If your cup of tea is dealing with mouse gestures, then you’ll be glad to know that there is now a SUPER Gestures plugin. Its SUPER!
• SWFUpload + jQuery = SWFUpload jQuery Plugin.

Pulled from my own personal archives. I bring you $.event.special.hover which is an alternative to Brain Cherne’s popular hoverIntent plugin. You may or may not have missed this plugin, but regardless, it’s certainly worth a first look, or second.

SuperBox and jOverlay, welcome to the crowd! Nice to have you.

It’s possible that you might be seeing several team members, if not John Resig himself, talking at the up and coming devdays. And the really juicy part is they might be wearing a DEVO red energy dome.

“You can save a tremendous amount of time and effort by using the browser-independent framework that JQuery has spent untold man-hours testing, debugging, and proving in the field. While there’s nothing wrong with writing JavaScript, why not speed your development time by writing to the library instead? As I’ve always said, don’t reinvent the wheel, unless you plan on learning more about wheels. ” - Jeff Atwood

CSS3 properties can greatly improve your workflow, making some of the most time-consuming CSS tasks a breeze and allowing for better, cleaner and more lightweight markup. Some properties are still not widely supported, even by the most recent browsers, but that doesn’t mean we shouldn’t experiment with them or give visitors with modern browsers advanced features and CSS styling.

In this regard, keep in mind that educating our clients is both useful and necessary: websites don’t have to look exactly the same in every browser, and if a difference doesn’t negatively affect the aesthetics or usability of a website, it should be considered. If we continue to waste valuable time and money making every detail pixel-perfect (instead of adopting more flexible and future-oriented solutions), users won’t have an incentive to upgrade their browsers, in which case we would have to wait a long time before older browsers become legacy browsers and robust modern browsers become the standard.

The earlier we experiment with and adapt new CSS3 properties, the earlier they will be supported by popular browsers and the earlier we’ll be able to use them widely.

The words above are a conclusion in a piece in Smashing Magazine on taking your design to the next level with CSS3.

The post goes into details with case studies and examples for a huge set of enhancements available in modern browsers:

• Selector improvement
• RGBA and Opacity
• Multi-Column Layout
• Multiple Backgrounds
• Word Wrap
• Text Shadow
• @font-face Attribute
• Border Radius
• Border Image
• Box Shadow
• Box Sizing
• Media Queries
• Speech

Take a walk through the article and play with the ideas. I really like Tim Van Damme's site!

I just looked through the API of Microsoft's new Bing search and found an interesting step in protecting code from throwing errors.

When you provide a JSON output for developers it does make sense to also allow for a callback parameter. That way your code can be used in script nodes without having to use any backend at all. Commonly this is called JSON-P and has been covered here in the long long ago. One of the issues with JSON-P is that when the callback method is not defined it throws an error.

The Bing API is the first instance where I have seen that they worked around that as the output is this:

1. if(typeof callback == 'function') callback(
2. {
3.   "SearchResponse":
4.   {
5.     "Version":"2.2",
6.     "Query":
7.       {
8.         "SearchTerms":"a hard day's night"
9.       },
10.     "Translation":
11.       {
12.         "Results":
13.           [
14.             {"TranslatedTerm":"einem harten Tag-Nacht "}
15.           ]
16.       }
17.     }
18. } /* pageview_candidate */);

I have no clue what the /* pageview_candidate */ is about and frown upon omitting the {} of the if statement, but I must say I do like this. One issue is that while end users don't get annoyed with errors, developers don't have a clue what happened either as the error is silent. One proposal would be to use a console.log() when there is an error:

1. if(typeof callback === 'function') {
2.   callback(... data ... );
3. } else {
4.   if (typeof console!=='undefined' &&
5.    typeof console.log !== 'undefined'){
6.     console.log('Error: Callback method not defined');
7.   }
8. }

More details about other ideas to improve this are here.

Geoffrey Donaldson is working on a series of screencasts covering the new SproutCore 1.0 code base.  He just posted the first episode, covering installing and creating your first app, on Vimeo.  Give it a look and tell him what topics you’d like covered in the future.

Watch the video »

James Coglan has updated JS.Class, his implementation of Ruby's object system in JavaScript.

This release includes a Hash implementation, HashSet, an updated Ruby 1.9 Enumerable module with enumerators and Symbol#to_proc functionality, and an improved package loader that supports parallel downloads and runs on SpiderMonkey, Rhino and V8.

Detailed Changes

• New libraries: ConstantScope, Hash and HashSet, a much faster Set implementation.
• The package manager has been improved with a new API, parallel downloading of files, and support for server-side environments such as SpiderMonkey, Rhino and V8. It also supports user-defined loader functions for transparent integration with Google and Yahoo!’s packaging systems.
• The Enumerable module has been updated with plenty of methods from Ruby 1.9, and now supports enumerators, and Symbol#to_proc-like functionality whereby a string, MethodChain or any object that implements toFunction() can be used as an iterator.
• The core object methods now live in Kernel, and we’ve added new methods: tap(), equals(), hash() and enumFor().
• The double inclusion problem is now fixed; no current Ruby implementation seems to support this properly.
• Ancestor and method lookups are now cached so callSuper runs about twice as fast.
• Classes can be named to generate displayName on methods for
  use with the WebKit debugger.

On the back of the first Jetpack announcement, we see new version announced, 0.2 that adds slidebars, jetpack.future, and persistent storage.

Slidebar isn't a spelling mistake, but a slightly different take on the traditional sidebar. Check out Aza in his screencast to see them in action, and wait for the part where he sucks in a playing video and lets you continue to browse the Web elsewhere.

To code up a slidebar you simply:

1.  
2. jetpack.slideBar.append({
3.   icon: "http://wikipedia.org/favicon.ico",
4.   url: "http://en.m.wikipedia.org/",
5.   width: 300
6. });
7.  

but you have to use another new feature of Jetpack 0.2.... future:

Jetpack is two things at once: it is a platform for experimentation and it is also a solid set of APIs that anyone to easily build new Firefox features. To enable Jetpack to be both stable and — at the same time — to experiment with not-quite-yet-ready features we’ve added the ability to import new features from the “future”.

Slidebars, for example, are still highly experimental. To use them, you need to import them from the future first.

Read more about future in the Jetpack enhancement proposal (JEP) for jetpack.future.

jetpack.future.import("slideBar")

Persistent Storage and Clipboard Support

One of the most requested features in the Jetpack development mailing list was for the ability to persistently store data across restarts.

We’ve added simple storage to the future module. The API is defined in the storage JEP. Using it as simple as:

jetpack.future.import("storage.simple");
var db = jetpack.storage.simple;
var data = {name: "Firefox", twitter: "@firefox"};
db.set( "friend", data );

Give it a go!

Nicolas Garcia Belmonte has updated InfoViz with version 1.1.

The JavaScript InfoVis Toolkit provides tools for creating Interactive Data Visualizations for the Web. The code has been updated:

• The library has been split into modules for code reuse.
• All visualizations are packaged in the same file. You can create multiple instances of any visualization. Moreover, you can combine and compose visualizations. If you want to know more take a look at the Advanced Demos.
• This Toolkit is library agnostic. This means that you can combine this toolkit with your favorite DOM/Events/Ajax framework such as Prototype, MooTools, ExtJS, YUI, JQuery, etc.
• You can extend this library in many ways by adding or overriding class methods. The JavaScript InfoVis Toolkit has a robust (and private) class system, heavily inspired by MooTools’, that allows you to implement new methods in the same class without having to define any new Class extension. By creating mutable classes you can add new custom Node and Edge rendering functions pretty easily.
• Custom visualizations are created by adding or changing Node/Edge colors, shapes, rendering functions, etc. You can also implement many controller methods that are triggered at different stages of the animation, like onBefore/AfterPlotLine, onBefore/AfterCompute, onBefore/AfterPlotNode, request, etc.
  You can also add new Animation transitions like Elastic or Back with easeIn/Out transitions.
  If you want to know more about these features please take a look at the Demos code.
• A complete API documentation generated with Natural Docs, with some Narrative Documentation and Syntax Highlighted Code Examples.