Topic Archive: Interview

Q&A with Trace Johnson of Chicago-based mobile-payment start-up Mpayy

Brian Dillard, Thursday, January 31, 2008 @ 11:41 am

Chicago isn't Silicon Valley, so it's always interesting to see tech start-ups putting down roots in Midwestern soil. Last night I hit the launch party for Mpayy, a mobile payment start-up that launched just last week. Over a hundred prospective customers, potential investors, and tech and banking professionals hit Fulton Lounge for cocktails, networking and, of course, a product demonstration. Afterwards, I chatted via email with Trace Johnson, Mpayy's product VP, about the launch, the company's future, and the state of Chicago's entrepreneurial culture. (Full disclosure: Johnson and I were once colleagues at Orbitz, one of the Windy City's big tech start-up success stories.)

Agile Ajax: First off, can you tell me the basics about Mpayy? What's the one-minute pitch?

Trace Johnson: Sure, but there are different pitches for consumers, online merchants and mobile merchants:

• Consumers get online and mobile payment processing. Shop online or send money to your friends from your checking account for free and get cash back when you buy.
• eCommerce companies get a secure payment solution with 0% fraud liability and they save 40-50% vs. credit card processing.
• Mobile merchants - taxis, fruit vendors at a farmer's market, Avon ladies, shirt vendors at a concert - get turn their mobile web enabled cell phone into a retail point of sale system.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Songbird powers label-approved P2P download service Qtrax

Brian Dillard, Monday, January 28, 2008 @ 10:35 am

Last week I posted my interview with Stephen Lau, developer evangelist for the Songbird open-source music player. Afterward, I had some follow-up questions, which appear at the bottom of this post.

During my conversation with Lau, he tipped me off to the imminent launch of a new music service that would be white-labelling the Songbird core. The accouncement came this weekend from new peer-to-peer download service Qtrax, which promises major label-approved P2P access to a music catalog of 25 million tracks. The Wired News report on Qtrax provides plenty of interesting background information. But now UK newspaper the Guardian is reporting that Qtrax's music-label support is far from final.

As the music labels continue their quest to usurp the iTunes monopoly, it seems like Qtrax would have as much leverage as any other alternative distribution channel. It'll be interesting to see how this plays out. In the meantime, here are our follow-up questions to the original interview with Stephen Lau

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

GWT a Year Later: Was it the correct level of abstraction?

Dietrich Kappe, Thursday, June 7, 2007 @ 8:43 am

A little over a year ago, Ajaxian published an editorial entitled Google Web Toolkit: The correct level of abstraction? In it, Dion raised some important questions about GWT:

• Isn't debugging generated Javascript going to be messy?
• Wouldn't the large size of the generated Javascript make it's use infeasible?
• Where is all of the cool stuff, like effects libraries, etc.?
• Is generating "assembler" in Javascript really the right level of abstraction?

Now that a year has passed and people have had a chance to experiment and develop with GWT, I thought it would be a good idea to revisit these questions. I interviewed GWT practitioners Dr. Adam Tacy and Robert Hanson, who -- aside from working on commercial projects featuring GWT -- have just finish their first book on the subject, GWT in Action: Easy Ajax with the Google Web Toolkit. They were kind enough to answer a few of my questions.

Debugging GWT code is as easy as debugging any other Java application. Just open up the Eclipse IDE, and launch the application in debug mode - the key is to really harness the power of the Java IDE and tooling to ease debugging. There may be some quirks here and there, but in general it is a very pleasant experience.

An issue that is sometimes raised by newcomers to the tool is the lack of a "debug window" component for the JavaScript (think of YahooGUI widgets, etc.) - but that basically misses the point of GWT where 99% of debugging can be applied to application logic in your Java IDE. If you want to hang onto the "printf/println" style of debugging, then in hosted mode it is possible to log to the hosted mode console. For client side code, GWT could be improved to allow for Log4J style log levels. But why would you do this in general when you have access to the powerful debugger in your IDE?

Once you get out of the hosted browser and deploy the project to your site, if there is still a need for debugging you can use the same debugging techniques as you would with any other JavaScript application. Some of our favorite tools include Web Developer and Firebug, two add-ons for Firefox.

One of the initial complaints from JavaScript developers was that the JavaScript code generated by the GWT compiler is obfuscated, and impossible to debug. To quote the Ajaxian story from a year ago, "I can't imagine how scary it will be to have a JavaScript error show up in a browser talking about line 2123 which has "a[b] = push(c)" in it". The author of that piece missed the rest of the story.

On the few occasions that you have an error that can't be debugged from the Java IDE, GWT gives you the ability to alter the output of the GWT compiler. You can select from two levels of verbosity ("pretty" and "detailed") that will emit JavaScript code that can easily be mapped back to the Java source. Once you have your "pretty" or "detailed" JavaScript, you can easily insert debugger commands to be picked up by a JavaScript debugger. You could use this verbose version of the JavaScript code when you deploy your application to production, but it is usually desirable to use the default mode of the GWT compiler, which is to compress the code as much as possible.

At another level, GWT has a powerful concept called Generators, which effectively auto-generates code for you (GWT itself uses them for its RPC, i18n, and JUnit integration approaches). Generators do get a hook into Log4J style log levels, and when running hosted mode or compiling for web mode you can follow the compiler decisions that led to the generation of code you are using - this leads to an easy way of debugging that, for example, could detect that GWT hasn't picked up the latest locale you added.

We have never had any problems debugging a GWT application - and don't forget, unless you are trying to do something really at the edge of the underlying technology (DOM, HTML and JavaScript), using GWT lets you concentrate on debugging your application logic rather than on browser differences.

The other benefit of GWT is of course the use of a strongly typed language - which reduces the probability of introducing errors in the first place. In our development experience so far, there has only been one occasion where we've had to drop down to JavaScript debugging - and that was really to understand what Opera was doing under one particular circumstance with the underlying DOM!

The tools story for GWT is really incredible, especially if you are already a Java developer that relies on these tools. People often quote the saying "GWT brings AJAX to the tools, rather than tools to AJAX" and tools like Eclipse, NetBeans, Ant, Maven, JUnit, and CruiseControl are all usable for GWT development. There is even a visual editor called GWT Designer from Instantiations that allows you to visually design interfaces the same way you might design a Swing, SWT, or JSF application. Tools like GWT Designer started appearing almost immediately because of existing code and knowledge about writing Java tools.

Then there are the best practices. There are reams of literature written on best practices for object-oriented and Java development. Books like the Design Patterns book by the "Gang of Four" and Refactoring by Martin Fowler can be applied to GWT development. Some of the patterns described in these books can also be applied to JavaScript, but JavaScript lacks things like interfaces and abstract classes, reducing the applicability.

It really is not all about just substituting one syntax with another, together those benefits above have been shown to lead to more maintainable code and make team development easier - otherwise we'd all still be writing all of our applications in assembler - and ultimately these benefits will drive down the cost of web applications/allow more complex applications to be built.

Yes. Assuming the developers for a given project know both Java and JavaScript, the differentiating factor will be the size and complexity of the project. If a few lines of JavaScript will do, then GWT is overkill. For small applications, perhaps a few dozen to a hundred lines of code, the JavaScript code will usually be as maintainable and will be smaller than the equivalent GWT code.

Where GWT really shines is when the application consists of many controls, requires passing complex data between the client and server, or if you want to package widgets and utilities for reuse.

Similar to the scripting language vs. Java debate we expect that there will be some JavaScript developers that couldn't imagine a JavaScript application that was too large to not be maintainable. One of us was a Perl developer in a former life, so we understand the draw of scripting languages, but Java clearly has some advantages for writing larger applications - modularity, easier to implement common design patterns, type safety to name just a few. There is also still a need for deeply technical JavaScript developers - it is possible to envisage times when GWT compiled JavaScript may not be fast/compact enough in the the way that people still occasionally write in assembler; as well as the Open Source nature of GWT should attract these people who are interested in making GWT tighter and even more optimized than it already is.

Its been hinted at a few times in our answers, but one way of thinking about the GWT versus JavaScript debate is the same way the debates from the 1960's and 70's over assembly versus the emerging higher-level languages were resolved. The higher-level languages "won" due to maintainability and reliability of code - which all goes to reducing the total cost over the lifetime of the project, an issue that web 2.0 projects cannot hide from for too long - however, segments of assembly are still used from time to time when it is needed.

If you were using the web in the late 1990's you will probably remember those animated GIF files of the mailbox that everyone used on their web pages to indicate a mailto link. So many sites used those animations because they thought that animations in general were cool. It wasn't about what the web user needed or usability, it was about using the latest cool toys. The same happened with framesets, DHTML, applets, and every other new technology on the web. Undoubtedly the same will happen with some early GWT applications, particularly as new releases of GWT add new widgets and panels there will be a tendency to throw everything in that there can be.

The point is that you shouldn't alter your expectations based on the tool. GWT is a solution to writing web applications with demanding user-interfaces, and should only be employed when it will help you deliver what your users actually need. So the answer to your question is no, a real-world GWT application is not bloated, assuming you use it when appropriate. We really like GWT, but as a developer you can't just use a technology because you like it.

When it comes to amount of code generated by GWT, it helps to understand how the compiler works. If you use Java you will be familiar with some of the utility classes like Vector, HashMap, Date, and others. When your code is compiled to JavaScript from Java, so are all of these classes that you used (or are used by other objects you used) in your project. So if you used Vector, your compiled code will include the JavaScript equivalent of this class.

This can result in a lot of code as you might expect, but the GWT compiler does some additional work to make it lean. The compiler starts by stripping out methods that don't actually get called. So if you only use two methods of a class that has ten methods, the code for the eight unused methods will be stripped out. The compiler then makes any other optimizations that it can to reduce the code size further. After that it takes what is left and renames all of the methods and variables to as few letters as possible, so a method doStuff() might be renamed to aB() to make the physical size of the code as small as possible.

Except in very small applications this will result in smaller a file size than the JavaScript equivalent. To give you an example, one of the most popular JavaScript libraries is scriptaculous (which makes use of Prototype) results in over 100K of library files. This is a hefty size penalty to pay if all you want to do is use one or two animated transformations. GWT on the other hand will only include the code that you actually need, then compress it, resulting in a smaller JavaScript file. This allows third-party GWT libraries to be bigger and do more without adding a size penalty for unused code.

We singled out scriptculous purposely because many GWT applications include animations often provided by scriptaculous. There are currently a couple animation libraries in the works written specifically for GWT, including one in the works from ourselves. We love scriptaculous, but all of that JavaScript is bigger than we like.

The Dashboard application that comes with the GWT In Action book contains around 1.12Mb of GWT code. The resultant JavaScript code is on average 245Kb - 22% of the source code size. Whilst 245Kb might sound large, this is an application that breaks our rule above since it packs in as much of GWT as possible into one application! Oh, and did we mention that GWT compiled code is specifically created to allow it to be compressed by the server? With compression, the 245Kb file could be as small as 60-80Kb.

GWT is also taking approaches to reduce load-time bloat, and release 1.4 introduces image bundling capability where you tell the compiler that these 10 separate images can be bundled together as 1, cutting down the return server trips and then splitting up the image on the client side as needed.

We think that targeting JavaScript was the right choice. It all comes back to the compiler. If you target Prototype or Dojo you now have the overhead of that library as well. Because the GWT compiler targets the lowest-level available in the browser, it can also make optimizations that wouldn't otherwise be possible.

This is a common misconception. A GWT application can mix Java and JavaScript code through the use of the JavaScript Native Interface. It lets you hook in JavaScript code similar to how a traditional Java application would use JNI to hook in compiled C binaries.

In fact, some of the first third-party classes distributed for use in GWT were wrappers to popular JavaScript libraries. Both of us are contributors to one of these third-party distributions, the GWT Widget Library (http://gwt-widget.sourceforge.net/). The GWT Widget Library contains Java wrappers for scriptaculous, JSCalendar, JSGraphics, and TinyMCE, and other JavaScript APIs such as Google's AJAX Search functionality.

In fact, you may have also heard of Google Gears, the new off-line AJAX tool with a JavaScript interface. There is already a GWT interface that uses JSNI so that you can use Gears from Java.

So no, GWT isn't crippled, in fact it has access to all JavaScript libraries, plus all GWT libraries. Of course writing natively in GWT allows the compiler to perform its magic and factor out unused code and remove most of the browser checking code that other JavaScript libraries have to include.

There are two issues that pop up recurring on the related GWT forums regarding lack of Java features. Firstly, it is easy to forget when coding in Java that you are targeting a web application. Hence there are often questions about why java.io or the JDBC libraries are missing/unable to be compiled by GWT. They are missing, and rightfully so, since client side code resides in a web browser which cannot do these things either - the solution is to use them as with any web app on the server side. Secondly, Java 5 syntax is not currently possible on the client side - it is in the pipeline for being implemented, but is not really a crippling aspect.

In general each of the approaches aims at addressing DOM, XmlHttpRequest, and other differences and we have to agree that the common ones are all quite successful in achieving this. Where GWT adds an advantage is in how it achieves hiding the differences. The secret sauce is the GWT compiler.

In a pure JavaScript approach you will use some code to detect the browser being used, and then execute the JavaScript appropriate for that browser. This is a simple solution, and easy to implement, but it generally means you need to send all the code for all browsers across the wire but only use part of it.

In GWT you need to do a little extra work to manage browser differences, but there are additional benefits. GWT's approach requires creating multiple Java classes, one for each variation. The DOM class of GWT is a great example of this and demonstrating how to cope with both hiding the differences and leveraging of the object oriented approach of Java. There is a basic implementation DOM class that contains most of the functionality, then additional classes extend the basic class providing only the variations needed for a particular browser/family. You therefore have a very nice set of classes in a well defined hierarchy which is easily maintainable and extend-able, compared to an approach that contains lots of "if browser= IE do X else if browser=Opera do Y......" spread over a number of places.

The payoff for all of this extra work, is what the GWT compiler does with these classes. Instead of creating a single JavaScript file it will create one file for each browser, and each JavaScript file only contains the code required for that browser (and further optimized to only include code for methods actually used). GWT uses some small, around 8K, bootstrap code to load the appropriate file for the browser you are using. The goal is to keep each JavaScript file as small as possible.

If you think only about the small browser differences, for example XmlHttpRequest, then this seems like wasted effort, and if that was the use case GWT was trying to solve we would agree. Where this really makes big difference is when browser differences result in a lot of additional code - take a look at the DOM class and think of the future issues of maintenance libraries that do not use this approach will have. Consider an application that needs to use either VML or Canvas for drawing, or Google Gears for off-line storage only if it is available. Your own code can harness the same approach - why send all the <embed> and <object> code necessary for all browsers just to display a Flash movie when you can send just the appropriate one?

To take this a step further, GWT applies this same approach to internationalization as well. So the German version of your application only includes the German vocabulary, the Italian version includes Italian, etc. For each permutation of browser/locale the GWT compiler will create a new JavaScript file.

Granted, this can result in a lot of files, but in practice it doesn't cause any issues. Fans of JavaScript may balk at the number of files GWT generates, but this can really help keep the size down providing for a better user experience.

The answer probably breaks down into two parts - more controversially, the home hobbyist is being drawn to GWT by the Google name and expectations of developing substantial web applications straight off, whereas they should perhaps spend some time getting used to Java, GWT, IDEs client/server divisions etc. Of course that is a generalization, but developing a substantial web application is not as simple as just adding a scriptaculous effect to a DOM element.
Changing locale is sometimes sighted as an issue as that requires a round trip to the server to select a complete new JavaScript permutation - however, in the real world users are less likely to be changing locale at the rate you do in testing, so the overhead required is not as poor as it sounds. If for your application this is an issue, then you can fall away from the static i18n approach preferred by GWT to a dynamic approach using the GWT Dictionary class - in doing this you lose GWTs ability to strip out unused code.

A modularization framework is something that would be useful to have natively supported in GWT. As it stands, you need to load all of your application in one go, so if you have 5 application modules they all are loaded when the web page is loaded. In certain cases being able to download modules individually as needed would be beneficial.

Yes the book does cover 1.4. The final version of the book was sent to the printers just before the 1.4 release candidate was finally released, but since GWT is Open Source we had access to the source code and the developers list during its development. So we took the risk of updating certain chapters so the readers didn't need to buy the second edition straight away!

Aspects of 1.4 that are definitely in the book are the approach to Image Bundling [Ch4 on Widgets], how the loading mechanism has changed (and how that plays nicely with the old way) [Ch17 on Peeking into how GWT works], the small changes to JSNI [Ch7], the additions to internationalization and talking about how the Serializable interface is now available in addition to IsSerializable. We don't go into detail on the new widgets (e.g. SuggestBox/Rich Text Editor) or panels (e.g. DisclosurePanel/Splitters) within GWT 1.4, but that fits with the way we have written the book as an "in Action" style rather than a rote reference.

Technorati : ajax, google, gwt, interview

• Digg
• Reddit
• del.icio.us

Comments (11)

agile ajax

An Interview with Dojo Creator Alex Russell, Part II

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

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

Ajax Challenges and Other Frameworks

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

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

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

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

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

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

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

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

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

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

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

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

Security

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

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

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

Comet

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

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

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

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

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

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

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

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

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

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

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

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

Future Plans

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

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

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

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

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

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

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

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

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

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

Q: What are your future plans for Dojo?

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

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

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

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

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

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

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

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

An Interview with Dojo Creator Alex Russell, Part I

Dietrich Kappe, Wednesday, August 16, 2006 @ 9:00 am

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

• Digg
• Reddit
• del.icio.us

Comments (9)

agile ajax

Interview: Google’s Bruce Johnson on the new GWT 1.1 Release

Dietrich Kappe, Monday, August 14, 2006 @ 1:04 pm

There's an interesting interview of Google's Bruce Johnson over at InfoQ. I thought his response to a question on open sourcing GWT was a little disappointing.

We've talked about that possibility from the beginning, so yes. Open-sourcing the tools right now could be more of a distraction than a help. It wouldn't serve GWT users if we took our eye off the ball by starting lots of discussions about the plumbing of GWT when we want to be focusing on making GWT the best it can be for developers. We'll periodically revisit the question as GWT evolves a bit more.

I think an Apache or BSD style license would make many more people take a look at incorporating GWT in their client work.

Technorati : ajax, gwt, interview

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax