AJAX News: stay one step ahead with the very best and latest in AJAX
from around the world

Supported formats for responses so far are photo, video, link and rich.

John Resig has completed 7 months of work to produce a port of Processing, the "programming language and integrated development environment (IDE) built for the electronic arts and visual design communities", which aims to teach the basics of computer programming in a visual context, and to serve as the foundation for electronic sketchbooks. One of the stated aims of Processing is to act as a tool to get non-programmers started with programming, through the instant gratification of visual feedback."

Processing.js uses Canvas and obviously JavaScript to get the job down in the browser.

John talks about the two pieces of the puzzle:

The Processing Language

The first portion of the project was writing a parser to dynamically convert code written in the Processing language, to JavaScript. This involves a lot of gnarly regular expressions chewing up the code, spitting it out in a format that the browser understands.

The language includes a number of interesting aspects, many of which are covered in the basic demos. Here's a brief selection of language features that are handled:

Note: There's one feature of Processing that's pretty much impossible to support: variable name overloading. In Processing you can have variables and functions that have the same name (e.g. float size = 0; float size(){}). In order to support this there would have to be considerable overhead - and it's generally not a good practice to begin with.

The Processing API

The second portion of the project is the full 2d Processing API. This includes all sorts of different methods:

Congratulations to John, and I look forward to seeing some fantastic visualizations in the browser thanks to this work.

This is Guerilla SOA. AjaxToaster is a server which is designed to perform the functions of an ESB and provide services to Ajax web applications. The goal is to provide practical SOA with absolute simplicity – the antithesis of the complexity of the J2EE frameworks.

If you 'aint got a URL scheme, you are a nobody. That is what I thought when I saw fx:// on the first day of JavaOne.

The newest one of these that I have seen is mountpoint:// which is part of an Opera proposal for a File I/O API in the browser. You know me, extending the browser is a bit of a passion, so I was excited to see what they had come up with:

Traditionally, web applications have had little to no access to resources residing on the local filesystem. The ECMAScript interfaces for file I/O specifies a sandboxed file system, where a widget or other trusted component can gain access to the local file system.

The File I/O interfaces in this specification represent an abstract filesystem, without knowledge of the underlying filesystem's path separators, conventions for setting file properties such as read/write permissions.

The interfaces provide methods for opening files, writing to them, creating files and directories, moving or deleting them, and so forth.

In order to work with files, an application first has to acquire a mountpoint. A mountpoint is either a reference to a file or folder on a disk, or an abstract reference to a set of files which might not necessarily be within the same folder.

If your application wants to use the File I/O API, the browser user will be asked to select a location for the virtual file system, and then you will have access to play in the sandbox.

The core interfaces are:

The FileSystem interface

In a context where the FileSystem interface is made available to applications, the interface is instantiated as opera.io.filesystem. When present, this object provides attributes and methods for acquiring access to files and folders on the local filesystem.

The File interface

The File interface represents objects in a virtual filesystem, and can represent either a file or a folder. A file object consists of a number of properties, and methods for working on these objects

File objects that are marked as persistent must persist across restarts of the application.

The FileStream interface

The FileStream interface represents a File object opened for reading and/or writing, and defines methods and attributes for doing this work.

I have talked before about the desire for a Notification API on the Web. As a Mac user, I would love to see Growl from JavaScript, and there have been libraries written from as far back as protoGrowl.

The difference is between a JavaScript API that does notifications on the desktop, versus trying to get little custom notifications inside the browser window itself. I am talking about the former.

Brian Dunnington has developed Growl for Windows, and with his latest version, he allows you to talk to the system via JavaScript.

You can check out the growl.js library.

What was interesting was the implementation side, and the paths Brian went down to get this working. I asked him for his thoughts, and he wrote up the following:

One of the biggest new features in the latest version of Growl for Windows (v1.2 alpha) is the ability to receive notifications from websites running in your browser. i spent quite a bit of time working out the best way to handle this functionality and thought i would share my thought process.

since Growl can already receive notifications over the network, i figured that it would be easiset to build the Web-based notification system on top of that. Growl receives network notifications using a simple protocol over UDP. ok - first hurdle: browsers and javascript dont do UDP, so i figured i would have to go with some kind of add-on. i wanted the solution to work cross-browser, so Firefox extensions and ActiveX plug-ins were ruled out. i also wanted the solution to work for the broadest range of people, so i didnt want to write a custom add-on (a la Gears). i knew that Flash and Silverlight both had networking support, but neither can do UDP, so they were both quickly ruled out.

that left Java as the only other widely-installed cross-browser extension at my disposal. Java obviously has robust networking support, including UDP, so i headed down that path. the biggest problem now was that i have never created a Java applet, nor even written a line of Java code. but the syntax was familiar enough, and i was able to find some good sample code on the net that i was able to mash into a tiny applet that could send UDP packets. it actually worked brilliantly, and i was quite happy with myself for solving the problem so easily.

but of course, it was not that easy. there is that little restriction known as the 'same-origin policy'. running the applet on my localhost worked great, but as soon as i ran it from any other location, i would get a secuirty exception. i tried all kinds of combinations of values for the CODE and CODEBASE attributes, including file:// urls and even encoding the applet code as a data: uri, but i was thwarted at every turn (as so i should have been - the entire reason the restriction is in place is to prevent what i was trying to do). right before i gave up on the applet idea, i had the realization that if i could serve the applet up from the local host, then it would be able to communicate with the local host later. but configuring and installing a simple web server just to serve up an applet seemed like overkill. alas, the Java idea was a dead end.

so, it was back to the drawing board. what did the browser have access to that could bridge the gap? i decided to try a custom protocol handler, similar to the Itunes Music Store (itms://). a couple of simple registry entries and i had my growl:// protocol working. i had a helper process that sat in the background and everytime a growl:// url link was clicked, the browser would pass it off to my handler, along with the original url. i decided that i could pass any information as a JSON-encoded string in that url information. again, it worked great and seemed to be a good solution, but that made me sure that it must have a drawback. turns out the drawback in this case was that there was no way for the browser to know if the protocol handler was installed on the user's machine - if the protocol handler was installed, the browser passed it off nicely and all was good, but if the protocol was not installed, Firefox would present a dialog saying something like 'firefox doesnt know how to open the address because the protocol is not known' (IE and Safari both just returned a 404-type page). since i wanted websites to be able to use the communication feature if the user had Growl installed, but not mess up the experience if they didnt, this was a deal breaker.

i was starting to run out of ideas at this point, but i remembered the idea of serving up the Java applet locally. while i was pondering the details of that solution, i thought 'if i am going to have a local server to serve up the applet, why not skip the applet and just communicate with the local server?'. so i implemented a very simple webserver that runs when Growl is running that can be accessed at something like http://localhost:9889. the idea of using the url to pass JSON was repurposed and soon i was able to pass JSON-encoded Javascript objects to the local server, which code then parse the data and handle it in real application code. i couldnt use ajax to communicate with the local server (same-origin policy strikes again), so i decided to use the hidden iframe technique. i wrote a small js library to abstract everything out, so now you can write code in Javascript that almost mimics the code you would write if you included the Growl libraries in you application code:

of course, receiving notifications from websites opens up the possiblity of spam and other noise, so applications that register from the web have their notifications disabled by default (thus requiring the user to explicity grant the notifications they wish to receive). but that is another topic for another day.

Ed: I decided to make today, "Extend the browser through APIs Day"

Last, but never least, is Alex Russell of the Dojo Toolkit and SitePen. In Alex's five minutes of video footage for our JavaOne talk, he explained how Dojo enables you to built fantastic, responsive applications for everyone. The everyone piece revolves around accessibility too, which is core to Dojo thanks to work from Becky Gibson and others on the team.

The Dojo grid and charting packages are very rich these days, and continue to get better. Alex also noted in a separate discussion how there are subtle advantages to the charting package such as being able to print the darn things out nicely. Other flashier products may not allow that minor feature.

Previously on Ajax Pioneer Week...

The Gears community is discussing a Geo Location API, which Aaron Boodman mentioned "was recently proposed to the W3C WebAPI group."

Aza Raskin just posted today about Geolocation in Firefox and Beyond which covers his thoughts on an API.

I thought it would be fun to look at the proposed APIs:

Gears Examples

Aza Examples

There is also a lot of talk around privacy and accuracy, and Apple has their own location manager too.

I hope that we can unify some of this, and give the browsers a geo location API soon. One simple JavaScript abstraction will enable a lot of great apps.

I've been talking about progressive enhancement here before and got a lot of flak in comments about it. It seemed that there was a general misunderstanding of progressive enhancement and unobtrusive scripting as a "passing fad" or "backward facing rather than being innovative".

I was asked by a design agency in London to go there and give a brown bag presentation (during lunch break) on the matter and took this as an opportunity to write up reasons and examples for progressive enhancement concentrating more on the why than on the how.

The gist would be to say: enhancing a product progressively means you'll always deliver a working product - as you have no idea how your product can fail in certain environments, you plan for it to fail. This ties in nicely with the agile manifesto - you always deliver software that works.

In my talk I came up with seven "rules" of pragmatic progressive enhancement:

I've taken these ideas and backed them up with benefits you get by following them and code examples in a full article: Pragmatic Progressive Enhancement.

The article is licensed with Creative Commons and uses YUI in the example scripts, feel free to translate, remix and create examples using other libraries.

You can also read the slides on slideshare:

Pending the quality of the recording, there'll also be a video available sooner or later.

Ben and I gave a presentation at JavaOne on what's new with Ajax. Since this was JavaOne, we skewed a little more than we normally would to Java topics, and one of them was using the new Java Plugin, that has great new features such as being able to take a running applet out of the web page, and having it continue to live after shutting down the browser. Java is running out of process here, which also helps the "Java crashing the entire browser" problem.

Anyway, back to our demo. For some context, last year at JavaOne had us performing Guitar Hero on stage, so we knew that we had to use a gaming console in some way. This year it had to be the Wii, but instead of using the console, we decided to just use the controllers.

Wouldn't it be cool to control a Web page using the controllers? We thought so, and we set to it. You can talk to the Wiimotes via Bluetooth, so we needed a stack that would allow us to do just that. Java has a bluetooth stack. We could get an applet to talk to the Java stack. Hmm.

It actually took quite some time to test out the various stacks out there. In the end we went with a native system called Wiiuse that a lot of Wii hackers use. There is a wrapper library called Wiiusej that gave us exactly what we needed.

A quick test later and we had an application that was talking between the remote and the program. It turns out that the main controller sees a series of IR lights that are in the Wii sensor bar, and this allows you to simulate the system with any decent IR source. In the presentation room the big lights that shine on stage were strong enough to act as a sensor bar so we won't even have to use it. We can just point out to the crowd.

Anyway, back to the application. We then wrote a Java class that acts as a state machine for what the remote is doing. It understands the movements, which buttons are pushed, how fast you are moving the device. With this data we could build a simple darts game. With the state machine Java code, and an Applet wrapper that exposed the information, we were ready to get to the Ajax side of the house.

We painted a darts board onto the screen and then had JavaScript start polling the Applet for information via JSObject (As simple as: document.nameofapplet.pollmethod()). This turned out to be more stable than talking the other way, even though it meant we were polling instead of being entirely event driven. When the JavaScript code polled the applet it would pass back a data structure with the data for the coordinates of the remote, and whether the dart had been fired (button A to fire, button B to reload). We would move the dart image on the screen as you move the remote, and when fired we kicked off an animation to fire the dart at the board.

At first, it was all too simple. You setup the shot and it would get the right area every time. Not a fun game. We then decided to add some simple physics to the Ajax game. We took into account the velocity of the throw (if weak it would fall down) and how straight your shot was. If you wiggle around, the dart will not be accurate.

Anyway, this was a lot of fun, and shows that as much as we mock Java applets, if we forget about using them as fancy blink tags, and instead think of them as more extension points, maybe there is life for them.

The video below shows you a demo of the application, the source code with an explanation, and more details.

David Kees has written about Using Prototype to Load Javascript Files, which is an implementation of the general technique of loading functionality via scripts based on the availability of DOM elements.

He started using the technique to scratch an itch:

The calendar on this site only appears on pages that show blog-related information. That calendar is enhanced with Javascript allowing you to change the month displayed by the calendar without reloading the rest of the page. So, in order to ensure that these enhancements would be available everywhere the calendar is, I figured I had two options:

Here is an example implementation:

John Resig got in front of the camera, and the projector, as he gives us his thoughts on the state, and future of Ajax.

He starts out by discussing jQuery Core, and the features in the near term (1.2.4), short term (1.3) and beyond. He then delves into the UI side of the house with jQuery UI 1.5. He segues from jQuery to the future of browsers and JavaScript in general.

Previously on Ajax Pioneer Week...

Eric Meyer has felt a lot of pain due to line-height, which means us mere mortals are totally up the creak.

He posted about how line-height is abnormal and goes into detail on his learning curve, and the pain he saw which lead him too:

Why bring all this up? Because I went and poked line-height: normal with a stick, and found it to be both squamous and rugose. As with all driven to such madness, I now seek, grinning wildly, to infect others.

Here?s the punchline: the effects of declaring line-height: normal not only vary from browser to browser, which I had expected?in fact, quantifying those differences was the whole point?but they also vary from one font face to another, and can also varying within a given face.

I did not expect that. At least, not consciously.

He created a tool that visualizes all of this for you, so you can see the magic at work:

Simon Willison gave another jQuery talk, this time at XTech, called Unobtrusive JavaScript with jQuery.

In the presentation he delves into the reasons why you should go unobtrusive, how to use jQuery, and why they are a good match.

Here is the presentation in full:

AJAX Matters

AJAX News from Ajaxian

...

Design stunning AJAX applicatins!
With JavaScript Editor you combine JavaScript, XHTML and XML visual and code editing