An Interview with Dojo Creator Alex Russell, Part II

Dietrich Kappe, Thursday, August 17, 2006 @ 9:00 am

Today we have the continuation of the interview with one of Dojo's creators, Alex Russell.

Ajax Challenges and Other Frameworks

Q: What do you see as the biggest challenge to Ajax and its further adoption?

A: Development of good, webish interface idioms and continued browser improvement and adoption. I'm excited that Microsoft is releasing IE 7 through windows update in a meaningful way, but unless we get a commitment from Microsoft to do the same thing for subsequent releases then I fear that dynamic in-browser apps will become a dead-end, held back primarily by the limitations of IE as a platform. From the scripter's perspective, IE 7 is a sub-point release -- clearly not nearly good enough.

Thankfully the Mozilla Foundation and Corporation are doing some great work in finally restarting some real competition.

Q: I have to ask the obligatory GWT questions. Is it a threat? A complement? Can it be used to integrate with Dojo or even write code for Dojo?

A: In order: Yes, yes, and yes.

Dojo is a set of client-side libraries that could be used with any server-side environment, including GWT. Since GWT is very squarely closed source and is tied to a single server-side language, we probably won't be the ones to write Dojo wrappers for it, but we hope that someone will (and we encourage them to!). It might come to pass that a huge library of stuff gets built up in the GWT community such that Dojo is entirely irrelevant. It's as likely as not. Interesting times ahead.

Q: Do you have any sense of how widely used your framework is?

A: We recently pass the 100,000 download mark for our last release, but we really have no way of knowing. Lots of server-side frameworks are starting to integrate it and therefore distribute it down to other developers who may or may not know or care that they're using Dojo. And we're all for that. Optimize for adoption, not control.

Q: What do you think of the server-side Ajax frameworks like Echo2 and ZK?

A: They're great, and we hope that more of them will integrate Dojo. We look forward to working with their developers to help them improve the developer and user experiences they deliver.

Q: Aside from Dojo, what is your favorite Ajax framework?

A: MochiKit. YUI is great code too, but MochiKit has it beat for clarity of vision and implementation quality. Bob Ippolito gets the constraints of the web. That, and I'm a Python guy at heart.

Security

Q: With various worms and viruses making headlines, the press is pointing the finger at Ajax as the culprit. You've said in the past that the fundamental causes of browser security problems haven't changed in the last few years. Still, there seems to be an uptick in Web 2.0 security exploits. Is that an accurate perception, and if so, why?

A: We're starting to see some new applications of old attack techniques, and in some cases like Jeremiah Grossman's new work, even some new techniques, but all of these things are predicated on the browser's assumption that all code running in the page sandbox is equally trust-able, and that hasn't changed and doesn't show signs of changing.

I'd welcome work on improving JavaScript as a language and browser implementations to support further application-controlled sandboxing and data hiding. The same-domain policy is far too coarse grained a solution for the applications we'd like to be able to write.

Comet

Q: You've done a lot of work on COMET lately. Tell me why you think polling isn't good enough.

A: Latency, load, and complexity. IM with a 5 second lag feels more like SMS than a real conversation. Also, systems that satisfy poll requests with a traditional process or thread model responder infrastructure have to throttle back the polling interval which again hurts the conversation. At that point, you wind up with folks trying to build notification queue infrastructures that are highly specific to their web server stack. At that point, wouldn't they have been better off with an HTTP stack that could just handle Comet?

Thankfully most things are gonna be there soon. The big challenges now will be at the application language layer. PHP and Ruby generally rely on process-level data isolation which translates into huge overhead for having lots of requests in flight. Twisted Python, Erlang, Java+continuations, and C# async network responders all can get around this pretty deftly, but making legacy code bases work with this stuff presents a challenge no matter what. We're trying to solve this in cometd by making the protocol stone stupid so that any language can have a client library that throws events at the event router (which may or may not be in-process or on the same box) for low-latency dispatch to the subscribed listeners.

Q: Wouldn't it be better to push for a protocol that was better suited to the task than HTTP?

A: I have tremendous respect for HTTP and for the challenges of getting anything new both into browsers and then out to users. HTTP isn't going away for this stuff if only because getting something else integrated into the fabric of the web is nearly impossible. HTTP has also shown itself to be highly resilient and extensible. The multipart/x-mixed-replace extension that Mozilla implements (and Safari almost gets right) allows the server to send discrete blocks over a single connection sans hacks. That's the kind of thing that makes me think that HTTP is a good enough tool for this.

