Friday, May 12th, 2006
Zimbra – Anticipated some of the benefits of Ajax, e.g. rich UI, zero-admin,
etc. But didn’t anticipate some other things: SOA/Mashups, Ajax authoring, that it would be the RIA winner (Google, MS, Yahoo, etc), ease (at the time, seemed really hard to do it).
Zimbra – not for everyone, but a good fit for Java programmers.
Demo of Zimbra’s drag-and-drop.
Zimbra = “Pure” Ajax (MM – AKA “Ajax Deluxe”, “Client-SOA”). No HTML is provided by the server. More like a Java app than most web apps. Result is “husky” client 3-tier architecture. All UI on client, with server-side Java code for UI operations.
Sure, most existing web apps are fine just to be augmented with Ajax. But Zimbra had the luxury of starting from scratch.
COBOL wasn’t so different from the web: Mainframe COBOL program handling UI, business, data logic, against green screen client. Then, we had client/server, where most of this moved into the client. But when the web came along, pushed those things back into the server. Now with Ajax, we get to decide on the partitioning ourselves. Various strategies are possible.
Toolkits should be abstracting all this browser-specific stuff.
Zimbra team got together with IBM team to extend Eclipse to support authoring. Others too, e.g. Dojo and OpenRico. Led to Open Ajax Initiative. Shared visionj: Ajax ought to continue working across browsers and across desktops (ie. OSs).
MS stack (Atlas, Visual Studio) is already great and a safe bet for efficient dev.
Zimbra/Kabuki (Zimbra will soon be Apache Kabuki), and also Dojo and Scriptaculous approaching critical mass, will be very hard for proprietary vendors (other than MS) to get a foothold.
Another challenge: browsers weren’t designed for this kind of punishment – memory leaks, performance gaps.
Complexity of authoring and debugging. “Deeper” Ajax still requires OO UI skills.
Demo of mashups in Zimbra. e.g. Phone number inside an email – shows owner’s details. Address in email – pops up map image.
ALE = Ajax Linking & Embedding. Authoring. Can easily go in and edit content. WYSIWYG authoring.
Practical Ajax Tips
- Use an Ajax toolkit. Contribute too if inclined.
- CSS is your friend. Parametise app so can re-skin without going into JS internals.
- Use JSON (and XML). XML parsing in JS is expensive.
- Use async network programming.
- MVC paradigm worked for us.
- Compress – jsmin saves ~1/4x. Gzip ~3-4x.
- Take testing seriously. Mercury’s QuickTest-Pro (QTP). Also JSUnit etc.
- Pick your fights.
- No such thing as secure client-side logic.
- Architect community review XML/SOA bindings.
- Dedicate top UI OO talent.
- Pick your fights – don’t do Ajax everywhere.
- Richly interactive UI desirable
- Combined with web look & feel and deployment
- No client-side data/resources.
Ajax isn’t a business model, it’s the means and not the end.
Scott asks the audience, “What is the biggest problem with Ajax?” Everyone in the audience calls out different things – accessibility, etc. Scott: Close, but the biggest problem is recruiting – interview 40 people for every hire. So let’s figure out how to make it a lot easier.
Posted by Michael Mahemoff at 10:59 am