I have been pushing an idea for quite a few years. In a nutshell it is a better markup technology than classic HTML+JavaScript. One that allows MVC and turing completeness within a 'page', keeping the hyperlink nature of the web and a 'browser' per se, adhering to the verbs of HTTP, and ultimately moving past the strict markup of XML-style 'must have matching end-tags' which is the hallmark of machine-centric forms, and into something that's more human-centric with curly braces for start and end of scope.

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:

In Red are inventions that came from nowhere that extend the viability of HTML. They irk somewhat as I really don't like the 'escaping' HTML (declarative) to get to JavaScript (procedural). In Green are the technologies described below that are more conformant to the idea that I though should prevail.

'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).

Groovy's Builders - 2004

It really started in earnest when I first saw Groovy's Builders in 2004. Particularly the Swing Builder. I realized that it could also be a alternate page technology to HTML and JavaScript, and much better than the "Long term persistence for Java beans" technology . Thus Thicky was born in March of 2004. It was a useful prototype that got some blog space attention (Obie Fernandez and Dion Alamer).

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

The Nokia folks make a nice DSL for their QT technology originally called alternatively called Kinetic, Qt Declarative, or QML. It really wasn't one language, but two, as theres an escaping mechanism to move from the DSL to the controlling JavaScript.

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.

My blog entries towards this agenda: