Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Is JavaScript the most successful scripting language ever?

Aaron says I need to work on my slug sentences, and I agree. On reflection, I suck at writing almost any kind of sentence. I guess I shouldn't expect slugs to be different.

For a couple of years I've been akwardly saying things like "and I would suspect that JavaScript is the most successful scripting language ever" or "I don't really have any hard numbers, but JavaScript seems incredibly successful as a language". Note all the hedging.

What I would like to know is this: on what axis is JavaScript not the most successful scripting language of all time? Can some other language beat JS in:

Perhaps KSH and/or bash would win? I'm curious to know if anyone can think up other strong contenders.

Updated DHTML Universe Map

I've uploaded updated renderings (pdf or png) of the document I use to keep track of the non-trivial, public DHTML toolkit efforts that have occurred over the years.

Interestingly, the difference between this version and previous ones is that many companies are starting to either release or talk about tools that they had quietly built in-house years ago. Also, Google and Yahoo have been on something of a hiring binge. Yahoo seems to be dedicating more (visible) resources to their responsive UI cause than Google. The secrecy difference between the two cultures might explain the delta, but I'm convinced that's not the whole story.

Also interesting is that many of the commercial DHTML toolkit vendors have been able to effectively keep mum about who is working on their products. The TIBCO's, Backbase's, and Bindows of the world must be paying their people astoundingly well for them to keep out of eyesight of the increasingly frenzied recruiters who are banging down the doors of every competent JavaScript hacker I know.

I will admit to not having kept this document as up-to-date as it should be. The proliferation of toolkits over the last year has been pretty astounding, and investigating each one to find out if it's just another crappy 10-line XMLHTTP wrapper hasn't been on the top of my list of things to do. So in true open-source style, your help is requested! If you have corrections or new information, please either mail them to me or submit a patch to the graphviz source file. The format is straightforward and easy to figure out.

What else is burried down in the depth's of Google's amazing JavaScript?

So the new GTalk interface in GMail is pretty rad. Congrats to Dan and the rest of the team that made it "go".

The talk feature is cool not just from a UI perspective as the code is also chock full of little gems. I'm kind of a dork about low-latency data transport to the browser. HTTP wasn't meant to be used this of course I'm interested! Ever since Joyce got me involved in the rewrite of mod_pubsub I've had my eye on the various ways that servers can push data to browsers and the kinds of technology that will prevent a server that's doing this from melting down (hellooooooooo Twisted). Using just what's available to the browser, it's possible to have the server push data encapsulated in <script> blocks and rely on a progressive rendering behavior that every modern browser implements to dispatch events in near real-time (compared to full page refresh or polling delay). There are a mountain of browser quirks that of course play into this process. The least desirable of these to the user are the "phantom click" and the "throbber of doom" that afflict IE users.

When a page (or an iframe it hosts) is loading content, your browser usually shows some sort of "I'm working" indicator. In the bottom "taskbar" there is usually some sort of progress meter. In the upper right (on IE) the "throbber" will continue to animate until the work is done. Of course in the scenario I'm describing the sent page is never done. The whole point is that the server keeps the connection open. Combine this with the IE behavior of producing a "click" like sound when an iframe is navigated to a different URL, and you've got a pretty poor user experience.

But couldn't you do something with XMLHTTP? Short answer: yes, but not as portably and it won't get you around IE's 2-connection limit either so there's not much of a win. For the long answer, see my talk at ETech or wait for me to post the slides. At the end of the day, the hidden <iframe> hack scales best and is the most portable. Especially if you can lick the UX problems.

Which Google has.

How? By cleverly abusing another safe-for-scripting ActiveX control in IE. Here's the basic structure of the hack:

  // we were served from but
  // have already set document.domain to
  var currentDomain = "";
  var dataStreamUrl = currentDomain+"path/to/server.cgi";
  var transferDoc = new ActiveXObject("htmlfile"); // !?!
  // make sure it's really scriptable;
  // set the iframe up to call the server for data
  var ifrDiv = transferDoc.createElement("div");
  // start communicating
  ifrDiv.innerHTML = "<iframe src='"+dataStreamUrl+"'></iframe>";

