Archives

I’ve just come across Yahoo’s new home page, which features a clean streamlined look, the ability to add your favorite pages as links right on the homepage, and most interestingly, a module that gives you access to (a subset of) your Facebook account. This module, which appears when you hover your mouse over the Facebook link on the let hand side of the page, will–after sign in–open up your facebook friend feed right there on the Yahoo home page.
Apparently Facebook has been giving third party websites the ability to connect to their users via Facebook for 8 months now (through a set of API’s collectively called Facebook Connect). But the Yahoo home page is the most high profile example yet. This is certainly the first time I’ve come across it.

The benefits of Facebook connect Facebook is obvious. It’ll gather more information about its users, and become more ubiquitous within the wider web, as users remain connected to its platform even while not actually on the facebook.com.

Last week, Karega Scott made a nice post on how Pure MVC makes development of Windows applications using C# simple. I thought I ll piggyback on this post and share some of my thoughts regarding this popular framework. I think the framework, if understood completely and adopted intelligently, has to offer some really cool benefits like :

• Light-weight messaging mechanism (using Notification/Observer patterns) between different parts of the application without having to create custom events/hooks all over the place.
• Highly Decoupled Components allowing abstraction and seperation of logic.
• The application’s testability is enhanced greatly because of the reason stated above.
• A Centralized singleton Facade component that mediates between the different components in the application.
• The use of commands in the framework can help in building complex applications that need to perform several different UI-driven functions.

I’m excited to announce that I’ve heard the call and volunteered to tackle maintenance and stewardship of Really Simple History, Brad Neuberg’s intuitive, lightweight Ajax history library. Brad developed RSH a couple of years ago, drawing inspiration from the Dojo Toolkit folks to deliver a standalone library that provides back-button and bookmarking support for Ajax apps in IE6 and various Gecko-based browsers. Since, then, many additional Ajax frameworks have implemented back-button and bookmark support, some of them drawing on Brad’s work.

Meanwhile, Brad’s been too busy with other projects to upgrade RSH for a variety of new and existing browsers: IE7, Opera, Safari/Mac and Safari/Windows. I asked Brad to let me take care of his baby for several reasons. For one thing, I’ve been an enthusiastic user of the library. For another, I’ve been wanting to get involved on a more formal basis with open-source JavaScript projects. But most of all, I believe RSH remains a great tool for folks who want a solution to the Ajax history issue without the overhead of a larger Ajax framework.

I’m currently working with Brad to migrate RSH to Google Code, get acquainted with the bug base, and start tackling the thorny issues surrounding Ajax history support in the 2007 browser landscape. I look forward to shamelessly pilfering the many fine solutions uncovered by a large community of developers since Brad’s initial work. (Brad was kind enough to point me to this blog post from Bertrand Le Roy, which lays out many of the aforementioned fine solutions and thorny issues.)

In the meantime, I’d love to hear from RSH users about their hopes for the future of the framework. Comments, please, or ping me directly at bdillard (at) pathf.com. Thanks!

My colleague Sholom Sandalow’s post about multi-column layout in CSS 3 drew a lot of comments and remains one of our most popular articles two months after publication. Folks are obviously hungry for discussion about the future of CSS. Yet there’s still a lot of fuzzy logic out there about where we’re headed.

Viewport dimensions still matter

Lots of pixels have been burned in the discussion of changing viewport specs. But most of the people talking about the advent of very large viewports are probably designers with Mac Cinema displays – NOT average users. As market penetration for super-wide resolutions grows, so will market penetration for portable devices with resolutions at or below the old-school 640×480. (And I’m sorry, iPhone designers, but reading a full-width web page on a tiny screen isn’t actually all that easy on my eyes. I’d much rather see media-appropriate layouts than tons of pan-and-zoom.) My point being: Assumptions about your audience’s screen resolution have always been at odds with the idea of the Open Web. They still will as user-agents proliferate and diversify. As CSS evolves, it must continue to offer us tools to make content attractive and readable on a variety of resolutions and devices.

Multi-column text isn’t a panacea

I also just don’t get the excitement over multi-column text in the browser. Again, this goes back to assumptions about the viewport. One commenter uses this page as an example of good multi-column type that mimics the eventual CSS 3 spec. Yet on Firefox/Mac and IE6/PC, it’s ugly, unreadable or both when you resize your browser to less than 500px tall or 1250px wide. How is this good design?

