Will Frameworks Tame Ajax?

With AjaxWorld convening this week, we’re hearing a lot from vendors who are promoting tools that could help enforce some form of discipline over Ajax development. We hear a lot about frameworks that, not only eliminate the need for raw coding in JavaScript, but provide ways to automate handling of events, connecting to structured or unstructured data, or deliver all of the above.

Oracle’s Ted Farrell, who’ll be keynoting, is making the case for Ajax frameworks. He argues that
1. Technologies come and go.
2. You can’t always find the widgets you need if you’re dealing with enterprise legacy; and
3. Enterprise mashups can’t be treated as casually as consumer-driven ones.

Let’s drill down point by point. First, if you look at the history of the web, we’ve had multiple generations of browsers that have not always fully supported W3C standards. Over the years, there have been numerous attempts to make web pages more dynamic, beginning with Java applets a decade ago, and more recently encompassing Ajax and newer rich frameworks form the likes of Adobe, Microsoft, and Laszlo Systems. So, give this point to Farrell, web technologies come and go.

Secondly, if you’re trying to hit against legacy apps that may not have been moved to the web, or exposed through standard formats like portlets or web services, you’re going to have a heckuva time unless you’ve found some tool to wrapper or tag them. Beyond mainframe apps, just look at the diverse stable that is now part of Oracle’s tent. Legacy Oracle users may have apps written in Oracle Forms, while PeopleSoft, Siebel, and J.D. Edwards have apps written in a mélange of C, C++, Java, or even RPG. Oracle Fusion, anybody?

Finally, there’s the case that enterprise mashups must be treated more seriously. Take that Google map where you’ve just mashed up the names and locations of your customers in a particular region. It may be fine to post it on an Intranet to the sales team, but if those names somehow leaked out to your external website, or pried open via SQL injection, you’ve got a HIPAA, Gram-Leach-Bliley, or even PCI (Payment Card Industry) violation on your hands.

OK, so you decide that a framework might not be such a bad idea. Well, most of the Ajax frameworks out there are currently focused on abstracting out the JavaScript, giving you declarative, 4GL-like tooling to piece those pages together. Others might be leveraging the middleware you already have to access back end internal assets that might not be exposed on a web page. And a few are starting to provide links to governance so that JavaScript objects that are deployed at run time don’t somehow get hijacked along the way.

Ultimately, whether you add a framework to your Ajax development depends how formal or informal is your organization’s mashup strategy. Given the outlaw lineage of this form of development (remember, the term Ajax itself was coined by a guy whose first and middle names were “Jesse James”), until now the idea of strategy was something of an oxymoron. Nonetheless, some enterprises are indeed starting to take Web 2.0, and more specifically, Ajax-style programming more seriously.

Indicators of whether an organization can, or will have a strategy for mashups rest on a number of factors. First, how controlling is IT – is there a strong tradition of governance, or is it an afterthought? Who’s doing Web 2.0 development, and why? Is Web 2.0 development now considered a formal extension of your enterprise software development portfolio and handled by your software development organization? Or are line organizations taking the law into their own hands to do Web 2.0 because it’s easy, and it’s a workaround to IT’s endless backlogs? And are the mashups intended to live for the moment, using assets that are easily accessible, and then be disposed? Or are mashups supposed to carry a formal lifecycle?

One of Farrell’s arguments for frameworks is that it’s meant to abstract your Web 2.0 development, not only from the vagaries of back end systems, but also from the technology churn that the web environment has proven to be. We can’t argue with that.

But that argument is valid only if your organization doesn’t swap out Ajax frameworks themselves. If your organization lacks a Web 2.0 strategy, and/or developers are not from the IT mother ship, you might buy frameworks, but they may be only as permanent as the PDQ mashups that they churn out.

Depending on your point of view, there’s hope. Outlaw technologies like PCs and the Web initially snuck in through the back door, only to eventually get accepted and “civilized by IT.” Frameworks might get the last laugh after all.