The Future is Frameworks, not Modules Antranig Basman fluidproject.org.
Transcript of The Future is Frameworks, not Modules Antranig Basman fluidproject.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”
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
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”
“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 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)
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" }
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" }
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>
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