- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Really Simple History: Onwards and upwards
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!
Topics: Ajax Bookmarking, Ajax Frameworks, Back Button, Browsers, Firefox, Frameworks, IE, IE6, IE7, Javascript Libraries, Opera, Really Simple History, Safari, Webkit
CSS 3: Multi-column Layout vs. Advanced Layout
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 640x480. (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.
Topics: CSS, Frameworks
The awesome state of JavaScript development tools
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.
Ajax/Javascript Library - DHTMLGoodies
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.
Topics: Ajax Frameworks, Frameworks, Javascript Libraries
An Interview with Dojo Creator Alex Russell, Part II
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.
Topics: Dojo, Frameworks, Interview, Javascript, Javascript Libraries
An Interview with Dojo Creator Alex Russell, Part I
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.
Topics: Dojo, Frameworks, Interview, Javascript, Javascript Libraries
Manageability.org - Open Source AJAX Frameworks with Server-Side Java Support
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.
Topics: Ajax Frameworks, Frameworks
AJAX Framework Browser Compatibility Matrix
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).
Topics: Ajax Frameworks, Echo2, Frameworks, Javascript Libraries, Review, ZK
Echo2 vs GWT
Back on June 6th I made a note of this post by Echo2 creator Tod Liebeck at The Server Side, entitled Comparing the Google Web Toolkit to Echo2, but never got around to blogging about it. Tod gives a fairly succinct description of both GWT and Echo2:
GWT's defining attribute is the Java-to-JavaScript compiler. This compiler allows you to develop the web interface to your application in Java, then compile it to JavaScript. GWT limits the developer to a subset of the Java 1.4 libraries. GWT applications can be served by any web server, such as Apache, without the need for server-side processing.
Echo2 applications are compiled to Java byte code and run on a Java server. Their Java code is executed by Echo2's "Web Application Container" layer, which sits atop a Java Servlet. On the web browser, the Echo2 "Client Engine" communicates user input to the Web Application Container via AJAX requests, with the server responding with directives to perform incremental updates to the state of the client web browser.
He goes on to analyze other points of comparison, including architectural, performance and legal issues. A good comparison by one of the AJAX worlds leading developers.
One thought here is that many folks have held out a GWT as a tool for writing widgets for other frameworks such as ZK and Echo2. I've been going through the Javascript infrastructure of GWT and it seems there's a whole lot of plumbing that stands in the way of making this a reality. More on this later.
Topics: Ajax Frameworks, Ajax Performance, Application Architecture, Frameworks, Google, GWT, Review
GWT Libraries Released - XML, SOAP, Crypto, Amazon, etc.
Openfount has released a beta of a set of libraries and tools for use with GWT. The web services parts of these work in conjunction with their queued server. This queued server basically acts as a proxy for XMLHttpRequest's. So, if you want to access web services from Amazon but you're loading your Javascript from another server, you can proxy the request through your server. There's a bit more to it, but that's the jist of it.
Looking at their Open Source license, I'm not sure it smells that good, but IANAL.
Update 1: I've had a closer look and have even more second (or should I say third) thoughts on this package.
Topics: Ajax Components, Ajax Frameworks, Ajax Products, Ajax Widgets, Frameworks, GWT, Open Source
OpenLaszlo Developments Afoot
One way that AJAX frameworks are going to be embraced is by providing lots of widgets. Another is by signing up other companies to develop applications using their framework. Nothing spells credibility than working software. To that end Laszlo Systems has announced that someone's going to be adding more oomph to their email software product built using OpenLaszlo:
Laszlo Systems, developer of OpenLaszlo, the leading advanced open source
platform for building and deploying Ajax applications, and Goodmail
Systems, creator of the CertifiedEmail system for trusted email, today
announced that Laszlo Mail will support the recognition and presentation of
CertifiedEmail messages. Offered for license to businesses and
communications service providers, Laszlo Mail delivers the functionality
and responsiveness of desktop email without requiring any client software
installation. Now with CertifiedEmail, Laszlo Mail will have the added
benefit of protecting users from phishing and other forms of email-based
fraud.
Hmm, the former Flash product is now "the leading advanced open source
platform for building and deploying Ajax applications." Last time I looked at their source tree it didn't do DHTML yet.
Another GWT Tutorial
Update: I've posted 36 GWT Tutorials, a more up-to-date list of GWT tutorials.
I know I promised this would be ZK week, but my code reading is going a little slower than I expected. So let me work in some more news about GWT. I know, I know, you're sick of GWT (or maybe you're not). But there's a nice new tutorial over at java.net. It's called Kickstarting Google Web Toolkit on the Client Side and it provides, in increasing order of sophistication, three example GWT applications: a simple "Hello World!" app; an amusing Zork type adventure game ("unlock door", "go north", "read plaque", etc.); a cool little animation made up of a few simple yet effective pieces.
This is probably the best GWT tutorial I've see to date as it actually tries to do something beyond flinging around some labels and text fields. Of course, the tech publishers are probably hard at work on a book that builds a non-trivial application with persistence and rich features. This will have to tide you over until then.
Topics: Ajax Examples, Ajax Frameworks, Frameworks, Games, GWT, Tutorials
Welcome to ZK Week
This week I'll be focusing on the ZK framework. It is one of two server-side component GUI frameworks in the Java AJAX universe, the other being the Echo2 framework.The basic idea behind these server-side frameworks is that you write web applications just like you write desktop GUI applications:
With ZK, you represent your application in feature-rich off-the-shelf XUL and XHTML components, and manipulate them by listening to events triggered by users, as you did for years in desktop applications. All your application codes are running at the server, while the visual representations of components and user activities at the browsers are automatically synchronized by ZK.
Though the idea is to write webapps like desktop GUI's, ZK applications are deployed as standard servlet-based webapps -- just edit the web.xml file, import in the zk libraries, add a few .zul files (ZUML) to the web content and package up as a WAR file.
Overview
A ZK application consists of two parts: a client-side Javascript engine and a server side Asynchronous Update (AU) engine. They interact something like in the following sequence diagram.
The developer's guide gives the following execution sequence:
-
When a user types an URL or clicks an hyperlink at the browser, a request is sent to the Web server. ZK loader is then invoked to serve this request, if the URL matches which ZK is configured for.
-
ZK loader loads the specified page and interprets it to create proper components accordingly.
-
After interpreting the whole page, ZK loader renders the result into a HTML page. The HTML page is then sent back to the browser accompanied with ZK Client Engine.
-
ZK Client engine sits at the browser to detect any event triggered by user's activity such as moving mouse or changing a value. Once detected, it notifies ZK AU Engine by sending a ZK request.
-
Upon receiving ZK requests from Client Engine, AU Engine updates the content of corresponding component, if necessary. And then, AU Engine notifies the application by invoking relevant event handlers, if any.
-
If the application chooses to change content of components, add or move components, AU Engine send the new content of altered components to Client Engine by use of ZK responses.
-
These ZK responses are actually commands to instruct Client Engine how to update the DOM tree accordingly.
You create the UI by writing ZUML files, an XML-based language for specifying the composition of ZK pages and components as well as Java snippets to specify behavior. Here is a simple example of a tabbed pane in ZUML:
<window title="tabbox demo" border="normal">
<tabbox width="400px">
<tabs>
<tab label="Tab 1"/>
<tab label="Tab 2"/>
</tabs>
<tabpanels>
<tabpanel>This is panel 1</tabpanel>
<tabpanel>This is panel 2
The second panel</tabpanel>
</tabpanels>
</tabbox>
</window>
This ends up looking like this:
ZK is just a presentation framework, i.e. you'll have to write all of the business and persistence logic yourself. But it does do quite a good job of providing you with off-the-shelf components and effects:
- Embedded, popup and modal windows.
- Tabbed panes.
- Calendar selectors
- Text input with constraints
- Various kinds of select and combo boxes
- Sliders
- Layout components -- group boxes, splitters, accordions
- Menus and toolbars
- Tables
- Trees
- Drag and drop
- Tool tips
- Context (right click) menus
- Async updates via Timers
Strengths
ZK's biggest strength is the jump in productivity that web developers are going to experience in switching over to the component GUI model, but it does have other advantages:
- As with any server-side widget framework that uses the bridge pattern, ZK decouples the rendering logic from the presentation logic. That means that they can retarget applications to devices other than the browser, such as desktop/swing or -- as Potix has announced -- a version for mobile devices.
- Timer component makes async update a breeze. You still have to pay attention that your server side logic doesn't run too long as "Events for the same desktop are processed sequentially. In other words, an event handler will block any following handlers."
- Doesn't try to reinvent the wheel. Makes use of existing Javascript frameworks, such as Prototype and Dojo. Eases integrating prototype-based Javascript widgets.
- ZUML makes it easy to build complex component trees. It also shortens the edit-compile-test cycle for developers.
- Allows developers to keep their business logic on the server side.
- Macro components -- components written in ZUML and composed from other components -- make it easy to build up more complex UI elements.
Weaknesses
There are some weaknesses as well, but most of them have more to do with platform maturity rather than design flaws:
- Documentation of both the Javascript engine and the method for writing new custom components is lacking.
- No IDE support.
- User interface state is stored in the client session. This can result in quite a bit of memory being used on the server-side, especially if lots of data and controls are combined.
- The lack of reference applications and tutorials make adopting best practices difficult.
- Look and feel is hard to control. At the very least, the details of how to change the standard "chrome" of windows, buttons, etc., needs to be documented.
- There appear to be some layout problems in some components, with slider controls floating outside of their expected positions. Could be stray positioning typos in the code.
Tomorrow we'll look at ZK from an architectural viewpoint and see how it holds up from a performance, reliability and scalability perspective.
Topics: Ajax Frameworks, Frameworks, ZK
IDE Watch - GWT Plugin for IntelliJ
On Tuesday, Alex Tkachman over at Jetbrains announced that he had developed a plugin that adds support for Google Web Toolkit (GWT) to IntelliJ. As he says, it's only a "first prototype yet but it definitely gives an idea about direction we are targeting." There is more information and a watchable demo here.
I don't use IntelliJ myself, but from the demo it appears to perform a number of useful functions:
- It does all of the messy setup of the GWT Eclipse project and application creation for you.
- It allows you to create several GWT entities via menus: Module, Entry Point, Remote Service (client and server side classes), and Serializable classes.
- It allows you to edit Java and Javascript in the same editor window.
- It will detect use of undefined CSS styles in your Java code and allow you to automatically create it in the module's style sheet.
- It will both launch the GWT application runner and compile the Javascript for you.
All of this isn't exactly earth shattering, but it does take some of the tedium out of developing with GWT. The automatic creation of a Remote Service with it's three files (shades of EJB) is especially nice.
I didn't see anything in the demo about deployment, however. It would be nice if IntelliJ were to package the application up in a nice WAR file, ready to go. I've been tinkering with an Eclipse plugin for GWT. Mine just builds the application skelleton for you right now. Maybe I have to aim a little higher.
Topics: Ajax Frameworks, Ajax Tools, Frameworks, Google, GWT, IDE, Web/Tech
Example GWT App - Newsletter Signup
I decided to try out GWT on a simple project: providing a small newsletter signup box on a conference micro site. The idea was that after checking that a valid email had been submitted -- and complaining with a DHTML popup if it wasn't -- that email would be sent to a backend web service (asynchronously, of course). While the async XHR request was percolating, the newsletter box would display a thank you message, then fade away. A cookie would also be set, preventing the newsletter box from displaying during the lifetime of the browser session.
This just barely qualifies as AJAX, since I'm doing just one crummy little "Hello World!" communication with the backend. Still, it gets rid of the whole painful navigation to a signup screen, so that's a win in the AJAX column.
OK, so just 150 lines of code later (yeah, I know), I have my little box. The site is software500.pathf.com where you can see the newsletter box in the bottom right corner. Please be kind and don't sign up your goofy friends.
A few lessons from the excercise:
- GWT doesn't remove the need for Javascript. I found myself writing a few funky methods like this:
public native void setCookie(String cookie, String value) /*-{ document.cookie = cookie + "=" + escape(value) + ";Path=/"; }-*/; public static native String getLocationHref() /*-{ return $wnd.location.href; }-*/; - The GWT documentation is not complete. What is does talk about is pretty solid, but the fact that Google is not a shrinkwrap software company is pretty evident. Let's hope they hire some gifted technical writers and such for the general release of GWT.
- Debugging in the hosted mode is pretty handy. Not that an application of this simplicity needed a whole lot of debugging.
- One of the gaps in documentation is that it isn't very task based. Suppose you have a question like "How do I include a third party jar file?" You can dig through the documentation site and maybe come accross an explanation of the syntax of the MyApp.gwt.xml file and on another page the directory structure of a GWT project. Putting the two together takes a bit of noodling. That's definitely a steep start to the learning curve that doesn't need to be there.
- Spend some time with the more essoteric parts of the documentation, like how to write modules. Also, take a spin through the gwt.js file and see how it parses the gwt meta tags. This will ease your pain down the road when your GWT app and html page sit in different directories.
In my previous article on GWT Developments, I've pointed out several good resources for getting started, including the GWT newsgroup. Make liberal use of them.
Topics: Ajax Components, Ajax Examples, Ajax Frameworks, Ajax Tools, Design Patterns, Frameworks, Google, GWT, Patterns
About Pathfinder
Recent
- Selling Git on the Business End
- IE8 Beta 2 Released
- Faster JavaScript for Firefox 3.1 Thru JIT
- Implementing linked multiselects with jQuery, LiveQuery, and Low Pro: Part 2: First pass at the actual code
- I’m Cranky Because I’m Not Getting Enough REST
- Flex Gauge Component Example with source
- Plugging Some Cool Tools
- Implementing linked multiselects with jQuery, LiveQuery, and Low Pro: Part 1: Requirements and interaction design
- Many Varied Components, or… Multi Variable Complexity, or… Mainly Vanilla Coding
- Custom Flex 3 Lightweight Preloader with source code
Archives
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Topics
.NET
3d
3D GPS
Accessibility
actionscript
activerecord
Add new tag
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Frameworks
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Analysis
Android
Announcement
Announcements
antennae
Apollo
Application Architecture
Application Development
ASP.NET
Asynchronous Processing
awards
Back Button
Benchmarking
Best Practices
BitmapData.draw
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business Reasons for Ajax
Business Rules
C#
Canvas
Case Studies
Chicago
CMS
COBOL
Code Generation
Color
COMET
Conference
Consistency
Content Management
CRM
CSS
Custom Flex Component
Degrafa
Design
Design Patterns
Desktop
Desktop RIA
Developer's Notebook
Diagnose
Dojo
Domain Knowledge
Drools
Echo2
Echo3
Editorial
ERP
Ethnographic Research
Ext JS
Facebook
FileReference
Firefox
Firefox Extensions
Flash
flash awards
flash player 10
Flex
flexunit
Flow
Frameworks
front end
front end development
Games
Gauge Component
Git
Google
Google calendar
Google Gears
Grails
Graphics
Greasemonkey
Groovy
GStreamer
Gwittir
GWT
Healthcare
Hibernate
IDE
Ideation
IE
IE6
IE7
IE8
ILOG JRules
Information Architecture
Innovation
Instructional Design
Interaction Design
Interview
iPhone
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSR-94
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
MetaWidget
Methodology
Microformats
Microsoft
Mobile
Mootools
Mozilla
Music
MVC
MySql
Object-Oriented