Agile Ajax

Recent Ajax Framework Releases/Developments

Some noteworthy Ajax Framework releases have come out in the last few weeks, along with some other news of interest:

• Ext JS 2.1 and Ext GWT 1.0 Beta - Better performance, new Slider, StatusBar components. REST support (support for other HTTP methods beyond POST and GET). The Ext GWT 1.0 Beta consummates the love affair between GWT (Google Web Toolkit) and Ext that was started by gwt-ext and MyGWT, but provides the comfort of knowing that it is supported by the Ext JS folks. Note: Ext GWT is pure GWT, not an Ext JS wrapper.
• Dojo 1.1 - First off, API compatibility between 1.0 and 1.1. Unified timing loop (ala Scriptaculous) for animation effects, with increased performance. Syntactic improvements to dojo.query. Unification of XHR functionality into dojo.xhr() function.
• Backbase Enterprise Ajax 4.2 - Backbase has been in the commercial framework game longer than almost anyone. Among the new features: hierarchical data bindings and improved performance. If you've wanted data binding for tree widgets, have a look.
• Google Search, Feed and Translation API - I opined a while back that Google discontinued their SOAP search API because they didn't want people reordering or otherwise manipulating their search results. Looking at the terms of use of the new REST service, you can see that this continues to be a concern:  You agree that you will not, and you will not permit your users or other third parties to: (a) modify or replace the text, images, or other content of the Google Search Results, including by (i) changing the order in which the Google Search Results appear...
• Google App Engine - it only runs Python apps right now, and it's a preview release available to a select few, but you can already see that this is Google's challenge to Amazon's EC2 compute cloud. In at most a year, unless you are security sensitive -- health care, financial services -- or running on Windows, you won't be building and maintaining data centers. The capital requirements for launching sophisticated and scalable online services is about to change.
• Echo3 (beta) - it's getting close. Superior performance to Echo2. Easier development of new components. Automatic serialization of objects between client and server. All HTML rendering now done on client. Overall the JavaScript client code is now of a design quality on par with the server code.

Lots of exciting developments for Ajax developers and Web 2.0 entrepreneurs. I, for one, can't wait to see how the Google App Engine compares to EC2 for deploying and scaling Facebook applications.

Technorati Tags: ajax, dojo, google app engine, gwt, ext js, backbase, echo3, google search

Facebook Application Logistics for Team Development

Facebook is a unique platform for application development -- Facebook applications have a powerful API, a large user base, and low barrier to entry. With the Rails Facebooker plugin, a Rails programmer can treat the Facebook user data as an extension of existing Rails session features. It's all very nice, and I'm not going to talk about any of that this time around.

I'm going to talk about the logistics of doing Facebook apps. When a user sends a request to a Facebook app, Facebook intercepts it and forwards the request to the third-party app server, along with some specific Facebook data, like the ID of the user making the request. Applications have to be registered with Facebook, and have a unique URL prefix at apps.facebook.com. You also provide the URL for your third-party server.

This sets up some challenges for a development team. First off, your application probably relies on Facebook services, meaning it can only be fully tested from within Facebook. This implies that the external Facebook server needs to be connected to your development server. Since many Rails developers run off their own development machine behind a firewall, this is potentially awkward. Similarly, the fact that the Facebook application has a single URL mapping makes it difficult for multiple developers to work on the same application without tripping over each others' work.

How can a development team make this work?

Facebook Application Logistics for Team Development

Facebook is a unique platform for application development -- Facebook applications have a powerful API, a large user base, and low barrier to entry. With the Rails Facebooker plugin, a Rails programmer can treat the Facebook user data as an extension of existing Rails session features. It's all very nice, and I'm not going to talk about any of that this time around.

I'm going to talk about the logistics of doing Facebook apps. When a user sends a request to a Facebook app, Facebook intercepts it and forwards the request to the third-party app server, along with some specific Facebook data, like the ID of the user making the request. Applications have to be registered with Facebook, and have a unique URL prefix at apps.facebook.com. You also provide the URL for your third-party server.

This sets up some challenges for a development team. First off, your application probably relies on Facebook services, meaning it can only be fully tested from within Facebook. This implies that the external Facebook server needs to be connected to your development server. Since many Rails developers run off their own development machine behind a firewall, this is potentially awkward. Similarly, the fact that the Facebook application has a single URL mapping makes it difficult for multiple developers to work on the same application without tripping over each others' work.

How can a development team make this work?

Ideal team size for your next Facebook project

I recently worked on a Facebook application for one of our clients.  This turned out to be our first collective experience building for Facebook, and it involved a mixture of re-using existing web services and building new ones for use by the same infrastructure.  All in all, a challenging thing to build and deliver given a relatively short deadline.

While there were many architectural considerations at hand, one of the interesting aspects of the project for me dealt with how we structured our team and went about tackling the problem.  As a result, I have a bit of advice on team size for those of you considering similar projects with an existing team at your company.  But first, a little history...

20 useful Facebook/FBJS developer resources

The Facebook application platform is less than a year old, and Facebook JavaScript (FBJS) made it out of beta less than four months ago. It's therefore unsurprising that comprehensive developer resources for both are a little thin. Most of the real content comes from official Facebook properties. Still, a little digging helped me uncover some decent tutorials and a wealth of open-source wrapper libraries for Facebook's RESTful API. Interestingly, I didn't uncover any big attempts at Prototype-style FBJS toolkits - just a few scattered examples of utility classes. It seems that Facebook development experience is still enough of a competitive advantage that the experienced few aren't rushing to create helper libraries for their hapless peers.

FriendFeed, Jaiku and Plaxo Pulse: Networks within networks

I'm as sick of signing up for new social networks as anybody. I'll never get back the hour I spent establishing an Orkut profile I never used just because two hipster friends momentarily thought Orkut was cool and badgered me into submission.

That said, I'm a little dismayed by the identity-management land rush. For a couple of years now, we've been hearing about this glorious world in which we'll be able to aggregate our online identities across multiple social networks. In just the last few weeks, I've gotten invitations to beta-test three new identity aggregators (FriendFeed, Plaxo Pulse and Jaiku). And now Facebook announces that it wants to make my data portable so I can take it with me to whatever network I want - a move unsurprisingly endorsed by Plaxo and other bit players.

Facebook's announcement is obviously a marketing move - just another step in its strategy to position itself open ecosystem rather than a closed network. But FriendFeed and its ilk are another matter. I have no doubt that the future will involve a procession of new, flavor-of-the-month social networks. But it's hard to imagine any one of these meta-networks building the ubiquity of the networks they cannibalize.

Most of these services fall into three categories: content aggregators, identity managers and reputation protectors. Content aggregators (such as FriendFeed and Profilactic) try to mege all of your "attention data" into a single stream for syndication. Identity managers (such as FindMeOn) seek to create a "master" online identity with permissioned access to all of your other identities. Reputation protectors (such as Naymz and ClaimID) help you establish and protect your online "brand."

There's a lot of overlap between the three concepts, but they all suffer from the same problems:

• They're too complicated to use: I gave FindMeOn a whirl about a year ago, but I found its system of "badges" and "digital keys" complex and annoying. It didn't help that its visual design and Ajax interface were so cluttered and quirky. FriendFeed, which is still invite-only, offers a much cleaner and more direct user experience. But its RSS mash-up strategy is far less ambitions than that of FindMeOn and its nebulous parent, Syndiclick. Regardless, none of these services really reduces the complexity of managing your online identities. If anything, they add to it, forcing you to keep one more profile up to date.
• They solve a problem most average users don't have: Tech professionals and early adopters may all have a zillion online identities, but most social-network users have at most a handful of accounts. As they discover new services, they're likely to stop using older ones. I loved Friendster as much as anybody back in 2003, but I never log on anymore because none of my friends do. Ditto MySpace circa 2005. I may have a trail of social-network accounts, but only a few are ever going to be truly active at any given time.
• They're a little too good at what they do: As earlier commentators have pointed out (here, here and here), social networks often derive much of their value from being walled off from one another. Users may want to share different data with friends, family members, colleagues and romantic prospects. Aggregating all of your identities just to re-segment them seems like too much work.

Is anybody out there actively using these services and, if so, how useful are they? As always, I'd love to hear in the comments.

Technorati Tags

• social networking
• Friendster
• MySpace
• Facebook