UI Markup Nirvana

I have been pushing an idea for quite a few years. In a nutshell it is a better markup technology than classic HTML and 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.

This pseudo-declarative nirvana over HTTP for a hybrid fat/thin reality needs to be built on a markup language that itself is pseudo-declarative, without the 'web' page aspect.

I've 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:

Produced by OmniGraffle 7.10.1 2019-06-10 16:05:15 +0000 Canvas 1 Layer 1 Angular / Knockout (HTML+JS) 2000 2010 Thicky (Groovy/Java) Swiby (JRuby) Long Term Persistence for Java Beans Shoes (Ruby) QML (JavaScript) 2005 2015 Node.QML Turing complete HTML : 2020 Flutter (Dart) SwiftUI (and many since)

In red is AngularJS of which tool HTML from pure declarative markup to into a pseudo-declarative future. This extended/polluted HTML is something you love or hate. Many client-side web frameworks have bee created since, but Angular1 started it in 2009. In green, mauve and blue are the technologies conforming to the pseudo-declarative ideals and are currently vying for dominance.

Historical: Interface Builder's LISP format - 1986

Not depicted in the timeline above, and never an Apple-endorsed thing, by the team Denny Bolay led to show Steve Jobs this Interface Builder idea uses Lisp for the source format. Both the designer tool and the runtime interpreted the Lisp into a context suitable for the purpose at hand. The Lisp format source could be edited in the designer UI or in plain text files (under source control), and it would all work. Here's a blog entry: Interface Builder's Alternative Lisp timeline. What if Tim Berners-Lee had seen that and not SGML before he stared work on his Next towards the world wide web?

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

Historical: 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.

Historical: 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 sequences. 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 former colleague (Vijay Jambu) and I had ready a demo app that used Google's cloudy "AppEngine for Java" as a backend on the day it was launched, as ThoughtWorks was in the alpha-test programme. 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/Trolltech folks make a nice DSL for their QT technology originally called alternatively called Kinetic, Qt Declarative, or more recently just QML. It really wasn't one language, but two, as there's a seamless escaping mechanism to move from the pure DSL to the woven-in JavaScript. QML apps are interpreted, though complexity is delivered via C++ linked pieces that you could make in-house.

By 2013, after much uncertainty, QT and QML have a better future with "The Qt Company" (a Digia subsidiary). Making apps for multiple 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.

Because of the interpreted nature of the proposition, QML could easily be a page-by-page deliverable to a browser or browser plugin. Well, as long as was able to sandbox apps/pages (one of the principles of containment).

Google's Flutter - 2015

Now dominant, Flutter DSL and it's coupled 3GL Dart can deliver applications to iOS and Android. Shortly Mac, Linux, Windows, and Fuchsia. ChromeOS natively in the future perhaps, though that's via Android support presently. QML must have been an inspiration for this. To my eye the code for Flutter solutions looks to be generally 10-20% more verbose. It is also the case that Flutter is compiled through some sophisticated toolchains to the target platform.

Apple's SwiftUI - 2019

Apple's answer to Flutter (and QML by implication), but perhaps Apple ecosystem only. In other words no Android, Windows, Linux, or Fuchsia, unless third parties deliver that.

My blog entries towards this agenda: