UI Markup Nirvana
If switched allegiances a few times on this topic. The general idea is the same (better language, turing-completeness, MVC in 'page'), but the implementations change. Here is a timeline view of what I am a patron of:
'Long term persistence for Java beans' - 2001
Sun used to have a technology called Long term persistence for Java beans. It was unique in that it serialized a class definition as well as the data. Sun intended it to be for persistence of a UI state to a local file system. In 2001 I showed colleagues a simple proof of concept where a functioning web-style UI could work with pages serialized and deserialized using this technology. A browser concept could display Swing 'pages' in a far richer experience than HTML could do at the time. I stopped there, somewhat daunted with how hard it would be get it to work with servlets (etc); Making dynamic XML that was compatible with the deserializer/browser would be a nightmare. A couple of years later at ThoughtWorks Joe Walnes made XStream which did transparent serialization of object graphs (but not class definitions).
I liked the idea because:
- a declarative style is a pleasant way of marking up a UI, and is particularly easy to learn like the HTML was in 1991.
- you do not have ugly hooks to mix in procedural code, you can choose to inline it (strictly speaking this breaks the declarative style)
- it is a script language that flies to the client like HTML (and not a large binary blob that comes down like Flash)
- it is functionally far superior to HTML/DOM/JS - movies playing behind data-entry forms anyone?
- it honors the ideals of the web as we know it; the GET/POST/PUT/DELETE verbs, REST, incremental load.
Ultimately though Thicky was flawed, as the Groovy team dropped their interpreted mode as they moved from alpha to beta, and silently generate Java bytecode on first script invocation. The problem for client side Java is that a delay before page display will be unacceptable. This was clear as later versions of Thicky that used later versions of Groovy were slower than the original one.
Shoes (Ruby) and Swiby (JRuby) - 2007
When I learned about Swiby from colleagues, I decided to help the author Jean Lazarou a little. It is the same Swing-DSL idea but leveraging JRuby. JRuby has an interpreter that kicks in primarily for a fast per-page start time, but as paths are re-executed, a JIT kicks in and moves that more towards Java bytecode fragments. It was not going to be as slow as the Groovy/Thicky idea because the JRuby team were committed to keeping alive their interpreter and not dropping it in favor of a pre-compiler.
Shoes too looks interesting. It uses plain Ruby and is engineered for desktop apps. It does not yet have a web equivalent mode - GET, POST, PUT etc. Its challenges are to recreate the sandbox concept to allow safe execution of untrusted scripts. That's something that Swiby's Java+JRuby underpinnings could hypothetically implement easily.
For both Shoes and Swiby, a colleague (Vijay Jambu) and I had ready a demo app that used Google's "AppEngine for Java" as a backend on the day it was launched, as ThoughtWorks was in the alpha-test program. For Shoes at least, it meant augmenting the Ruby script loader to accept sources over HTTP.
By 2011, both Swiby and Shoes have fallen by the wayside.
QT Markup Language - QML - 2009
By 2013, after much uncertaincy, QT and QML have a better future with "The Qt Company" (a Digia subsidiary). Making apps for muiple platforms with QML becomes commercially viable. QML, though, requires heaving lifting to be done in C++. It is an arbitrary decision by its makers, and Oleg Shparber (2014) went on to combine Node.js with QML to make Node.qml allowing you to punch through stay in the QML grammar for much more (if not all) of your application.