Why is there Air - Bill Cosby versus Kevin Lynch

I know I'm dating myself, but Bill Cosby had a pretty funny routine where a PE Teacher explains that the purpose of air is to pump up basketballs and volleyballs.

Now Adobe has launched their Air product (with a matching Kevin Lynch NY Times article, and GigaOm fan dance) to allow platform to allow browser apps to escape from their little Firefox and IE prisons and flit gaily across the desktop like "real" apps.

Now what exactly are the benefits here? According to the NY Times article:

1. I can click an icon on my desktop instead of a bookmark in my browser. Yawn.
   
2. I can run an application without the browser border. Snore.
   
3. I can run an application offline. Now this is cool, but hardly new, following earlier moves by Google Gears, Dojo Offline and Mozilla Prism

Excuse me, but I prefer Bill's definition of why we need air.

As I have written, Air, Flex and Silverlight are"back to the future" approaches for Rich Internet Applications that would have us believe that the future of the web lies in a proprietary animation engine (Flash) or an ancient and proprietary fat client architecture (Silverlight).

At WaveMaker, we believe open-source toolkits like Dojo are the best enterprise Ajax choice a more flexible, open-source browser choice. To be fair, we in the Ajax community still have a lot of work to do to be truly ready to take on giants like Adobe and Microsoft - but that's where the power of the community can make a difference.

Speaking of community, you can come find out more about the the Dojo toolkit at the upcoming Visual Ajax User Group meeting. On Thursday, March 20 from 12-1:30 PST, Alex Russell, one of the co-creators of Dojo, will be talking about the Zen of Dojo - how to make Dojo development effortless for beginner and expert alike. Come in person or sign up for the webinar by sending email to rsvp@visualajax.org.

Compressing Javascript for zippy Ajax apps

A constant challenge with Ajax development is figuring how to get the widget code you need over to the browser as efficiently as possible. There are two issues here: 1) how to figure out exactly what Javascript needs to go on the client; and 2) how to make that Javascript download as small as possible.

The good counterexample here is the old Dojo download which was roundly criticized for being too large but Dojo has since trimmed down to a svelte 25K (take that jQuery fans!)

So the trick is to figure out what Javascript widgets need to get loaded to make your application run, then compress them to make them download faster. On the other hand, you need to make sure that uncompressing the download doesn't take more time than you saved in the download, as John Resig points out in his article on Javascript library loading speeds.

Brian Moschel of Jupiter IT in Chicago pinged me about a cool Javascript tool they developed called Include, that "makes compressing and including scripts ridiculously easy. It determines which files to compress at runtime and automatically compresses them using Dean Edwards'Packer." Check it out at javascriptmvc.com/include

Top Ten Ajax Mistakes

Ajax is powerful, but its very power can get Ajax developers into trouble. This list of top Ajax mistakes was compiled by Alex Bosworth. Unfortunately, his original posting has been lost in the great URL broken link black hole, so I summarized his main points here:

1. Using Ajax for the sake of Ajax: a lot of the new Ajax applications are really just little toys, not developed for any real purpose (see the Ajaxian post, Why Ajax?)
   


2. Breaking the back button: the back button doesn't mesh very well with Javascript. Keeping back button functionality is a major reason not to go with a pure Javascript web app. O'Reilly has a good post on fixing the back button.
   


3. Not giving immediate visual cues for clicking: if something I'm clicking on is triggering Ajax actions, you have to give me a visual cue that something is going on.


4. Leaving offline people behind: web application design should at least consider supporting offline Ajax access.


5. Sucking wind on slow networks: if I have poor network connectivity, every time I do something I have to wait for the server to return a response, giving me poor Ajax performance.
   


6. Sending sensitive information in the clear: all traffic must be vetted to make sure security is not compromised. Because Ajax apps tend to be more chatty, there are more opportunities for security breaches.
   


7. Assuming AJAX development is single platform development: it's not enough just to code to JavaScript standards, you need to test on all major browers and versions. Quirksmode has a good discussion of javascript browser compatibility.
   


8. Inventing new UI conventions: a major mistake that is easy to make with Ajax is: 'click on this non obvious thing to drive this other non obvious result'.


9. Not using links I can pass to friends or bookmark: I need to be able to pass people "permalink" URLs to my Ajax web app. There is a good article in the Content with Style blog on fixing Ajax bookmarking.
   


10. Blocking Spidering: Ajax applications that load large amounts of text without a reload can cause a big problem for search engines. This is related to the lack of permanent URLs. Google has a good discussion of the Ajax spidering issue.
    

Alex Russell on the Zen of Dojo - Thursday March 20

We are very please to announce that Alex Russell, one of the co-creators of Dojo, will be presenting to the Bay Area Visual Ajax Group on Thursday, March 20 from 12-1:30.

Alex (his blog is here) will be talking about the Zen of Dojo - how to make Dojo development effortless for beginner and expert alike.

The meeting will be at WaveMaker, 301 Howard Street (at Beale), 22nd Floor (BART stop Embarcadero). For more information, to reserve a space, or to get webinar dial-in information, send an email to:
rsvp@visualajax.org

Microsoft .NET and AJAX

Ajaxian has a good article today about some of the new AJAX solutions that are based on .NET. Given .NETs strong visual tooling, this is starting to be a good way to get more visual in building AJAX apps.

The Ajax Data Controls is a DotNetSlackers project. You can read more about the AJAX Data Controls project on CodePlex

Getting Started

This is the first posting for the Visual Ajax blog. I look forward to inviting various Ajax thought leaders to present at our monthly user group meetings in San Francisco as well as post to this blog!

The goal of this blog is to promote the use of AJAX tools to build rich internet applications (RIA). We are looking for ways to make AJAX programming as easy (and as ubiquitous) as VB programming.

If you want to know more about me, check out my "day blog" at www.keeneview.com or my "day job" at www.wavemaker.com.

Some other resources to check out include:

• Adobe owns the domain, www.visualajax.com, which is a bit sinister when you think about it ;-)
  
• Ajax Webshop, a visual IDE for AJAX
• Ajaxian is a great resource for information, such as surveys on AJAX usage
• Ajax.dzone.com is another good resource
  
• Aptana, a web IDE for for building AJAX applications
• Backbase is another visual AJAX IDE
  
• Visual AJAX toolkits listing, and another one on Ajaxian
  
• Coghead is a hosted environment for building visual AJAX applications
  
• Teqlo is another hosted environment for building mash-up AJAX applications
• Tersus, an open source tool for building AJAX web applications without coding or scripting
• WaveMaker is an open source framework for visual AJAX web development