Innovation, or the lack thereof… W3C, anyone?

I originally posted this on the OSFlash mailinglist, but i thought it would make a good blog post, so here it is:

My vision of a next generation web application framework.

(or: Innovation, or the lack thereof… W3C, anyone?)

There’s a sh*tload of XML dialects for GUIs either available or being developed at the moment. Just to name a very few: Adobes MXML, Microsofts XAML, Laszlos LZX, Netscapes XUL, and from the OSFlash camp ActionSteps ASML (or Renaissance) and ASWings AWML.

All of them are proprietary formats (plus most of them are direct projections of the underlying, proprietary APIs), and all of them require some decent amount of script code to be written in order to actually make the UIs work. Problems: to author sophisticated applications i need extensive knowledge of the XML dialect itself, of the API and the scripting language, and probably of the underlying platform API too. For most ‘next gen’ RIA platforms much of this is proprietary stuff, so i better choose wisely what technology to dive into for the next months/years. I also better be able to think ‘code’ in order to make my RIA a successful reality.

Wouldn’t it be nice to develop web applications using open, standardized technologies that everyone is already very familiar with? Let me introduce you to the W3C, and please try to forget about browsers in general and men with white beards wearing birkenstocks in particular for a moment.

Contrary to popular belief, the W3C is working on really cool stuff. Some of it you’re already very familiar with: (X)HTML and CSS. The *real* cool stuff though are W3C technologies that haven’t made it into the mainstream yet (because they aren’t supported by mainstream clients, or because they’re being worked on yet). I pick two of those technologies, XFrames and XForms, and briefly introduce them here, as i think that together with XHTML (2) and CSS (3), they pretty much cover everything a RIA framework needs.

The technology that is supposed to supersede HTML Frames. XFrames of course is going to support framesets as we know (and hate) them today, but there’s so much more. Using CSS, frames can be styled to appear as floating windows or tabbed panes for example, and using a new URI scheme it will be possible to easily link not only a frameset but also it’s content, example:,id2=uri2,...).

The technology that is supposed to supersede HTML Forms. XForms is going to significantly change the way we author forms. Basically, it separates the model from view and controller, as you can now have multiple data instances (usually XML, both inline or external) that you can use as data provider for controls and widgets (controls can be bound to data provided by instances using XPath). Validation is handled in a purely declarative way via XML Schema datatypes. But again, there’s much more, for example: <switch> and <case> to show/suppress parts of the UI (to be used for e.g. wizards, tabbed interfaces or dynamic forms), or <repeat> (to be used for e.g. filling tables with rows, or datagrids, or just about anything UI that repeats itself). Of course everything is styleable by CSS and can be bound to data instances. Sounds familiar? It sure is. And did you know that the latest ColdFusion uses XForms under the hood? Yes it does.

I recommend the W3C articles “XForms for HTML Authors” (Part 1 and Part 2) and Micah Dubinkos XForms Institute (hey look, he’s using DENG!) for a leightweight introduction to XForms (The XForms Institute also links a free online version of the O’Reilly book “XForms Essentials” in case you’d like to dive in further)

If you mix all those technologies mentioned above, and throw in some more, like SVG, SMIL, and maybe even XUL, that’ll be my vision of a sane platform for Web 2.0 [sm][tm](c)… ok, Web 3.0 it is then. A sane platform to develop RIAs on. Don’t even get me started ranting about the current state of the web as too many people see it. What the web needs is innovation, not hyped acronyms for old crap, or yet another proprietary markup language.

Of course such a framework needs to be developed yet. With the Flash Player 9 in our hands, the great performance boost compared to version 8 and a way better API (minus native text rendering.. still sucks), i’m sure it’s absolutely doable. If only somebody with some angel $$ would share my views, or if only everybody would work together with open minds instead of cooking their own soup…

We even have a proof of concept, anybody remember DENG? That was Flash Player 6. I’m also writing all this because i think most people misunderstood DENG and see it as a better HTML-enabled TextField or something, or worse, as a HTML browser. It was supposed to be the beginning of an application framework. Of course it’s missing A LOT yet to really become one (and of course Flash Player 6 was way too slow to do such stuff), but again, with Flash Player 9 and some likeminded developers, this could become quite a blast.

Thanks for listening :)

Addendum: Some good and valid remarks and questions i got in the OSFlash mailinglist:

This is, in my mind, a brilliant idea especially when you throw in Haxe‘s planned ability to render to different (and future) runtimes (I assume that you would use Haxe to do this).

One of the most frequent issues on the Haxe list is the lack of a component written for Haxe. I think that a project like this would solve that issue for Haxe.

I’ve looked into Haxe. It sure looks promising, and It’d be a major plus that a framework written in Haxe potentially wouldn’t have to be tied exclusively to the Flash Player. The first thing i would do if i would start to develop such a framework in Haxe is write a compliant DOM3 Core implementation that works exactly the same in Flash 6, 7, 8 and 9 and in all mainstream browsers. That alone would already kick some serious bottom.

I glanced through the XForms documents on w3c and was wondering if it would be possible to leverage one of the existing component sets (specifically ActionStep or ASWing) to complete this task? To me, it would seem like a much smaller job if we used an existing framework.

But could we imagine to bind a standard Flash XFrames/XForms/CSS parser with any/a few GUI toolkits? That would actually be great, but is it possible to achieve?

I have been asked this question many times already. Theoretically, this is possible. However, if i would develop such a framework, i would surely want to implement CSS3 which features styling and skinning mechanisms that imho beat those implemented in all current GUI toolkits together, and integrates perfectly into all mentioned W3C technologies. So depending on what toolkit you use, you probably can only implement a subset of CSS3. I also think that it wouldn’t be very easy to integrate custom component sets, or rather, i think it wouldn’t be worth the pain.

DENG 2.0

DENG 1.0 has been around for a long time now (almost three years), and there hasn’t been any new code release for quite a while, so some of you might wonder what we’ve been up to, and what the plans are.

We started developing DENG in difficult times. DotCom had just crashed hard, and demand for XForms renderers was low (the W3C XForms WG was still working on it). It was very hard to find contributors as most Flash developers generally disliked everything the W3C produced, and the proprietary nature of Macromedia products made it hard for people outside of the Macromedia world to join such a project. Also, it was nearly impossible to get funding. Nevertheless, we worked hard to make DENG a reality, found a few contributors who saw the potential, and even had a bit of funding (well, at least enough to pay the rent for a while).

A big up goes to Stefano Debenedetti, who was working on a Flash XHTML/CSS renderer for Benetton at the same time i was working on DENG. He quit his day job just a few weeks after we made first contact to come from Italy to Germany for a few months to join the core team and work on DENG fulltime. He eventually implemented the DENG XForms module, as well as an experimental SMIL module.

After we got DENG 1.0 out the door, open source, and with a lot of features (significant subsets of CSS3, XHTML, XForms, SVG, XFrames, etc), we started an open discussion about the future of DENG. The Flash Player 7 was released by Macromedia, introducing Actionscript 2 (an ECMAScript 4 implementation), but not much more that would be relevant for DENG. We thought about porting DENG to Actionscript 2, even wrote some proof of concept modules (Jim Cheng did a DOM implementation, i ported the DENG CSS parser etc).

The UGO initiative was given birth, at first as an attempt to develop an open source framework for the Flash Player. UGO was drawing the attention of quite some developers (both Flash and non-Flash), and some very interesting discussions were going on. The UGO initiative today focuses on providing reliable standards support on ECMAScript-like platforms and is an ongoing project. Current results are a deployment system, a module loader and a non-Flash, ECMAScript XForms implementation for current browsers, developed by Stefano, who luckily found a new employer (Dreamlab) being very pro open source and open standards and actually made all this possible.

I was very busy the last year, working on commercial Flash projects (and I still am). I also moved to Brazil some months ago, and currently am in progress of setting up a company here, so time was very limited thus far to work on DENG or UGO. I feel very bad for that, but unfortunately this was necessary.

With the Flash Player 8 on the horizon, i am now going to catch up with the development of DENG, and push it to version 2.0.

DENG 2.0 will be targeted for Flash Player 8. That means that the current code base will be completely refactored and DENG will leverage all the new features that are going to be introduced by the new Player (many of the new features are not yet published by Macromedia, but some are, like big improvements in drawing API and performance) – along with features developed in the UGO initiative (standards compliant API).

I have high expectations. I am working towards 100% compliance of XForms, SVG Tiny and CSS3 and as much of XHTML compliance as possible, with a strong focus on CSS3 and XForms.

Please contact me at claus at in case you want to contribute code (although it will take some time yet for code contributors to be able to join as the Flash Player 8 is not released yet) or in case you are looking for an open source, zero install, pure clientside, lightweight, modular renderer of XForms, XHTML, SVG etc (you name it) with CSS3. I also haven’t given up hope to get decent funding for that project, in order to make this a fulltime job again, either for me, or for other contributors. Thanks.

XForms For The Masses

The FormFaces project team announced their open source ECMAScript XForms solution today. The engine processes XForms entirely on the client side and runs on any ECMAScript and DOM Level 2 powered Webbrowser (Internet Explorer, Mozilla, Opera, Konquerer, Safari and others). All the author has to do is add one JavaScript include to her XHTML/XForms document: <script type="javascript" src="xforms.js"></script>.

Given that the engine lives up to its promise, this release may mark the end of the UGO Project as we know it today. The goal would have been achieved and developers can finally start writing sophisticated forms applications without the hassle of messing with error-prone, homegrown JavaScript to overcome the limits of current HTML forms implementations.

FormFaces is currently in alpha and scheduled to be released in April.