FlexJS
360|Stack Web Session #4
Alex Harui
Apache Flex PMC Chair
October 23, 2013
Who am I?
• One of the original Flex SDK developers at
Macromedia
• VP of Apache Flex
• Apache Flex PMC Chair
• 30+ years experience
• 11+ years at Macromedia/Adobe
Disclaimer
• Even though I am a full-time Adobe employee and
spend my whole day on Apache Flex, everything I
say here is just my opinion, and not an official
statement on behalf of Adobe Systems Inc., or the
Apache Software Foundation, or even the Apache
Flex project itself.
Agenda
• Why
• What
• Highlights
• Demo
• When
• How
• Deeper Dive
Why
• Flash used to be in virtually every browser.
• AIR used to run on most computers.
• Executives no longer carry Flash-capable devices
• AIR apps require installation and upgrades.
• AIR apps have some fidelity issues (StageText)
• Flash-based solutions no longer desirable.
• Large existing MXML and ActionScript code base.
What == FlexJS
• Use MXML and ActionScript to create either SWFs
that run in Flash/AIR or HTML/JS/CSS files that
run in browsers (or anywhere HTML/JS/CSS runs)
without Flash.
• IE8, 9, 10, Chrome, Firefox, Android, IOS
• Mobile Apps via PhoneGap/Apache Cordova
• Adobe Common Extensibility Platform (a.k.a. Creative
Suite Extensions)
Several Approaches
• Emulate Flash Player
• Emulate current Apache Flex SDK
• New framework
Emulate Flash Player
• Then you wouldn’t have to change any of your code.
• But that’s a lot of work
• Fidelity/Performance issues
• See JooFlash
• http://www.jangaroo.net/applications
• Also DartFlash
• http://www.stagexl.org/
Emulate Flex SDK
• Then you’d have to change code wherever you went
straight to Flash APIs
• useHandCursor
• blendModes, filters
• Still some fidelity/performance issues
•
•
•
•
Weak references
Dictionary
E4x
Embedded Assets
FlexJS: New Framework
• Designed to be cross-compiled
• Doesn’t use AS/Flash features that are hard to
implement in JS
• New coding patterns support plug-ins and
composition.
• Incremental feature development
• Better Performance
• Smaller SWFs and JS downloads
Backward Compatibility
• If you have an app of 10,000 lines of MXML and
100,000 of ActionScript, you can rewrite all of it
when porting to some other JS framework, or port
much less of it when using FlexJS.
• Would you have re-written it anyway?
• XML handling is cumbersome in the browser. If you
were going to port your app to some other JS
framework, would you have switched from XML to
JSON anyway?
How much can you re-use?
• To the extent your application is MXML
components glued together with ActionScript that
does not access Flash APIs directly, you will be able
to re-use your code.
• No chance if you require Flash-quality video
• No chance right now if you require TLF
• Scan your code for “import flash.*” and “embed”
• Gives a good first estimate
• Events are easier to port.
Familiar Constructs
• MXML DataBinding
• Can be optimized where needed
• MXML States
• Component Names
•
•
•
•
Button
Label
DropDownList
Etc.
What’s Different
• Skinning Model
• Bitmap-based, at least on IE8 and other non-HTML5
browsers
• SVG-vector skinning support being investigated
• FXG for AS, SVG for JS
• Application is not a DisplayObject
• Multiple Component Sets
• Many different kinds of Buttons
DEMO
DEMO
• http://people.apache.org/~aharui/FlexJS/DataBin
dingTest/bin/js-release/
• Shortened URL: http://s.apache.org/MQT
• JS debug and SWF versions:
• http://s.apache.org/ukh
When
• Prototype available now.
• Hopefully alpha-quality by end of 2013.
• Beta and 1.0 in 2014.
• 1.0 means basic functionality of most current Flex
SDK components, not “near-parity”.
• But “when” depends on you. If you can contribute,
we’ll make progress more quickly.
Practicality
• Apache is an all-volunteer organization. Most
contributors work in small snippets of time. The
code patterns attempt to reflect that reality. Features
are hopefully composed of small plug-ins.
• So, instead of waiting for someone to create a Spark
Button with 124 properties, the initial Button can
just have a label and click event, then others can add
enable/disable, default button, accessibility, etc.
• Get basic functionality out now, work on harder
stuff later.
How
• New Compiler (Falcon and FalconJX)
• MXML and AS cross-compiled to JS
• SWC classes must have JS equivalent
• Standard CSS copied.
• AS code must handle standard CSS
• Custom CSS cross-compiled to JS
• JS code queries custom CSS
• Different HTML “wrapper”
Block Diagram
Falcon
Button.as
(SWC)
HTTPService.as
(SWC)
Block Diagram
Button.js
FalconJX
Button.as
(SWC)
Google
Closure
HTTPService.as
(SWC)
HTTPService.js
Questions so far?
We’re about to dive deeper.
Under the Hood
• FlexJS is a completely new code base.
• No attempt to refactor current code base
• No attempt to copy from current code base.
• JS implementations influence AS implementations
Browser-First
• Wrap built-in HTML elements
• Encapsulate and Present
• Identify good practices in the JS world.
• Package as AS classes.
• As low overhead as possible.
Other Philosophies
• Parallel Frameworks
• Plug-ins
• Composition over Inheritance
• Multiple Component Sets
• Just-in-time, not Just-in-case
• Rapid prototyping is important, but end-game
optimization is critical
Parallel Frameworks
• The component developer does the hard work:
• Creates both a Button.as and Button.js
• Essentially, writes the component twice, once in AS
and once in JS.
• Button.as can use Flash APIs
• Button.js uses HTMLElements, JS, and CSS
• The application developer writes one set of code
• Compiles and debugs in Flash
• Cross-compiles to HTML/JS/CSS
Why SWF?
• If you can still use Flash, it should save you a whole
bunch of browser-specific testing and tweaking.
• Leverage existing IDEs
• ActionScript is strongly-typed so will catch bugs
sooner.
• “The longer it takes to find a bug, the more expensive it
is to fix it”
• ActionScript VM does run-time checking.
Javascript == Play-Doh
• Play-Doh is
unstructured. You can
create just about any
shape and create small
structures with it.
JavaScript == Legos
• There is some structure
in JavaScript.
• Legoland has some big
structures, but the hotel
is not made up of
Legos.
Compile-Time Checking
• Tells you that all the
pieces you have fit.
• But what if:
• You can’t get all of the
pieces in one place?
• Pieces move around?
Run-time Checking
• Verifies that moving
parts fit.
Other Philosophies
 Parallel Frameworks
