Beholding the giant pyramid of application development; why Ajax applications are its natural top layer

The pyramid of application developmentRikArends @rikarends @ajax_org

Then1983 Commodore 6465536 bytes of ram1 mhzFocus: applications

NowCurrent PC2.000.000.000 + bytes of ram4x3000 mhz +Focus: applications

How do layers emergeCompetition creates layer complexityA new layer in between the app and the hardware is needed to optimize reachMs / IBM PC, OS / runtimes

Why layer independence is importantMonopoly emerges through multi-layer controlled competition destructionDiversity is healthyNever stops optimizing areasNatural selection works by selection from the diversity, not by directed adaptation

When do you need standardizationUp: abstraction, Down: standardizationProgress halted because of not abstractable scalability differencesCompetition incredibly technicalLower level innovation useless because of too many verticalsGroup competition with larger entities

Where are we nowStandardization in the browser made it scalable to abstract on base levelBrowser competition now focused on performance and strict compliance

What do JS libraries doAbstract browser differencesOptimize effort vs resultModularize and reuse

JS Library differentiationDOM operation automation:jQuery, Prototype, MootoolsWidget libraries:Dojo, Qooxdoo, ExtDomain specific methodologiesAmple, Ajax.org Platform

Domain specific methodologiesCompression through projectionLanguage optimized for understandingCross-over at optimal points

Browser domain specificHTMLDocument and spatial structureCSSStyling

HTML 5 Started as the DSL for web applicationsMoved towards adding features HTML is the assembly language of the webDoes not solve the application-level integration

Domains in an applicationLayoutStateStyleTemplatingData bindingsCommunication

DSL approachesTree hierarchy (markup, json)Functional Reactive (signal-slot)Query selectors (css-selectors, xpath, json-path)ExpressionsCode flow syntax (e4x, live markup)

Why are we doing this?Our time is expensiveWe want to build cool stuffIt should be fun to make and maintain

Ajax.orgDSLsAjax.org Markup LanguageStatic application declarationLive MarkupDynamic application declarationLayoutingSkinningExpression CSS

Ajax.org Markup LanguageApplication is represented in a DOM treeXML (AML) definableJSON definableJS 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(newapf.axis());axis.setAttribute("mode", "2D");var graph = axis.appendChild(newapf.graph());graph.setAttribute("mode", "line");graph.setAttribute("formula", "sin(x)");var graph = axis.appendChild(newapf.button());graph.setAttribute("mode", "line");graph.setAttribute("formula", "sin(x)”);…

Dynamic UI - Live Markup<?lmvarx = 10; <ul>{each([mdlExample::foo/bar]) { <li>{ [@name].toUpperCase() + x }</li> } }</ul>?>

Live markup syntaxExtended JavaScript[] for query selectors{} for code modeIn string parsingE4X style xml literals (literal is a string, not an object)Overloaded operatorsAsync calling abstracted (use sparsely)Fast execution and compilationAuto concat and auto output

A lot of work in HTML:Synchronizing data with the UIDealing with the serverMaintaining stateUndo / Redo / OfflineTemplating from dataDynamic 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 togetherCollaborative applicationsDatabinding (remote)Complete widgetsServer communication

VisionThe browser is the application platform of the future

What we needFull feature UI platformIDEDesktop integrationServerside integrationMake the browser compete withFlash and Silverlight

APF RoadmapApf 3.0 stable early Q1 2010 Apf 3.1contentEditableWAI-ARIA supportVirtual viewport for all widgetsOffline applicationsMultiple query languages in Live Markup (JSON-Path, CSS3)

Thank youRikArends @rikarendsrik@ajax.orgwww.ajax.org @ajax_org

Beholding the giant pyramid of application development; why Ajax applications are its natural top layer

More Related Content

Viewers also liked (20)

Similar to Beholding the giant pyramid of application development; why Ajax applications are its natural top layer (20)

Recently uploaded (20)

Beholding the giant pyramid of application development; why Ajax applications are its natural top layer