It’s amazing how far we’ve come in a few years with JavaScript. A few years ago, Microsoft and then Firefox built out new functionality accessible from JS to allow JavaScript to make asynchronous calls back to the server side. At the same time, methods to manipulate the page became even more robust. Combined with improvements on the client side (faster computers and connections) as well as improvements in the efficiency of browser JavaScript engines, JavaScript applications can now operate as smoothly as native applications. Some browsers are, of course, better than others in this new world, but all big three browsers are more than acceptable.

What’s fascinating is that the core specification hasn’t changed much in a long time. New functionality has been added, and the folks at Microsoft have driven a lot of it, but the core language and the types of functionality exposed are pretty much the same as they have been for 4 or 5 years. After looking at a lot of the great libraries out there, I keep finding code that, while very clever, seems really hackish in terms of bringing certain functionality to the browser.

I’ve spent part of this afternoon looking for specifications or proposals for the next iteration of JavaScript. I’ve seen some stuff at Mozilla.org about JavaScript 2.0 and some discussion around what that spec means. There are OO features and strong typing coming out, and I can see those kind of generic changes coming. The biggest feature I’ve found so far is E4X, which basically exposes XML DOMs in a very convenient way. At work, we use a AS2 library which does essentially the same thing for Flash. I think it’s this one or something like it.

What I wish they would come up with is a common interface for socket communications, similar to ActionScript’s XMLSocket object. While XMLSocket is limiting in exactly what I can do (it’s hard to send bytes, no HTTP or SOCKS proxy support), it would be a good start. Ideally, we could get a version of XMLHttpRequest that allows the client to inspect the stream as it downloads rather than at the end. That would get us most of the way there.

If you’re wondering what we could use this for, just think about the dynamic scoreboards at ESPN.com, or GameCast, or applications like a stock ticker or, well, you get the idea. We’re so close to having a seamless, completely browser-agnostic way to do this that it’s sad that we can’t get there. Our solutions (in fact, all of the ones I can find, not just ESPN.com’s) all rely on a plugin of some kind. Flash or Java are the most common choices, but that means more dependencies and another set of implementation bugs to deal with.

By the way, if you work with distributed project teams and want a realtime communication system that gives you a hybrid between a messageboard (persistence, shareability) and IM (realtime communication), you should take a look at Campfire by the fine folks at 37signals. It’s free at the entry feature package, and it’s so simple to use, it’s ridiculous. If you want to try it, drop me a line and I’ll invite you to my chat setup.

I only bring it up because XMLHttpRequest is close enough for most realtime functionality. Their app polls every three seconds which means a lot of hits that are wasted, but worst case you’re looking at a 3 second delay between someone hitting enter and you seeing their message. For apps like stock streamers and sports applications, though, where events may be minutes apart, polling is extraordinarily wasteful.