The pyramid of application development

Rik Arends @rikarends @ajax_org

Then• 1983 Commodore 64– 65536 bytes of ram– 1 mhz

• Focus: applications

Now• Current PC– 2.000.000.000 + bytes of ram– 4x3000 mhz +

• Focus: applications

How do layers emerge• Competition creates layer complexity• A new layer in between the app and the

hardware is needed to optimize reach– Ms / IBM PC, OS / runtimes

Why layer independence is important

• Monopoly emerges through multi-layer controlled competition destruction

• Diversity is healthy– Never stops optimizing areas– Natural selection works by selection from the

diversity, not by directed adaptation

When do you need standardization• Up: abstraction, Down: standardization• Progress halted because of not abstractable

scalability differences• Competition incredibly technical• Lower level innovation useless because of too

many verticals• Group competition with larger entities

Where are we now• Standardization in the browser made it

scalable to abstract on base level• Browser competition now focused on

performance and strict compliance

What do JS libraries do• Abstract browser differences• Optimize effort vs result• Modularize and reuse

JS Library differentiation• DOM operation automation:– jQuery, Prototype, Mootools

• Widget libraries:– Dojo, Qooxdoo, Ext

• Domain specific methodologies– Ample, Ajax.org Platform

Domain specific methodologies• Compression through projection• Language optimized for understanding• Cross-over at optimal points

Browser domain specific• HTML– Document and spatial structure

• CSS– Styling

HTML 5 • Started as the DSL for web applications• Moved towards adding features • HTML is the assembly language of the web• Does not solve the application-level

integration

Domains in an application• Layout• State• Style• Templating• Data bindings• Communication

DSL approaches• Tree hierarchy (markup, json)• Functional Reactive (signal-slot)• Query selectors (css-selectors, xpath, json-

path)• Expressions• Code flow syntax (e4x, live markup)

Why are we doing this?• Our time is expensive• We want to build cool stuff• It should be fun to make – and maintain

Ajax.org DSLs • Ajax.org Markup Language– Static application declaration

• Live Markup– Dynamic application declaration

• Layouting• Skinning• Expression CSS

Ajax.org Markup Language• Application is represented in a DOM tree– XML (AML) definable– JSON definable– JS DOM-api controllable

The XML way<div> <a:chart> <a:axis mode="2D"> <a:graph mode="line" formula="sin(x)" /> </a:axis> </a:chart>

<a:button>Test</a:button>

</div>

The JSON wayvar chart = new apf.chart({ htmlNode : document.body.firstChild, childNodes : [ new apf.axis({ mode : "2D", childNodes : [ new apf.graph({ mode : "line", formula : "sin(x)" }) ] }),

new apf.button({caption : "2D”}) ]});

JS and W3C DOM APIvar chart = new apf.chart();apf.document.body.appendChild(chart);

var axis = chart.appendChild(new apf.axis());axis.setAttribute("mode", "2D");

var graph = axis.appendChild(new apf.graph());graph.setAttribute("mode", "line");graph.setAttribute("formula", "sin(x)");

var graph = axis.appendChild(new apf.button());graph.setAttribute("mode", "line");graph.setAttribute("formula", "sin(x)”);…

Dynamic UI - Live Markup<?lm var x = 10; <ul>{ each([mdlExample::foo/bar]) { <li>{

[@name].toUpperCase() + x }</li>

} }</ul>?>

Dynamic UI - Live Markup<?lm var x = 10; <ul>{ each([mdlExample::foo/bar]) { <li>{

[@name].toUpperCase() + x }</li>

} }</ul>?>

Live markup syntax• Extended JavaScript

– [] for query selectors– {} for code mode– In string parsing

• E4X style xml literals (literal is a string, not an object)• Overloaded operators• Async calling abstracted (use sparsely)• Fast execution and compilation• Auto concat and auto output

A lot of work in HTML:• Synchronizing data with the UI• Dealing with the server• Maintaining state• Undo / Redo / Offline• Templating from data• Dynamic vector graphics

Loading data

<a:model id = "mdlUsers" src = "http://example.com/users.php" />

Displaying data - databinding<a:tree model = "mdlUsers" each = "[user]" caption = "[@name]" icon = "icoUser.png" />

Displaying data – a bit more complex<a:tree each = "[mdlUsers::user]" caption = "{[@fname].uCaseFirst()} [@lname]" icon = "{[@icon] or 'icoUser.png'}" />

Managing state and simple logic<a:thumbnails each="[mdlThumbs::thumbs]" image="[@url]" thumbsize="{sld1.value}"/>

<a:slider id="sld1" value="90" min="10" max="150" />

Managing state – a bit more complex<a:tree id="tree" actiontracker="atTree" ... />

<a:label value="[{tree.selected}::@name]" />

<a:button disabled="{!atTree.undolength}" onclick="..."> Undo</a:button>

Undo and Redo<a:tree actiontracker="atTree" ... />

<a:button onclick="atTree.undo()">Undo</a:button><a:button onclick="atTree.redo()">Redo</a:button>

Vector graphics<div> <a:chart> <a:axis mode="2D"> <a:graph mode="line" formula="sin(x)" /> </a:axis> </a:chart>

</div>

Putting it together• Collaborative applications– Databinding (remote)– Complete widgets– Server communication

Collaborative Demo

Vision• The browser is the application platform of the

future

What we need• Full feature UI platform• IDE• Desktop integration• Serverside integration• Make the browser compete with

Flash and Silverlight

APF Roadmap• Apf 3.0 stable early Q1 2010• Apf 3.1

• contentEditable• WAI-ARIA support• Virtual viewport for all widgets• Offline applications• Multiple query languages in

Live Markup (JSON-Path, CSS3)

Thank you• Rik Arends @rikarends rik@ajax.org• www.ajax.org @ajax_org