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.
Flip to Ruby and 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.
Keeping an eye on other DSL markups (2009)
Martin and this pattern of DSL usage.
Lastly, I was trying to persuade Martin Fowler to write a 'bliki' article called "Closure Normal" or "Nested Closures" as he is really good at explaining things to the masses. It is when you use a language like Ruby or Groovy and leverage builders so that the UI part of a map looks to be almost entirely made of closures. There are loads of keywords in the mix like DSL, Builders. Even Closures has a regular understanding that's classically one level deep. All this confuses the elegant simplicity of a app encoded in a set of indented closures. Closure Normal does not just apply to UIs of course.