• Plug-ins
• Composition over Inheritance
• Multiple Component Sets
• Just-in-time, not Just-in-case
• Rapid prototyping is important, but end-game
optimization is critical
Beads (Plug-Ins)
• Instead of one Button with every property
imaginable, Button optional properties are packaged
into “Beads”.
• Beads are the name for plug-ins
• They should be highly-reusable
• Prompt for TextArea, TextInput, ComboBox, for example.
• Component when used as sub-components don’t
need as much as when used at top-level
• Border on TextInput in ComboBox
Beads (cont’d)
• Different code for different runtime environments
• Toss out mouseover code on mobile, swap in touch
code instead
• Use CSS to choose beads
• Wrap up a bunch of beads into a top-level
component and proxy the model to the component
API surface
Other Philosophies
 Parallel Frameworks
 Plug-ins
• Composition over Inheritance
• Multiple Component Sets
• Just-in-time, not Just-in-case
• Rapid prototyping is important, but end-game
optimization is critical
Composition
• JIT compilers are used in the runtimes.
• The more you re-use code, the more efficient JIT is
• Flex startup is actually faster without JIT because it
doesn’t re-use as much code
• A single feature can be written once and applied in
several places.
• Text prompt example
Other Philosophies
 Parallel Frameworks
 Plug-ins
 Composition over Inheritance
• Multiple Component Sets
• Just-in-time, not Just-in-case
• Rapid prototyping is important, but end-game
optimization is critical
Multiple Component Sets
• A one-size-fits-all Button works in most places, but
not all
Multiple Component Sets
• A one-size-fits-all Button works in most places, but
not all
Multiple Component Sets
• A one-size-fits-all Button works in most places, but
not all
• A choice of Buttons means you have more decisions
to make, but you don’t have to carry around excess
code.
• You can use JQuery or other JS UI frameworks or a
set of components that are HTML5 dependent.
Other Philosophies
 Parallel Frameworks
 Plug-ins
 Composition over Inheritance
 Multiple Component Sets
• Just-in-time, not Just-in-case
• Rapid prototyping is important, but end-game
optimization is critical
Just-in-Time
• Flex initializes a bunch of managers at startup that
prepare for overlapping top-level windows, tooltips,
and custom cursors.
• None of these are likely to be found in mobile apps
• You don’t even need PopUpManager unless you have
floating non-modal popups
• Choose the right PopUpManager, and only
instantiate it when you actually get around to
showing a popup.
Other Philosophies
 Parallel Frameworks
 Plug-ins
 Composition over Inheritance
 Multiple Component Sets
 Just-in-time, not Just-in-case
• Rapid prototyping is important, but end-game
optimization is critical
Prototyping vs Optimization
• How do you choose from so many different buttons?
• Need utility to help you choose
• Maybe a few heavy buttons with lots of options baked
in
• More MXML tags to write.
• You will be able to toss out code you are not using.
• Debug-mode beads can give more warnings and do
more parameter checking.
Component Patterns
• MVC
• Model Bead – stores properties
• Spark model is baked into the component
• View Bead – assembles sub-components, if any
• Spark Skins combine sub-components and the actual
visuals
• Controller Bead – manages events, updates model and
dispatches other events
Button.as
• Has no model. There are no properties!
• CSS for Button specifies a ButtonView as the view.
• ButtonView.as only knows how to display whatever
is specified by the background-image style.
• That’s what the HTML Button does so that what we’ll
encapsulate and present in AS.
• Flex buttons used for scrollbar arrows still think about
text label layout. That’s not pay-as-you-go.
TextButton.as
• Wrapper that proxies label property to model.
• CSS for Button specifies model with label property.
• TextButtonView.as only knows how to display the
label.
• Different ButtonView could know how to display an
icon with a label.
• Then you’d use a different model as well that supports
an “icon” property or style.
Button.js
• Thin wrapper around HTML Button element
• TextButton.js is same since text behavior is built-in
to HTML.
Button Skin
• For the basic component set, the skins are images
you can specify as a background-image in HTML.
• Gif, png, jpg
• They are loaded on the fly, no embedding
• But the HTML5 Button set can load SVG as
background-image
• You choose different components sets based on
target devices.
Panel.as
• Specifies a PanelView that creates a TitleBar and
ContentPane
• Another PanelView would create a TitleBar,
ContentPane and ControlBar.
• Other PanelViews would include a StatusBar
• TitleBar is a Sprite with a TextField
• Some other TitleBar could be a Sprite with FTE Text
Panel.js
• Also specifies a PanelView. This one also creates a
TitleBar and ContentPane.
• TitleBar is a DIV with some text in it.
TextPromptBead.as
• Overlays Text widget
• Different TextPromptBead can have different
strategy for when to appear/disappear/reappear.
• Different implementation could change styles and
text in a single text widget.
Next Steps
• More compiler work
• Falcon needs to able to compile current SDK.
• Falcon needs to compile and run a “large” app.
• New MXML output format needs testing
• More components: DataGrid, Charts, etc.
• Finalize names, packages, namespaces.
Help Wanted
• We need help!
• All kinds of contributions welcome on both current
SDK and FlexJS and other efforts.
•
•
•
•
Testing
Development
Documentation
Examples
Summary
• FlexJS protects your MXML and ActionScript
investment
• FlexJS apps will run in just about any browser.
• You can directly affect the growth and development
of FlexJS
Questions?
• Wiki:https://cwiki.apache.org/confluence/display/FLE
X/FlexJS
• Mailing List: mailto:dev@flex.apache.org
• To subscribe, send an email to: mailto:devsubscribe@flex.apache.org
• Prefix subjects with “[FlexJS]”
• Nabble Forum: http://apache-flexdevelopment.2333347.n4.nabble.com/