So, in the previous post I raved like a lunatic about the concept of declarative UI languages -- and QML in particular. It turns out that apparently I got excited about old wine in new skins. Which isn't exactly unusual either :-)
More specifically, I recently chatted with a certain developer -- and he pointed out that Edje (one of the various pieces in the EFL stack) has (supposedly) provided the same stuff for years...
This is a bold claim of course. Scepticism rears its head... However, judging from a quick glance at least, there are indeed striking similarities between QML and Edje Data Collections. Now I should dig a bit deeper, to find out how far the similarities go. Only I'm too lazy to do that, until I get to actually use either of them :-)
Someone also threw in XAML, which is used (among other things) for declaratively describing user interfaces in Microsoft's WPF. While I originally understood WPF to be one of the crazy frameworks for doing desktop applications in HTML, it turns out that with XAML as the language for UI descriptions, it is related to DHTML (i.e. HTML/CSS+JavaScript) only in spirit; while the actual implementation is designed from scratch, and thus probably saner... Or let's say: it has the potential for being saner -- but being created by Microsoft, it's as likely as not they actually screwed it up anyways :-)
Obviously, XAML being XML-based, it doesn't look very similar to either Edje Data Collections or QML (and is barely human-readable in fact) -- but from a cursory glance, the fundamental concepts behind them are quite similar.
What's more, XAML also forms the basis for Workflow Foundation, which some described as monads in disguise (no, I do not remember where I read that) -- i.e. related to functional programming. I don't know how these pieces fit together exactly (nor am I much inclined to seriously study such proprietary abominations... I mean technologies); but by the sound of it, this might allow for the kind of declarative UI descriptions with functional-style behaviour specification, that I was musing about -- especially when combined with F# for the actual application logic.
It's rather chilling to see that apparently Microsoft is kinda taking the lead here... So let's change topic quickly -- I'm freezing by now!
To avoid serious confusion, I feel obliged to point out that storing UI definitions in a data file (rather than building the UI elements one by one with function calls in the main program) is not a new concept by itself. Point-and-click GUI builders have done this back in the nineties, if not earlier. However, elevating the UI descriptions to actual source code -- which can be viewed and modified by the programmer directly, rather than only through some point-and-click tool -- totally changes the game.
For one, the UI definition becomes a first-class part of the program. It can be handled with a text editor like the rest of the source code; it can be properly versioned. The connections between UI definition to main program, and the workings of the UI in general, become much more transparent.
Moreover, the UI definition itself becomes more powerful. There is only so much behaviour you can reasonably describe with a point-and-click tool; any non-trivial interaction requires calling back into the main program. When on the other hand the UI definition is handled as a true source code file, it becomes natural to implement complex interactions directly there as well; so the whole UI definition can be contained in the same source file, and the main program really only has to handle actual program logic. That's where these new declarative UI frameworks excel.
By the way: I learned in the meantime that functional programming is generally considered a subclass of declarative programming -- so my intuition about this was quite on spot :-)