This is the kind of fundamental technique that is critical to making the next generation of interactive experiences a reality. Server tools like mod_pubsub and LivePage (and perhaps even JMS buses) are starting to come into their own and the benefits of event-driven IO are starting to become well understood by server-side devs. It's only a matter of time before server-push data hits an inflection point in the same way that background single-request/single-response data transfer did with Ajax. Dojo will, of course, have infrastructure to support this kind of thing when the borader developer community is ready (most if it is already in place).

From long and painful experience and amazingly deep respect, I take my hat off and bow to whoever it was on the GMail/GTalk team that figured this out. It's a hell of a hack. It's no wonder that Google has been able to attract and develop the best DHTML hackers in the world.

Update: so just to be very clear, I worked on the rewrite of the mod_pubsub client. The server rewrite was handled by some folks who are much smarter than I am.

OSCON '06 JavaScript/Ajax Track

These are exciting times for JavaScript. Just a couple of years ago, what community was left around JavaScript and DHTML was dying. No one who was seriously interested in doing development with the language back then could have imagined that JavaScript and the yet-to-be-named Ajax would have it's own track at OSCON, but that's exactly what's happened. I'm happy to announce that Elaine Wherry of Meebo and I are co-chairing a JavaScript and Ajax track at OSCON 2006.

While the Call for Participation page doesn't yet include our track as one of the options, time is short for getting talks in (just over 2 weeks at this point). If you've been itching to talk about something JavaScript, DHTML, or Ajax related, please go fill out the CFP form and mention that it's for the JS/Ajax track. Obviously, we can't guarantee that your talk will be accepted by the committee, but there's nothing to lose and you can propose multiple talks.

If you're one of those folks who has scads of DHTML/JavaScript experience and just isn't sure what to propose a talk on, just send me mail and we can discuss what topics might be better than others.

Good luck, and see you at OSCON '06!

How IE7 Can Avoid Irrelevance

Every generation of browsers has its boat anchor: that browser which is so painful to develop for that there's nothing professionals would love more than to see it instantly disappear from the desks of users. This is different than simply being old. Old browsers will eventually cycle oh-so-slowly out of circulation. Webdevs understand this and live with it. We're used to pain.

What really rankles is when there's no light at the end of the tunnel. No year we can wistfully mark on the calendar as the date when we can use feature X of the latest CSS spec ("position: fixed;" anyone?). In the last 3 years, the title of the Web's Boat Anchor has been handed off from Netscape 4 to IE 6. Like the dreary days of NN 4.7.x, IE 6 is patched and patched again, but never to fix bugs we care about. With Firefox ascendant, MS had no choice but to restart development on IE in order to prevent it from being relegated to displaying help files in Office via an ActiveX control. The IE 7 team has shown a willingness to be candid about what they will and won't fix, and that much is commendable. Unfortunately, developers of dynamic applications (cough Ajax) have been entirely left in the cold. If Microsoft doesn't commit to fixing the following issues in the near future, no number of CSS rendering updates are going to stem the tide. The problems on the list are by no means simple to address. In some cases, they may require re-architecting large tracts of IE internally. Here's a little hint to whoever is the PM in charge of the renewed IE 7 effort: we don't care. We don't care how much it costs you. We've been cleaning up your messes for years. Those of us tasked with "just making it work" have spent so many sleepless days and nights routing around IE brokenness that our empathy and sympathy are entirely tapped out. All that's left is a combination of despair and loathing. You want us to give a (expletive) that you blog and are "engaging with the community"? Fine. Fix your (expletive) browser. That's the bar the IE 7 team needs to hurdle. I hope they've internalized that.

At a minimum, dynamic web apps need the following out of IE and JScript in the very near future:

If Microsoft is to re-build any credibility around their browser, they need to show us the goods. CSS fixes won't suffice this time around.

Older Posts

Newer Posts