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.
- implementations of a ratified language spec (scheme? lisp? do they even "count"?)
- interpreters deployed (Forth is in every Apple and SUN bios...can that possibly beat the distribution of IE, Firefox, and Safari?)
- lines of code written for said language
Perhaps KSH and/or bash would win? I'm curious to know if anyone can think up other strong contenders.
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.
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.
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 way...so 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 child.example.com but
// have already set document.domain to example.com
var currentDomain = "http://exmaple.com/";
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.
Good luck, and see you at OSCON '06!
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:
- Memory leaks need to simply disappear
- Fix the cache+gzip bugs
- Give us getters/setters in JScript or give back watch()
- Fix the event object. Pass it in to DOM handlers by default. Also, offsetLeft and offsetTop are so ambiguious as to be useless. Give us currentTarget.
- Bump the limit on the number of concurrent HTTP connections if those connections are initiated after onload (either via XMLHTTP or other methods)
- Today, allocating more than 5K objects or so brings JScript to its knees. Object allocation cost needs to be O(1)
- Either revive (and start to fix) VML or give it an SVG-Tiny+DOM facade
- Give us a persistent, string-keyed, local cache in the MB range (5-10MB/domain seems a good start)
- Fast DOM queries. CSS selectors or XPath, we don't care. Just give us a way to say "get us all DOM node objects matching this"
- A way to toggle the box model on a per-element basis without switching doctypes. The CSS 3 box model spec seems a good starting point
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.