UI Markup Nirvana
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:
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
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
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:
- August 18th, 2018 » Flutter and UI Automation
- April 8th, 2017 » Node.QML would have been the key to the Ubuntu Phones's success
- November 15th, 2016 » QML's Squandered Opportunity
- September 8th, 2015 » Decorators in the DOM
- August 12th, 2015 » Making a very small MP3 player with QML
- September 30th, 2014 » QML Becomes a Viable Mobile UI Framework Choice
- September 22nd, 2014 » Cross-Platform Mobile Application Development
- September 17th, 2014 » UI Development Has Never Been More Expensive
- July 9th, 2014 » Browsing QML instead of HTML
- June 14th, 2014 » Qt, QML, V-Play and multi-platform mobile
- March 28th, 2013 » Interface Builder's Alternative Lisp timeline
- February 11th, 2013 » Push or Pull Decorators
- February 4th, 2013 » The Importance of the DOM
- January 31st, 2013 » Application Development Glass Ceilings Revisited
- January 12th, 2013 » RubyMotion in a declarative UI style
- January 12th, 2013 » Categorizing Languages
- January 11th, 2013 » QML and the new Ubuntu phone OS
- April 15th, 2012 » Application Development Glass Ceilings
- March 12th, 2012 » The Importance of Design-Mode for Client-Side MVC
- September 12th, 2011 » What is Dart going to be?
- September 26th, 2009 » Kinetic - Qt based Declarative UI (one to watch)
- April 13th, 2009 » Shoes and Swiby - walking through the example RIA apps
- April 7th, 2009 » Google App Engine for Java with Rich Ruby clients
- October 13th, 2007 » Sweb 3.0
- May 9th, 2007 » JavaFX Mobile is *just* SavaJE aquired by Sun
- March 31st, 2004 » Thicky- like the web, but with a Groovy thick-client experience
- February 16th, 2004 » Groovy - a convergence language