The main disadvantage of single-column text – that it’s hard to read when the columns are too wide – can easily be solved by strong design skills and smart use of existing CSS capabilities. And the main advantage of multi-column text – that it makes more efficient use of space – ignores the fact that a browser is not a piece of newsprint. Ultimately, print-style columns work in some situations and don’t work in others. They are neither a universal solution nor an antidote to bad web design. They are simply an additional tool in our CSS arsenal – one useful mostly in print stylesheets. It’s nice that this basic layout feature is finally coming to CSS, but it’s hardly the most exciting part of the CSS 3 roadmap.

Advanced layout: Finally, something to get excited about

No, my favorite CSS 3 spec is the Advanced Layout Module. (Thanks to my buddy Zack for alerting me to its existence.) This "concept album" exploring advanced layout strategies recently received its first refresh since 2005 (discussion here). For anybody who’s ever struggled with CSS layout, there’s a lot to love in this proposed templating system. Basically, the spec calls for a new type of display that combines the best aspects of table-based and float-based layout but provides far more flexibility than either. Of course, implementation is a far-off dream, and many aspects of the proposal haven’t yet matured. But the Advanced Layout Module proves that the standards bodies are attempting to tackle the big picture of CSS layout rather than the little details.

In the meantime, several frameworks and techniques have emerged to tackle the problem of cross-browser, grid-based layout. Notable examples include the following:

• YUI Grids
• YAML (Yest Another Multicolumn Layout)
• Blueprint CSS
• Switchy McLayout: An Adaptive Layout Technique

I’d be interested to know who’s using these tools, how userful they are, and whether they provide the same advantages as JavaScript/Ajax frameworks – that is, less time spent reinventing the wheel and more time creating great websites and webapps. As always, weigh in on the comments.

Dietrich’s post on the depressing state of IE develpment tools got me to thinking about the generally wonderful state of JavaScript tooling. Compared to just a few short years ago, we’ve got a wealth of productivity-enhancing browser add-ons, TDD frameworks and static-analysis tools at our disposal – most of them open-source. For those who want to get their hands dirty writing POJ, this is a golden era.

Like most developers, my code circa 1998 was filled with commented-out alert() statements. I spent way too many hours cursing IE4′s inability to report accurate line numbers in its error dialogs. I relied heavily on Netscape’s built-in debugger. Within a couple of years I had graduated to a primitive logging utility that spawned a separate browser window and output messages into it using simple DHTML. At the time, it seemed like a huge advance.

Then came the Firefox era, with its host of disparate add-ons. You could edit your CSS in the sidebar, selectively disable JavaScript and CSS, inspect the DOM …. Once again, the possibilities seemed endless. Now, thanks to Firebug, most of my grab-bag of browser add-ons are gone. Firebug is so powerful and wide-ranging that the only other add-on I use regularly is the venerable Web Developer Toolbar. Yahoo’s new Firebug extension YSlow adds some really useful optimization benchmarks to the suite. When a plug-in begins to spawn its own plug-ins, you know you’ve got a winner.

I’d be interested to know, though, what kind of process UI developers use to debug their JavaScript. Most of us are using similar tools, but how are we using them? (That’s an invitation to jump in on the comments, folks.) Every UI person I know develops prototypes in Firefox and Firebug, crossing his or her fingers that there won’t be too many implementation-specific issues to tackle in the other browsers. Many rely on a logging utility – heir to that long-ago popup window – to grind away at any such browser bugs.

But beyond that kind of hunt-and-peck debugging, have we arrived at an industry-standard practice for client-side code maintenance? Who’s doing true TDD with one of the flavors of JsUnit? Who’s using Selenium to test their entire webapp in the browser? Who’s picking apart the details of their syntax with Douglas Crockford’s JsLint? Who’s busting out Fangs or another accessibility test tool on a regular basis? The tools are out there. It would be interesting to know who’s using them, and how.

When you’re banging your head against a wall trying to figure out why a certain DOM element won’t return the same node type from one browser to the next, it’s easy to see why there are a hundred competing Ajax frameworks promising to solve all your cross-browser issues for you. Let’s just remember how far we’ve come – and how important it is for real-deal UI developers to maintain the skills that they’ve honed for over a decade. The more trust we put in frameworks, the more helpless we’ll feel when our code fails and we’ve lost the ability to figure out why.

If you want to spruce up your vanilla webapp or site but don’t want the bother of adopting a full framework, you may want to look at the Javascript/AJAX library site DHTMLGoodies. What do they have?

• A folder tree with drang-n-drop
• Several image slideshows
• Ajax tooltip widgets
• An Ajax blindfold chess trainer
• Automatic left hand nav based on page content

There’s a ton of these, plus tutorials, tips and tricks. Check it out.

Technorati : ajax, dhtml, javascript

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

A case can be made that Dojo is the single most influential framework in the Ajax universe. Any time I talk with Ajax developers about frameworks, the discussion always turns to Dojo. Even other framework developers take their hats off to the amazing work done by the guys at dojotoolkit.org, and many of them include Dojo as a part of their own frameworks.

I had a chance to talk with Alex Russell, one of Dojo’s creators, about the framework’s success and future. Alex had plenty of interesting things to say, so I’ve divided the interview into two parts. The second part will be posted tomorrow.

Dojo Background

Q: Alex, what’s the history of Dojo? How did it come about? Who was involved in it’s creation?

A: Dojo was the result of some fortuitous hiring by Informatica. They had already pulled me away from a job in security to help make their web-based BI (business intelligence) product more responsive and another team “needed an Alex”, so I got in touch with most of the folks I knew from my days hanging out in comp.lang.javascript and on Dan Pupius’ excellent DHTMLCentral.com. It turned out that, like me, most everyone had gone and gotten “real” jobs since no one wanted to pay a bloke to sit around and make things dance on a webpage in 2003. Getting back in contact with everyone inevitably started discussions. There was a sense of doom at that time around DHTML and JavaScript. Everyone had (re)invented the same things multiple times and I started to realize that at some point people reach a “personal effort radius”. Even for people as persistent as DHTML hackers, there’s a limit to how far one person can push something and in those day we only really shared code snippets and techniques. There weren’t any “canonical” libraries despite many attempts (including my own) at it. The market didn’t see a need.

The upshot of these discussions was a new mailing list which has subsequently become the Dojo contributors list. The original folks early on the list were Aaron Boodman, Dylan Schiemann, Tom Trenka, Simon Willison, Joyce Park, Mark Anderson, and Leonard Lin.

Fast forward to early 2004 and Dylan Schiemann and David Schontzler were also at Informatica and just as David was heading back to school we started on a new project that looked like it would need good SVG support. We needed a library that would be portable between environments, and Dojo was born. Retrofitting netWindows just wouldn’t work. It was far too HTML specific. We tried to make a case for writing Dojo while working on this project and got some initial support, but in the end it was the folks at JotSpot and Renkoo that really helped push the project forward in the early days through their generous support.

By the time we had started on the new project at Informatica, we had gotten some momentum on the mailing list to try to combine all of the tools everyone had laying around. We set about to build a Standard Library for JavaScript. The original intent (and something we still hope to do today) was to get the best code and approaches from the community and boil them down into a single package.

We got all the IP donation stuff sorted out and it was off to the races.

Q: And the name “Dojo?”

A: The name “Dojo” came about because I had received a Cease and Desist from Microsoft when they noticed that my one-man DHTML project — netWindows — had the word “windows” in it. Of course, you can’t appropriate a word out of the language, no matter how much money you throw at it, but Microsoft seems to think they can. When we went to name the project it was decided that we should pick something less likely to get us sued, so Leonard Lin proposed “Dojo,” and compared to all the other dreck that was being suggested, it won easily. Naming things well is hard!

Obviously the recent past has lots to do with Ajax, Jot, IBM, Sun, the general dynamic-languages renaissance, but I’ve blabbered enough on this, and everyone always loves the creation myth more than the hard work parts anyway.

Q: What exactly was netWindows?

A: It was my first attempt at a DHTML library. It included things like a widget system, a theme system, a signals-and-slots event system, some useful widgets and a pre-XMLHTTP IO infrastructure using a request queue built on top of Iframes. There was even a primordial build and compression system. Some of the stuff in netWindows, like a generic focus manager, still haven’t made their way into Dojo yet. Luckily we all got a chance to “reboot” with Dojo and take only the best parts out of netWindows, Burstlib, f(m), and some other codebases that have been donated along the way.

Dojo Strengths and Weaknesses

Q: What would you say are the strengths and weaknesses of Dojo?

A: We’ve got amazing infrastructure to support for folks who know and appreciate JavaScript as a language and know what they want out of a toolkit. Dojo is a set of layered libraries and a lot of folks love the ability to pick just the bits the like and ignore the rest, and while that’s a strength for the folks who need that much power, it’s a liability for everyone else.