Could we do better with raw sockets or some UDP network layer? Of course, but good luck getting that into browsers. There are options for doing this today, but they're all quite exotic and not for the faint of Ethereal-foo.

Q: Given that HTTP is a stateless protocol, many major web sites can get away with deploying firewalls and load balancers that can handle 64k or 128k open connections at a time. Won't COMET force these sites to retool?

A: Yes. But they were gonna need to do that anyway. Now that we can do C10K without too much effort, something was gonna force their hand. The great thing about Comet is that even if they do terminate these connections, you've still got the latency of polling. Worst case, it's neutral in terms of latency.

Q: What is Bayeux and where does the name come from? How does it relate to Cometd?

A: Bayeux is a name that Matt Trout came up with. There's a famous tapestry that chronicles, among other things, the Battle of Hastings, the life of William the Conqueror, and one of the first recorded spottings of Haley's Comet.

Bayeux is now the name of a JSON-based protocol for publish/subscribe event notification. It's not a descendant from the Open Source version of mod_pubsub, but in much the same way that we learned a lot of lessons in Dojo from netWindows, we're learning more about where responsibilities in the protocol should be split up thanks to the pioneering work of the KnowNow and CommerceNet folks (among others).

Cometd is a project to implement Bayeux in multiple server and client environments so that we can have easy-to-deploy Comet software for whatever your tastes may be. There are architectural constraints in many environments that will mean that a Bayeux server (possibly Cometd) will need to be run on a high port or on another server and we're trying to address those things in both the Bayeux protocol and in the reference implementations. We've got kind of a janky demo in SVN, but work on an initial draft of the protocol is moving forward at a good clip. I'm optimistic about having code that people can start to play with very soon.

Future Plans

Q: What are the biggest feature requests you are getting from users of Dojo today?

A: Better docs, widget system performance improvements, and whatever widget they love from [insert name of desktop GUI toolkit here]. Widget theming and templating also seem like common requests.

Q: What other web technologies do you think we should keep and eye on?

A: SVG and things that enable occasionally-connected operation. I'm also interested in seeing what Macromedia cooks up with Apollo.

Q: What is the Dojo Foundation? What is it's purpose and who is involved?

A: It's a not-for-profit 501c6 foundation that holds all the licenses for the Dojo Toolkit and OpenRecord projects, and soon the Cometd project. Like other Open Source foundations such as the ASF (Apache Software Foundation) or Eclipse Foundation, the Dojo Foundation provides development infrastructure, legal cover, and community-building tools for Foundation sponsored project.

If we had to do it all over again, I'm not sure we'd set up our own foundation again, but luckily folks like the ASF have dealt with many of the problems and gave us ready answers for some of these. There's an interesting thing with Open Source foundations, though, and that is that they seem to be language-centric. The ASF might be the one big exception in that they have both active C and Java communities, but I think that's the exception to the rule. We're still trying to figure out what we want the Foundation to be when it grows up, but I would be very happy if we can continue to provide a level, vendor-neutral playing field for high-quality web and JavaScript development for a very long time.

Right now the Board of the Foundation is just Dylan Schiemann and myself, but all the real power lies in the hands of foundation project committers. They can call votes on any topic at any time.

Q: How much work is it to support a major browser release like IE7?

A: These days, not a ton. We're lucky to have struggled in vain for eight or so years before working on Dojo so we pretty much knew what to avoid doing. Also, web standards have mostly done their job.

Q: What are your future plans for Dojo?

A: World domination...and trying to figure out ways to slip "a series of tubes" into interviews. Unfortunately we're doing better at the first.

All kidding aside, the road to 1.0 has a lot of hurdles still left to clear. Namely:

• efficient data binding
• a "real" template system
• themes
• full accessiblity support for all widgets
• widget i18n and localization
• generic, cross browser 2D vector graphics
• a more complete and polished widget set
• even more agressive optimization tools
• documentation

We've got active work in most of these areas today thanks in no small part to the support of SitePen, Jot, IBM, AOL, the Mozilla Foundation, and Google's Summer of Code program. That kind of broad community and industry support makes me very optimistic about our future.

Q: One final question -- has working on a high profile open source project been good for your career?

A: Yes. But working on low-profile open source projects was also good for my career. There's nothing like being able to show a potential employer a public SVN repo where they can see what you did or a mailing list where they can see how well you play with others. Potential employers would give appendages to get that kind of information before making every hire.

Technorati : alex russell, dojo, framework, interview, javascript

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment