Over-Egging the XForms Pudding (Not)

Mark Birbeck seemed to feel I had accused him of over-egging the XForms pudding and posted a thoughtful treatise on XForms programming in reply. As usual Mark makes a lot of good points in support of his thesis that:
“… a programming model based around events, declarative mark-up, a spreadsheet-like dependency engine, automatic reflection of model state to the UI, automatic validation using standards, easy encapsulation of data submission, and so on, is easier than scripting, AJAX, C++, VB, Java, and yes, even Ruby on Rails.”
I was most definitely not accusing Mark of over-egging any puddings: as an uncouth Yank the phrase was not previously in my lexicon. And clearly Mark’s got a broader perspective than XForms. Others involved in XForms have been somewhat vocal about the demerits of script-based web applications and the inherent superiority of XForms declarative approach (e.g. for promoting accessibility and device-independence). Mark, by contrast, has taken a pragmatic and use-case-driven approach to looking at how best to utilize XForms capabilities in real-world rich-client application scenarios. Indeed Mark’s intricate sample applications cross the line into “programming XForms”.
And that’s exactly my point. It’s not a question of whether XForms is an improvement, but rather whether it’s realistic to expect programmers to adopt it all-in as an displacing paradigm. Innovations that require people to change behaviors often have a hard time getting adopted. Millions of developers build rich-client user interfaces by combining declarative XML markup for presentational artifacts with JavaScript for client-side interactivity and business logic. This approach is common across AJAX, XUL, Laszlo, Dashboard, Konfabulator, and Flex. Microsoft’s paying its typical fast-follower “flattery” in adopting this approach for it’s forthcoming WPF/E.
If these RIAs exhibit an MVC architecture at all, it is typically in classic OO programming style via rich domain objects (i.e. the data are encapsulated in programmatic objects, with method-based access). Whereas XForms requires that the presentation/controller layer of the application deal with an XML data model. This RESTful (or in SOAP terms “doc/literal”) approach can also be supported in classic script-based RIA architectures, so in some sense XForms gives programmers fewer capabilities. Less may be more in terms of the overall application lifecycle, and I happen to believe that the looser coupling of the XForms approach is a promising paradigm in an SOA world of remixed web applications. Nevertheless it’s hard to envision many developers giving up the OO approach that has been drummed into them for decades as best-practices.
And, Mark’s comments about the potential to extend the XForms actions mechanism with looping and branching constructs like “if” and “while” set off further alarm bells for me. If XForms actions is destined to become a full-fledged Turing-complete programming language – and a procedural one at that, rather than a functional-programming system like XSLT – then it’s simply in head-on competition with JavaScript/Java/C#/Ruby/et. al.. Given the extremely cumbersome XML syntax and lack of a user base, what would be the motivation for devleopers to adopt it? Once you have the looping & branching the static analysis required of a developer tool processing XForms action sequences wouldn’t seem to be fundamentally different than if it were processing blocks of JavaScript. XML syntax makes things much more complicated for the human programmer yet is a minor convenience for tooling – whether JavaScript or XML, parsing is a minor part of the tooling equation. Some folks from MIT have tried build a programming environment, Water, around simplified XML, but it appears to have gained no traction in the community.
I’m not sure what the right answer is but Clayton Christensen makes compelling arguments that the best way to get disruptive innovation adopted is to compete against nonconsumption. To me this come back to focusing on tooling that enables new workflows, ultimately the Holy Grail of applications assembled by visual designers and non-technical knowledge workers, rather than expecting to persuade OO developers to use sequences of XML actions to do the same job as ECMAScript, or give up their domain objects (luckily, E4X promises to bridge the XML-ECMAScript gap). I also agree with Mark that XForms promise is as a “component of a much wider solution” and that other aspects like the universal document still need working out. My instincts are that, for solutions aimed at developers, ECMAScript will still play a central role. In that regard I might suggest to Mark and other XForms advocates that coming up with hybrid examples that usefully blend script and declarative XForms constructs, rather than strive to use only XForms markup even at the cost of obstruseness, might be a more constructive form of evangelism of XForms as (to developers) “sustaining innovation” rather than “disruptive innovation”.