In terms of weaknesses, the obvious answer is “documentation”. We have a communication problem around trying to get the word out about how Dojo is layered and how to use it in real-world scenarios. We’re working on those things, but some of it is inherent in trying to build something so broad within the constraints that the web imposes.

Q: Dojo has been criticized as being too heavy. How do you respond to that?

A: I’d respond “what are you trying to get done?”

In a lot of cases people assume that Dojo is some kind of monolithic thing. They download a release and go “OMG! It’s huge! all these files, where do you start?” and I sympathize with that. In the past we’ve discussed breaking things up, but then you have the problem that a lot of other folks have today which is that you dump the problem of assembling the right versions of all these different things that work together and load in the right order onto the end developer.

The package and builds systems lets us avoid most of that, but we still ship the “src/” directory so that if you want some part of the library that’s not part of a build, you can just say dojo.require("dojo.someModule.*"); and you can trust that it’s going to work, that all of its dependencies will get loaded in the right order, and that you can make it faster later if you need to by dropping unnecesarry code.

We know of some people who use just the package system (around 20K, built) and people who do entire application UI’s as Dojo widgets, and the system scales to both extremes. We ship the various profiles to give people people a head-start, but the system is flexible to the core. So the answer to the question is: Dojo is as heavy as your application requires and your interest in “right sizing” it lasts.

Q: What is your favorite feature of Dojo?

A: Hard to pick, but since I have to pick I’ll say the build/package system. I hate Ant and I’m no lover of Java, but they’ve allowed us to solve a very hard deployment problem in a way that doesn’t require anyone to change their code. Just make a build, point your app at the new “dojo.js”, and your app loads that much faster. I love things that let you start developing fast up front and put the work of “making things fast” a deployment issue, where it belongs.

Q: There are client-side, server-side and various other classifications of Ajax frameworks. How would you characterize Dojo?

A: Pure JavaScript. We try to implement generic protocols for talking to servers such that we don’t have a dependence on any particular server-side language or environment. As a result we’ve grown things like great JSON-RPC support. Of course, we don’t have a strong identification with a particular group of developers the way Prototype/Scriptaculous or Atlas do, but that’s fine by us. In our experience most good developers write in multiple languages on the server side, so why shouldn’t their favorite JavaScript tools be portable? We’ve always had a mantra that I borrowed from Joe Kraus and modified a bit: “optimized for adoption, not control.”

Q: What do you see as being the biggest competitor to Dojo?

A: Short term, the closed-source frameworks like Backbase and Bindows probably have the same breadth and depth as Dojo. Longer term, I think that we’re in for an interesting time in figuring out if they’re all anachronisms in the face $serverSideLanguage -> JavaScript “compilers”. GWT doesn’t make any sense to me since it’s a less-powerful language being transformed into a more powerful one, but Python to JS and Ruby to JS look like real competition.

Q: Why do you say that Javascript is a “more powerful” language than Java?

A: Oh boy, I’m gonna get in trouble with this one.

Before I get into it, let me say that I write a lot of Java myself and don’t view Java and JavaScript as being in opposition, and even less so with the introduction of Rhino into Java 6 (Mustang). Pretty soon most Java developers will get the language advantages of JavaScript with the library support of Java. The best of both worlds.

As a language, JavaScript is still horribly misunderstood. All real power in JavaScript comes from understanding closures, the “everything is always mutable” property, and the prototype chain. These are foreign concepts to Java developers who don’t have FP or scripting backgrounds.

Even those that do, don’t often recognize JavaScript as a language of that type. It’s quite a good chameleon in that whatever you think it is, it’s probably also that (or can be made to look like it). Making matters worse, there are a lot of idioms that the JavaScript community has cobbled togeather over the years to build classes that have some of the same properties as what’s found in class-based OO, but fundamentally JavaScript is a different beast.

JavaScript is a functional language trapped in C-style syntax. It allows you to compose logic in ways that languages like Java generally require bytecode or precompiler antics to achieve. There has been some work in the Java world to introduce more powerful, more generic and more composable building blocks (e.g., jakarta commons-functor, but even that seems to have fallen into disrepair). In the end these efforts are always working against the grain of the language and even if they weren’t, they face a similar comprehension gap among Java developers.

The JavaScript style of data hiding via closures is the flip-side of class-based OO: instead of having instantiable data structures that carry around behaviors, closures are behaviors that carry around their data with them. Thanks to the prototype chain and some magic in the “new” keyword, they can be made to look like class-based OO from a distance, but that illusion breaks down pretty quickly. Most Java programmers just assume that JavaScript is somehow “broken”, when in fact it’s just providing more abstract primitives for getting at the same end goals. Consider this highly contrived code:

function getThud(){
return this["thud"];
}

function ClassFoo(){
this.thud = "xyzzy!";
}

ClassFoo.prototype.getThud = getThud;

function ClassBar(thudValue){
this.thud = thudValue||"default thud";
// constructor assignment
this.getThud = getThud;
}

fooInstance = new ClassFoo();
alert(fooInstance.getThud()); // will be "xyzzy!"
barInstance = new ClassBar();
alert(barInstance.getThud()); // will be "default thud"

// prototype extension affects all existing objects
// of a class as well as new ones
ClassBar.prototype.getThud = function(){
return "prefix plus "+this.thud;
}

barInstance2 = new ClassBar();
alert(bar2Instance.getThud()); // will be "default thud" (!!)
barInstance3 = new ClassBar();
delete barInstance3["getThud"];
alert(barInstance3.getThud()); // will be "prefix plus default thud"

The implementation of logic can be promiscuous but object and closure scope can be used to make things immutable. The Ruby guys call this “open classes”. I’m sure this code example will make strong-OO folks shudder in horror. OMGWTFBBQ! What if the implementation changes? How does anyone know that getThud is a member of ClassFoo? What about API versioning? Closures give us answers for all those things too but I’ll leave that for another time.

The upshot of closures, the primality of the function object, and the prototype chain is that it’s possible to better express your intent as a programmer in less space than Java and without resorting to syntax or contored class hierarchies. The language is just more supple. It bends more easily to your will.

There was a fascinating paper by Lutz Prechelt in 2000 entitled “An emperical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl”. Among a representative sample of programmers, he found that scripting languages produced better performing programs that used less resources and required roughly half as much code as their Java equivalents.

Scripters lost out big-time in I/O (expected) and C and C++ developers could turn out code that beat all, but not with as much reliability as the scripters. The scripters on the other hand beat everyone for productivity despite roughly static LOC/hour productivity between the programmer populations. Takeaway?: if you’re a decent programmer but want to look freaking brilliant, use a scripting language in a Java shop.

The paper wasn’t a “do the same thigns the same way” kind of benchmark, it was a sampling of how programmers think about the problems they’re presented with given the facilities of the various languages. In the 50′s there was this paper called “The Magical Number Seven, Plus or Minus Two” that outlined the limits on human capacity for keeping things “on the stack” when solving problems. The limits are just as real today, and the mildly functional programming style that most scripting languages expose adds new tools for managing and encapsulating complexity to the programmer’s toolbox. OO clearly isn’t going away, but single-paradigm languages seem to be at a statistical disadvantage. I think we’re seeing a realization that 20 years into the experiment, strict OO design is not the be-all and end-all of complexity management. Functional programming probably isn’t either.

The hybrids (Python, Ruby, JavaScript, etc.) seem to have real legs these days. Luckily for the Java world, Sun is finally adding good scripting interfaces to the language. They’re 5 or 6 years late to the party, but it’s a big improvement for the lot of Java devs none the less.

JavaScript is poised to become a productivity shot-in-the arm for Java.

I can’t wait to see how it plays out. Will Sun have the foresight and political will embrace the future? There were signs of it at JavaOne this year, but it was fleeting. From what I can see, the church still has the state cowed and functionally imobilized.

Tomorrow: Other frameworks, security and future plans for Dojo.

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

Manageability.org has a great list of AJAX frameworks with Server Side support. I think I’ve mentioned this before, but manageability.org is a great resource for developers explorting open source Java.

Musing from Mars has published an update of his Ajax Framework Browser compatibility review. It’s not a framework review but rather a rating of how compatible these frameworks are with all of the major browser versions. His grading scale is simple: the more versions of browsers you support, the better. See below.

A - IE 6, Firefox 1.0, Safari 1.2, Opera, Other DOM-compliant
B - IE 6, Firefox 1.x, Safari 2.x, Other DOM-compliant
C - IE 6, Firefox 1.x, Other DOM-compliant
D - IE 6, Firefox 1.5
E - IE 6

I’m not sure I agree with his grading scale (what grade does a framework that only supports Opera get?), but no matter. Some information is better than none. Some of the highlights? Echo2: A; ZK: D+ (Safari problems and insufficient testing); Tibco GI: E (tied to IE with very lame Firefox support).