FlexJS

1. FlexJS 360|Stack Web Session #4 Alex Harui Apache Flex PMC Chair October 23, 2013

2. 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

3. 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.

4. Agenda • Why • What • Highlights • Demo • When • How • Deeper Dive

5. 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.

6. 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)

7. Several Approaches • Emulate Flash Player • Emulate current Apache Flex SDK • New framework

8. 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/

9. 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

10. 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

11. 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?

12. 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.

13. Familiar Constructs • MXML DataBinding • Can be optimized where needed • MXML States • Component Names • Button • Label • DropDownList • Etc.

14. 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

15. DEMO

16. DEMO • http://people.apache.org/~aharui/FlexJS/DataBindingTest/bin/js-release/ • Shortened URL: http://s.apache.org/MQT • JS debug and SWF versions: • http://s.apache.org/ukh

17. 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.

18. 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.

19. 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”

20. Block Diagram Button.as (SWC) ApplicationMXML & AS SWF Falcon HTTPService.as (SWC)

21. Block Diagram Button.as (SWC) ApplicationMXML & AS Button.js JS FalconJX Google Closure HTTPService.js HTTPService.as (SWC)

22. Questions so far? We’re about to dive deeper.

23. 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

24. 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.

25. 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

26. 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

27. 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.

28. Javascript == Play-Doh • Play-Doh is unstructured. You can create just about any shape and create small structures with it.

29. JavaScript == Legos • There is some structure in JavaScript. • Legoland has some big structures, but the hotel is not made up of Legos.

30. 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?

31. Run-time Checking • Verifies that moving parts fit.

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. Multiple Component Sets • A one-size-fits-all Button works in most places, but not all

39. Multiple Component Sets • A one-size-fits-all Button works in most places, but not all

40. 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 frameworksor a set of components that are HTML5 dependent.

41. 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

42. 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.

43. 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

44. 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.

45. 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

46. Button.as • Has no model. There are no properties! • CSS for Button specifies a ButtonViewas 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.

47. 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.

48. Button.js • Thin wrapper around HTML Button element • TextButton.js is same since text behavior is built-in to HTML.

49. 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.

50. 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