There is not a lot written about what Dart is actually going to look like, so I will speculate a little. ThoughtWorkers are going to cringe as I take the opportunity to bring up something I have been chasing for years.

Convergence of Declarative and Procedural UI markup languages

It has never been described as pleasant jumping from a declarative form like HTML to a turing-complete procedural form like JavaScript. That we use an escape mechanism <script>JS here</script> is only the first clue that the combination is as ugly as hell. JavaScript was defined after HTML, so it is interesting to wonder what the pair would look like if JavaScript had come first. I am sure it would look more like JavaScript and less like HTML. The clue is the huge amount of libraries today that retrofit JavaScript with increasing elegant UI morphing capabilities. JQuery is perhaps the best known of these, but there are others that are compelling too.

Columns of UI setup code - bad bad bad

There is a style of UI programming that is common, where methods and functions separate sections of UI setup code in a classing OO design. Model View Controller (or related patterns) are possible, but the largest visual aspect to actually developing the source for these, is the long columns of ‘object.method(params)’ with the occasional for loop, or if condition. Nesting is only there if the developer has not broken the setup into separate methods.

Swing, SWT and GWT are all examples of this. Elaborate UIs can be constructed using them, but there’s none of the elegance of the original HTML, in that nesting of the UI logic, does not map to visual nesting. That nesting, in HTML 1.0, was the thing that allowed unskilled people to have a go at editing pages, and hitting refresh in the browser.

Some meld of JSON, closures is my hope for Dart.

Here’s something that Duda Dornelles put together using Node.js, that could execute directly in a browser context:

html(
     head(),
     body(
         h1("MJS example"),
         div({id: 'header'},
             ul({id: 'nav'},
                 li(a({href: '/home'}, 'Home')),
                 function() {
                     if(loggedIn) {
                         return li(a({href: '/logout'},"Logout"));
                     }
                 }
             )
         )
     )
 )

I cannot help feeling though that it is too lispy, with the current ugliness of JavaScript interspersed. I would prefer something more like what is possible in Groovy, Ruby or Python with builders/closures:

html {
    head {},
    body{
        h1 "MJS example",
        div { 
	        id: 'header',
            ul {
	            id: 'nav'
                li { 
	                a { href: '/home', txt: 'Home' }
	                ifLoggedIn
	            }
            }
        }
    }
}
function ifloggedIn {
    if(loggedIn) {
        return {
            a { href: '/logout' txt: "Logout" }
        }
    }
}

I have not shown above (because I’m trying to keep close to Duda’s sample) the Turing completeness that could be worked in whether would be best or worse practice with the hypothetical markup language.

With a bootstrap for the browsers shipping today

You would client side code in this style today, but only if you’ve made a bootstrapping JavaScript library that can act as parser and liaison to the inevitable DOM mutations. We know this is possible as Cappuccino has done this for many years - refer 280slides Note that Cappuccino is another column-of-operations style of UI markup. That is because what it is inspired by (Objective-C) is also in that style, notwithstanding InterfaceBuilder and the resulting nib/xib files which are not human readable.

Summary

I asked Martin Fowler what this style is called, and he says that it is ‘Nested Function’ form/style. He mentions in his DSL book, and he reminds me that it is very common in the Lisp world, and uncommon in the OO world.

Incidentally, I remember a markup for an early version of InterfaceBuilder (‘Next’ in the late 80’s, before Apple subsumed it) that used a form of Lisp for the format of the saved UI files. It used Lisp for the WYSIWYG load/save cycle, as well as (I think) the run-time execution. I’ve emailed a bunch of people about that time before the format was changed to ‘nib’ and nobody can corroborate, so I must have dreamed it.

Folks that are interested should read about Erector and Shoes, and Duda’s MJS and something he found that is similar - node.magic_dom

Anyway, I’m hoping that Google Dart stuff is nested functions, interoperating with the DOM, in the sandbox, negating the need to use any HTML, more coffee than ecma, and easy one the eye, with a bootstrap for modern browsers until native support is baked in.