The Future is Frameworks, not Modules Antranig Basman fluidproject.org.

The Futureis Frameworks, not Modules

Antranig Basmanfluidproject.org

The problem of software

• Failure of composability

— combining modules A and B creates a system with greater than linear increase in complexity

• Failure of flexibility

— addressing tasks X and Y involves more work than the union of the factored pieces of X and Y

The problem of software

• Failure of composability

complexity(A + B) > complexity(A) + complexity(B)

• Failure of flexibility

cost (X + Y) > cost(X) + cost(Y)

Your Future

C = F + Axγ

(Feel free to stare at the ceiling)

DevelopmentCosts

Costs ofFramework & Tools

Functionality deliveredto users

γ > 1: Ball of mud, junkheap, death

γ = 1: Scale-free development, endless life, “Code utopia”

This is your app

We’re not getting very far

•OO in many cases makes problems worse

– n2 adaptor problems

– opacity of APIs which are just referring to data

•Functional idioms allow better factoring

– but lead to even more opacity with higher-order functions

(since 1960)

JavaScript is a GREAT environment

•Unexpectedly, for solving these highest-scale engineering problems

•JSON is a superb dialect for expressing

– a general model for state

– representation of structures like syntax trees

What is in Fluid Infusion?•The Fluid Skinning System (FSS – a CSS

framework)

•Some fundamental facilities

– Infusion Event System

– Fluid Renderer

– Data Binding and the “Change Applier”

– Accessibility assistance (keyboard binding, ARIA)

•Some “widgets” – the Uploader, Reorderer, UIOptions and InlineEdit

•The Infusion IoC System

Elements of the solution

•IoC system with some concepts inherited from Java world, but much cooler

– A “context” is any element of the tree being constructed

– Entire tree is addressible using context + path expression syntax

– JSON-equivalent model allows working with application as document

What is a “component”?

•A “unit of work”

•An actual “widget on the screen”

•The result of a decision about an implementation strategy

•A context for further decisions

ALL OF THE ABOVE

Structural Scoping

What is a “component tree”?•A collection of all the “widgets” you

made

•A map of all the state in your application

•A map of the dependence structure of your code

•A computational structure like an AST

•A map of nested “scopes” like a call stack

ALL OF THE ABOVE

A “demands block”

fluid.demands("fluid.uploader.totalProgressBar", fluid.uploader.multiFileUploader", { funcName: "fluid.progress", container: "{multiFileUploader}.container" });

A “demands block”“demanded function name”

“context name to match”

fluid.demands("fluid.uploader.totalProgressBar", fluid.uploader.multiFileUploader", { funcName: "fluid.progress", container: "{multiFileUploader}.container" });

“contextualised path reference”“pseudoargument name”

“disposed function name”

Which was the most crucial

feature lost when JavaScript was created from

LISP?

I HOMOICONICITY

Designing for Context

Disability is contextual

Disability is environmental

What is accessibility?

Accessibility is...

the ability of the system

to accommodate the needs of the user

Accessible systems are...

•Flexible

•Separable

•Modifiable

“I can’t even imagine what a better UI for me would look like, because I’ve spent the past 13 years of my life adapting to the computer.”

- Johnny Taylor, unboundedexistence.com

No Black Boxes

Unlock your markup

Let developers and users in

A widget isn’t just one thing

Question the rules

Open Architecture:

Markup example: Dojo

<div class="dijitDialog" tabindex="-1" waiRole="dialog" waiState="labelledby-${id}_title"><div dojoAttachPoint="titleBar" class="dijitDialogTitleBar">

<span dojoAttachPoint="titleNode" class="dijitDialogTitle" id="${id}_title"></span> <span dojoAttachPoint="closeButtonNode" class="dijitDialogCloseIcon" dojoAttachEvent="onclick: onCancel, onmouseenter: _onCloseEnter, onmouseleave: _onCloseLeave" title="${buttonCancel}">

<span dojoAttachPoint="closeText" class="closeText" title="${buttonCancel}">x</span>

</span></div><div dojoAttachPoint="containerNode" class="dijitDialogPaneContent">

</div></div>

Markup example: jQuery UI

Markup agnosticism: Infusion

<table summary="The list of files"> <tbody> <tr class="flc-uploader-file"> <td class="flc-uploader-file-name”>File Name</td> <td class="flc-uploader-file-size”>0 KB</td> </tr> </tbody></table>

fluid.defaults("fluid.fileQueueView", { selectors: { fileRows: ".flc-uploader-file", fileName: ".flc-uploader-file-name", fileSize: ".flc-uploader-file-size", fileIconBtn: ".flc-uploader-file-action", errorText: ".flc-uploader-file-error" }

Actually a TEMPLATE (Fluid Renderer)


var jFileName = dom.locate(“fileName”);

Transparent

Apps•M is where it’s at

•Events inside and out

•Assistive technology inside the Web, not bolted on

Find usgithub:

https://github.com/fluid-project/infusion

tweet: @FluidProject, @amb26ponder

web: fluidproject.org

IRC: irc.freenode.net/fluid-work

Infusion 1.4 – coming early June

https://github.com/fluid-project/infusion

The Future is Frameworks, not Modules Antranig Basman fluidproject.org.

Documents

Transcript of The Future is Frameworks, not Modules Antranig Basman fluidproject.org.