Over on my personal blog I talk about a 3D slide deck I’ve created that uses HTML5, CSS3, and a bit of SVG (video). The main idea behind this deck is to be able to ‘zoom’ into topics to as deep a level as necessary. Slides are nested, like an outline.

For example, I gave a talk at Future of Web Apps recently on HTML5, CSS3, and other web technologies and only had 40 minutes, so I just skimmed the surface of the slides. However, in a few days I’ll be speaking at Fronteers and will be diving deep into SVG and Canvas, so those slides can be zoomed into. The goal is for me to have a universal slide deck that can ‘accordian’ open and closed to fill either a 40 minute session or an all day workshop, kind of like stretchtext.

Read more to learn about the 3D slide deck and how I built it.

In his own words:

Software development is hampered by a specific set of design mistakes that were made in the first programming languages and repeated in everything that has been done since. And, somewhat miraculously, JavaScript is going to make it right, radically transforming the way we write applications. Again. In the Loop of History, it has all happened before, but it has never happened like this. This is why you should care about the emergence of server-side JavaScript and the excitement around projects like Node.js — not because they’re at the sharp end of a trend, but because they’re paving the road toward the next big revolution in software.

You can sign up for your free ticket on Meetup and there are still a few places left. As with all the BayJax talks the video will be available later on, too.

French: Paul Rouget of Mozilla, shows you the future

Paul builds the best demos. ever. At the Mozilla Summit in Whistler, he shows off what you can do when you remix HTML5, CSS3, SVG, WebGL, and WebSockets. A must see.

German: Building an awesome social HTML5 engine

Paul Bakaus of Dextrose (and jQuery UI fame) recently launched the Aves Engine, a social gaming engine in pure HTML! Dextrose also joined forces with Effect Games to bolster its Web gaming might. Paul gave a talk at Google explaining the technology, and it just went live:

“Irish”: Paul shows you jQuery c0de

Ok, Irish by name, and maybe a touch by nature…. but not by nationality. Paul Irish has been doing an amazing talk at conferences where he walks through the jQuery source code to teach you fun and frolics of JavaScript. He picked up ScreenFlow and did it again to reach you all. Paul is a gem in our community, and at 52 minutes…. you will still want more:

Have a great weekend!

(Live blogging notes.)

At JSConf, Steve Souders walks us through several performance-optimising things on his mind lately.

Site Speed in PageRank

A week ago, Google announced site speed is going to be taken into account for PageRank. For Steve, this is a dream come true. Now companies are going to start investing in performance, so less of those slow-loading sites that frustrated him enough to get started down this performance path. One of the criticisms is that this will favour big companies, but Steve points out that smaller companies are often more nimble and able to adapt to changes like this.

As part of Google's webmaster tools, site performance is shown to respective site masters, along with some guidance. Another good resource is http://www.webpagetest.org/. Other than its main measurement service, a great feature of WebPageTest is side-by-side comparisons. Show your manager a side-by-side against a competitor for guaranteed satisfaction.

Performance of Third Party Widgets

There's been something of a reversal in performance hotspots. Five years ago, it was the core application code that was mostly slowing things down, much as teams would like to blame performance problem on 3rd party ads. Nowadays, those apps have been more finely tuned, and at the same time, people are using more 3rd party stuff - not just ads, but embedded widgets. All of which explains why Steve's been looking at third-party widgets lately. You can see what he's been up to at P3PC, a benchmark tool for third-party widgets.

A key question is how are the widgets embedded? People are no longer just doing the blocking document.write calls. Instead, it's much more common to dynamically create a script tag and append to the page. But where and how do you append it? jQuery's library code, for example, does it in a simple, elegant, manner:

Others, not so much. See Steve's recent blog posts for more analysis on these techniques (e.g. on Google Analytics).

Frag Tag

An early proposal from Steve and Alex Russell ...

<FRAG>
<script src="snippet.js"></script>
</FRAG>

The idea is that the frag loads independently; even document.write doesn't block. And it could go further, into a sandboxing mechanism. "If we had this frag tag, it would be one of the biggest things website owners could do to improve the performance of their pages."

Browser Disk Cache

The main message here is that browser disk cache is too small, and he's been talking to vendors about upping capacity. And there's a survey for you.

What makes sites feel slow?

So lately Steve's been going back to basics and looking at user perception, thinking not just about how fast the Javascript takes to load, but how fast till the user sees anything. So he's promoting the standard progressive enhancement pattern, similar to Facebook's earlier talk:

* Deliver HTML
* Defer JS
* Avoid DOM
* Decorate later.

He's done a couple of studies to this end:

* Charting page load time - as the user actually sees it - against market share...in an attempt to show faster sites mean bigger market share.
* Looking at initiail payload versus execution. Many of the sample (highly popular) sites are serving many functions on initial payload, which could be deferred until later - putting scripts at the bottom of the page, and loading scripts asynchronously.

Other Stuff

Check out:

* Browserscope, "a community-driven project for profiling web browsers".

* HTTP Archive Format (HAR). An industry standard for capturing Used in an increasing number of tools, e.g. NetExport plugin in Firebug.

* Velocity Conference, which Steve founded with O'Reilly. June 22-24, Santa Clara.

@edr is the man. He did amazing things at Yahoo! and now at his new role at Google he continues in the same vein. This time he has created the coolest set of HTML5 slides ever, using the technology inline.

Take a walk through the woods and learn about all things HTML5. Starting with the JS APIS (selector API, storage, appcache, web workers, web sockets, notifications, drag and drop, and geolocation).

Then delve into the new HTML semantic tags, link relations, micro data, ARIA, forms, audio and video, Canvas, and WebGL.

Finally, the holy trinity finishes with CSS and selectors, fonts, text, columns, stroking, opacity, HSL, rounded corners, gradients, shadows, backgrounds, transitions, transforms, and animations.

Top draw Ernest. Top draw (he based his work on a presentation from Marcin Wichary).

Thomas Fuchs gave a presentation titled "I Can't Believe It's Not Flash" at WebStock. It is often hard to grasp a presentation from slides, but this one is great fun to flip through.

This one really hits home:

We were surprised to see how JavaScript was NOT the bottleneck in Bespin when we first prototyped it.

And, this is Thomas, so you know he is going to be cheeky.... and he doesn't dissapoint ;)

Douglas Crockford is Yahoo!'s JavaScript architect and a member of the committee designing future versions of the world's most popular programming language. In the first three months of 2010, Douglas will be delivering his acclaimed series of lectures on the history of JavaScript, its features, and its use.

1. Monday, January 25: History of JavaScript (RSVP)
2. Friday, February 5: Survey of the JavaScript Language (RSVP)
3. Wednesday, February 17: Functions and Inheritance in JavaScript (RSVP)
4. Wednesday, March 3: JavaScript and the DOM (RSVP)
5. Wednesday, March 31: Style and Performance in JavaScript (RSVP)

Lectures will be held in URLs Café, Building C, on Yahoo's main campus in Sunnyvale, CA. Doors open at 5:30 p.m.; lectures begin at 6 p.m. Pizza and refreshments will be served. Attendance is free, but seating is limited; RSVP is required for admittance.

I can't wait!

The Goodies

Here are some of the things we can look forward to. (Having been part of the large crowd who charged the pub across the road at lunch, I was a bit late getting back, so I missed one or two of these.)

Lists

It takes a mental shift to start taking advantage of features like this. "Certain browsers" *cough* don't yet provide these conveniences, but you can take advantage of them straight away. Or another example is the base2 library - use it now and you'll be ready for the time when it's present in all browsers.

Getters and Setters

As our Javascript apps get increasingly bigger and more complex, we need to borrow principles, patterns, and techniques from "real programming". Getters and setters are the kind of thing we'll need more of. More generally, we'll need to be in the mindset that we're building APIs to components, which others might use; not just an individual making a one-off web app. Stuart shows a couple of techniques for getters and setters: (a) manually defined; (b) using

Storage

We can now do global storage - globalStorage works similarly to cookies. "Like cookies turned up to 11".

He notes that like XHR, Microsoft did it a long time ago with userdata.

There is also the possibility of SQL and a consistent database API, somewhat supported today but not yet standardised.

Server-Sent Events

Only in Opera right now.

Great. So Do We, Can We, Use it Now or Later?

You can use these features now if you're in a single-browser environment that supports them: app for one mobile; Air app; intranet app (where you've amazingly got Firefox exlcusively on your intranet); HTA. This isn't the sinful act of coding to weird proprietary APIs; it's coding to browsers that happen to support the technologies of tomorrow, today.

The libraries help us get to the future today, as long as they can support APIs compatibly across all the browsers. But it's all a little difficult when the market leader doesn't play ball. Hopefully, Dean Edwards will continue working on Base2 to plug the gaps, but we still have the problem. Around a year ago, it felt like the anti-IE6 might be at a tipping point, but that's died down a bit, and it's not clear how much longer we'll be held back.

What can you do then with IE6? If a number of major websites really held back and stopped supporting IE6, Stuart reckons corporations would upgrade. Imagine what would happen if Google stopped working on IE6...immediate upgrades. Show of hands indicates perhaps 20% of the audience would agree to mass dropping IE6 on their public sites. In Q&A, Stuart later clarifies he's not really proposing an IE6 shutdown switch, more like a helpful suggestion to upgrade.

Silverlight and Flash. Proprietary, not open. If everyone started using Flash, the future is Adobe's future. Let's make it our future instead - we're building the open web. A call to arms for showing strength in numbers.

Comparisons: Understanding identity (===) versus equality (==).

Boolean expressions: Understanding how short-circuit logic (if a && b won't eval b if a is false);

Types: Type coercion ("1"+2+3); "falsey" (false, null, 0) versus "truthy"; the importance of using operators like parseInt and instanceof.

Functions: Anonymous functions; self-invoking functions - function() { })() ; using the arguments collection to get all arguments to the current function, important to note it's not a real array with all the array methods, and using arguments to overload arguments.

Objects: Using object literal notation { a:b, c:d } instead of setting up properties individually; equivalence of ben.arms and ben["arms"], and how useful it can be to use the latter in conjunction with a function argument, ie let the caller pass in a variable which will be set; using "in" to check if a property exists (if "arms" in ben).

Inheritance: Using the prototype chain for inheritance from subclass to superclasses up to Object. There are various implementations - e.g. Resig, Edward's Base, Dan Webb; if you understand these implementations, then you understand Javascript. However, Robert's arguing for the native way of doing it - as Doug Crockford says, "I now see my early attempts to support the classical model in Javascript as a mistake".

Global scope: Avoid using global scope where you can. For example, nesting functions. R
obert later points to the Yahoo! module pattern.

Binding this: Using call and apply; these are useful for setting this and also can pass arguments through from the current function to another one without having to manually copy them out.

Sugaring: Adding syntax sugar, e.g. extending String.prototype.

Currying: As illustrated by Doug Crockford's curry implementation.

This becomes disastrous when a company tries to reach developers with their product. Normal marketing and PR stunts normally fail to get us excited. To work around this issue, clever companies allow developers to move into a role of developer evangelists.

A developer evangelist is a spokesperson, mediator and translator between a company and both its technical staff and outside developers.

This is my job at the moment, and I was asked by people I trained if there is a handbook about the skills needed to do this job, so I wrote one.

Check out the The Developer Evangelist handbook

The handbook explains several things:

The handbook is Creative Commons and free to use. I am working on getting a printed version out, too.

I went along last night to the London Mozilla Labs meetup, where Dion, Ben, and Joe delivered a presentation on Bespin. These are my notes from the event.

Goals

Bespin - initially an experiment, now interested to see how far it can go as a coding environment (among other things).

"The editor of our dreams":

• Accessible from anywhere
• Simple to use, like Textmate - for people who don't want to muck around with low-level details, too much time in version control
• Wicked fast - many editors look okay initially but don't scale well with large files and fast editing
• Rock-solid real-time collaboration - like SubEthaEdit - watch people in our time, e.g. follow someone like Brendan Eich as he codes (given that it's already open source). One of the meta-goals here is to lower the barriers for open-source development.
• Integrated command-line, like Vi
• "Self-hosted" environment - like Emacs. As a programmer, can get into its guts. And can do this kind of thing in real-time - modify the model as it runs (c.f. Eclipse - must re-compile)

Demo

Dion demos interacting with the Bespin editor. (Always good to see how the creators eat their own dogfood.) Ben points out it's fast, thanks to Canvas. Some demos of the command-line, its extensibility, and collaboration features.

Collaboration

Moz hired Joe Walker of Comet/DWR fame a month ago. Joe explains collaboration goals.

Typical scenario - two coders working simultaneously, perhaps chatting over skype.

From Neil Fraser (worked on Google Docs stuff around this) - designed as a "little version control system" - sends out diffs and patches it (see Mobwrite. Bizzarely, the bottleneck is not the network or the patch, but the diff. And exarcebated by the fact that typing faster - doing more work - necessitates more diffing.

Joe shows debug messages in Firebug console - showing diff info going to and from the server

Extra Features

Code nav - heatmap showing all of code and what's been edited. recently. Example of a mashup component you can build.

e.g. IBM coder turned it into a Java compiler - by compiling the Java on the server. Used Bespin's server API. Likewise, the editor is also a distinct component - can use the editor for other (non-IDE) application - e.g. a wiki project using Bespin's editor to edit the wiki. Likewise, the command line is separate. And there's the underlying core, Thunderhead.

Ben further emphasises it's not just a rich client-side editor - server-side code analysis with the RESTful API.

Upcoming Features

Big things:

• Collaboration
• VCS integration - integrate with Mercurial, etc etc
• Ubiquity Integration
• Server Side Javascript - can have different server implementations, could be Ruby etc, and want to implement one in JS

Smaller:

• Some nice commands
• Plan "follow me!"
• Syntax highlighting
• Design concepts
• Templates ("create project Rails")
• Editor functionality
• ... many more - need people to help with it (engaging with the community and supporting contributions in an open-sourcey way is a big theme in this talk)

Fin

They leave us with a clip of Dave Thomas @ RubyConf asking if it's weird to love your software tools, and answering that you have to love your tools. Fair play!

Questions and Answers

Q. Distributed Version Control - will bespin support it? Bespin designed for two basic use cases (a) standard thing - check in to repo etc (b) bespin.mozilla.com - SAAS type model.

Q. What data structure is being used for patch sets? Because a decent structure would make VCS possible. Mobwrite - Neil Fraser's project behind Google Docs - so using that format, but we might expect it to change in the future.

Q. (me) Eating your own dogfood Dogfooding by end of month, when VCS lands or using Appcelerator Titanium to run off local file system.

Q. (about integration with Ubiqutiy I think?) Ubiquity as the runtime and Bespin for authoring. Initially, separate to Ubiquity and then normalised commands with Ubiquity. Now just starting to share components like parser. Next phase, access to virtually all of Ubiquity and will work even without Moz browsers. And the other way round - running Ubiquity commands inside Bespin.

Q. With the collaboration engine, can you do more than code creation, e.g. drawing or spreadsheets? Using Mobwrite, the engine behind Google Docs' collaboration - Mobwrite's restricted to text - as long as there are changes to some structure (ie it can be serialised), it's possible.

Q. Codes and tests in the cloud - should be great for continuous integration There are various people already implementing the Bespin server API for other things too. With the code out in the cloud, very possible to do all sorts of things with the code. John Resig (also Moz) is also interested in this area - also wrt manual tests that are downloaded to various people's browsers and run locally. Maybe could even be automated using the aggregate crowd while the browser isn't doing anything else. Another project is Test Pilot (usability testing).

(On a related note, I mentioned later on it would be interesting to couple the code with real-time user data, e.g. a heatmap overlay on the code showing how much resources each segment used during real-world use.)

Q. Hyperlinking in code? Could you create ~implicit links, e.g. to other parts of the code? Don't have hyperlinks because it's canvas! But will be able to implement these things - would be done as a syntax highlighter extension.

Q. Firstly, the name? Secondly, the offline capability - can I just run it directly off the local file system. With Appcelerator Titanium, would feel like a real desktop app while offline, but can still access the cloud when connected. (No-one answered the name question ;)

Q. Mashups in the browser - loads of scope for in-editor mashups, will it be part of the editor framework Right now, editor has an event bus - events like "he's opened the file, he's hit a key", so can set up events for this kind of thing. It's all based on an asynchronous model, so very possible.

Q. Will there be user testing - to see what people really want? There's a huge list in Bugzilla for these kinds of things. This is a tech preview, missing a ton of functionality. Already improved, but a lot more to do.

Q. Vim or Emacs macros - which will be first? Have implemented Elisp and Javascript, so it's only a matter of time. (cunningly avoided expressing a preference :)

Q. Functional reactive programming (FRP) - Flapjax demonstrates the idea in JS - for pubsub. Would it be possible to extend the current pubsub framework into a FRP framework - avoids bugs around order . Would be good to see something like that.

Q. Are you "re-inventing the web" with this stuff, i.e. finding that canvas doesn't support it? Yes, do have to reinvent a lot of things - people coming together to discuss these things - ARIA etc. Very focused on accessibility. Two ways to do it - (a) hacks like the cut-and-paste to mirror what's happening; (b) longer-term - drive the browsers forward.

Aside - Bespin currently leaks memory. Browsers are now runtimes, so want to build a tool for memory tracking. (a) Log each garbage collection. (b) Graphical view of the heap. After that, tool after that is meta - a directory of all the tools out there.

Q. On a much smaller scale, could it be used as a textarea? Yes, Firefox engineers were keen to look at that.

Q. How much implemented in Javascript? Very much the trend in Moz. cf. Aza Raskin's recent post on doing an extension in Javascript (*cough* Chrome *cough*). All the XUL stuff was necessary at the time. Javascript's not the bottleneck anymore.

Q. The name? (as was previously asked) So with that, let's wrap up.

My colleague Fred has also posted his impressions.

This was my favourite presentation of the year. Ben and I have given a lot of talks together, and to spice things up we created the presentation randomizer, a simple Ajax app that would sound a buzzer at random times. Why did we do this? When the buzzer went, we would have to instantly change presenter. "Who's line is it anyway?" for geeks.

The presentation was recorded by Adobe, and Ted Patrick just pushed it live:

The Ajax revolution is complete: Sophisticated JavaScript user interfaces are nearly ubiquitous. Yet, the innovations in the Ajax community continue. Dion and Ben set the stage for the Ajax Experience by discussing the latest developments, including multithreaded JavaScript technology-powered UIs, robust offline storage, choosing the right Ajax/JavaScript technology framework, Ajax outside of the browser, and more.

Thanks again to the entire community that came out to The Ajax Experience. Without you, we wouldn't have this opportunity.

At our Ajax Experience keynote this year, Dion and I coded up a simple little program that buzzed at random intervals every 10-120 seconds. Whenever it buzzed, one of us had to stop talking and the other would have to pick up right where the other guy left off. It definitely kept things fresh.

Quite a few folks asked us to release the code. It's quite trivial; check it out.

We used SoundManager2 to play the buzzer sound; the rest is straight-forward.

First, we have his interactive learning area where the presentation is just a JavaScript application that you can play with. Double click on the code, make a change, and save away!

The talk goes into the innards of the language that we are know, love, or at least deal with:

• Defining Functions
• Named Functions
• Functions as Objects
• Context
• Instantiation
• Flexible Arguments
• Closures
• Temporary Scope
• Function Prototypes
• Instance Type
• Inheritance
• Built-in Prototypes
• Enforcing Function Context
• Bonus: Function Length

The goal of all of this, is that after going through the presentation you should understand the following:

Next up is his talk on Canvas, Processing and Processing.js. Everytime I see this stuff it makes me smile. Amazing visualizations are here:

Dean Edwards, Brendan Eich, Christian Heillmann, Jake Archibald, Joe Walker (chair)

I've captured at least some of what was said here ;).

What is the Open Web to you and why is it important (or otherwise)?

(general agreement that it's good thing, as we'd expect :)
Christian - What if open formats don't have the reach? e.g. ogg vorbis.

One JS file can't depend on another without wrapping all the code in a function. How should this be solved? An "include" function in ES4?

Brendan - "include" could make UI lock up. Can do it with (html 5) web workers (speculative parsing).

Should you pick just one library/framewrk to use, a handful, or have an open policy to use anything at any time? How do you evaluate which one(s) to use?

Christian - would be good to see comparison sites like cmsmatrix.org, not just which one is 20 milliseconds faster than the other. (MM - I tried to create something like this, but it could be bigger in both dimensions.)

Discussion about the "glow" library created by BBC, discussed by Jake Archibald yesterday. Okay to release unpolished product to open source as an individual or small company, but harder when it carries the name of a big organisation like BBC.

What kind of build scripts/engines do you recommend to concatenate multiple scripts into one?

Jokes about copy-paste and batch scripts.

Christian - It's 2008 - we should be using minifier, etc. More structured approach to releasing.

What recent tools or techniques do you use to speed up or improve your development process? Do you have any quick tips?

Jake - More developers :) HTML editor - Komodo edit. Debug - Firebug in FF, Developer toolbar and windows script debugger in IE

Christian - Moving to a Mac made developing far better, and partly due to Textmate. And Javascript bundle that runs JSLint over your code. Firebug.

Brendan - Distributed version control systems have been good. Textmate's good, but I'm an old Vi/Unix hacker.

Dean - Recently disabled Firebug to speed up development - causes bugs, reports misleading line numbers, etc. Went back to error console which gives you the correct line number. (Joe - it's getting better now.) Microsoft script debugger is actually quite good.

Christian - Firefox still the coolest browser for developers, but with all the tools, have to keep turning off greasemonkey scripts etc.

Does Cappucino / Objective-J have a future? What are their benefits and detriments?

Dean - More problems in the browser
Brendan - GWT guys are realists, acknowledge their abstractions leak. But OTOH they've made Ajax development accessible to Java developers who otherwise wouldn't do it.
Brendan (asked about what he'd do if he could change the language in the browser) - You'd get a lot of demand for Python and Ruby, Python's probably the more mature.
Brendan - Flex originally intended to make web app development like windows development. (Questions this approach). Pity we don't have things like JQuery for desktop apps.

What's the biggest missing bit of functionality from modern web browsers?

Christan - Big problem is we're stuck with old browsers.
Jake - Large companies lock down IE6.

Poll of audience - many people work for companies where the average user still runs IE6.

How to prevent? 37signals, Apple, Facebook have all written apps that don't target IE6. Christian-mainstream media could help, e.g. recent article saying users rarely get viruses via FF. Facebook also recommends FF and Safari along with IE.

Christian - Chrome is targeted at regular users, not developers - so IE market share might reduce. Brendan - Chrome might, good if they do, but difficult to see how to make a major change.

Jake - Apple get away with a lot of evil that if MS did the same thing they would be beaten for. e.g. Apple ships with a browser, just like MS.

Back to the question - what would you want:

Dean - standardised behaviour extensions for CSS
Jake - constants in CSS

Joe - vector graphics engine - canvas everywhere

Christian - web forms - e.g. calendar control

Jake - CSS - multiple background images

Christian - better layout (discussing boxes and vertical centering). Right now, we're as hacky as we were with tables.

Christian - better video and audio support (Jake - Flash alrady does this well, would rather see effort spent on other things).

Audience - up button (to go up directory levels).

I had to single this talk out. Steve Yegge is a living legend, and with his mammoth write up of his talk you can see it in text view, and you can also download all of the slides.

Steve does his thing, and goes in glorious directions, such as how we end up with a scriptable back end, how the JVM matters as a host for these things, SchemeScript, how defineProperty gets around the for .. in issues, "Who likes to write their own giant deterministic finite automata to do string matching? Heh. It's weird — nobody raised their hand.", obj = {run: function() { print('hi') }}, RnR (Rhino's not Ruby), "And Scala's interesting because it actually takes a functional static type system and it layers... it merges it with Java's object-oriented type system, to produce.... Frankenstein's Monster.", and man it just keeps going and going.

As much a talk about languages as a whole.... and a lot of fun.

As well as Firefox 3 support, Gears 0.3 includes:

• Ability to create desktop shortcuts with a snippet of JavaScript
• Improved support for customizing the installation flow and permission dialog
• Better support for sending complex objects to workers
• Detailed progress events for managed resource store updates
• And more...

Then, all of the videos from Google I/O sessions have been published.

I put together a playlist that includes Ajax and Gears related content:

Check out the great talks such as:

Gears

• Improving Browsers in New Ways: Gears++
• Google Gears for Mobile
• HTML 5, Brought to You by Gears
• Gears and MySpace - Search on the Client
• Taking Large-Scale Applications Offline
• Gears Case Studies

GWT

• Using GWT to Build a Diagramming Tool
• GWT and Client-Server Communication
• GWT Extreme by Ray Cromwell
• JavaScript and DOM Programming in GWT
• Resource Bundles and Linkers in GWT
• Deferred Binding with GWT

General Ajax

• Alex Russell on "Can We Get There from Here?"
• Spice up Your Apps with Google AJAX APIs
• Yours truly, Dion and Ben, State of Ajax: The Universe Is Expanding
• Steve Yegge on Server Side JavaScript

Wow, a lot of material there!

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.

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...

• Alex Russell of Dojo
• Bruce Johnson of GWT
• Sam Stephenson of Prototype