Less AS3 frameworks, more native implementations, please!
The TLF framework is a good example of the current status quo regarding native implementations vs. AS3 frameworks at Adobe. Adobe is implementing core functionality (layout of text) through an ActionScript Framework and not as a native implementation in the Flash Player. Sure, you have the low-level text engine classes and API that let you actually use low-level layout and rendering, but Flash has for a long time implemented high-level API’s natively.
Lets discuss the advantages and disadvantages of using Frameworks vs. native implementations:
Advantages:
- Updatability. You don’t rely on Flash Player updates to deliver new functionality or bug fixes.
- The Flash Player download size does not increase
Disadvantages:
- Speed. If you remember my recent post on our AS3-2-Java compiler, the same code run 800 times more faster in Java than it did in the Flash Player using AS3. So expect things to run three orders of magnitude slower.
- Bloat. The framework takes a chunch of bandwidth for every piece of SWF that uses the framework, as it’s embedded in each and every SWF that uses is (yes, there’s of course the framework cache, but still, cache misses are currently more frequent than hits)
IMHO the bad _clearly_ outweighs the good. Heck, I would donate second testicle to have Flash run even a bit faster. Now fast forward to the days of Flex. You’ve got hundreds of components littering the screen are your CPU just screams for help. If you inspect your List-based component you quickly get dizzy with the number of UIComponents flying around. Not only is there one for each base component, but with Flex 4 you’re essentially doubling the number of UIComponents on screen as all of your skin files are based on UIComponent as well.
Now to me it would seem logical to just implement the UIComponent natively as it does so much of an apps work (measure, layout, (in)validation, focus & input management and whatnot). At least it would be an interesting experiment on how much every Flex app would gain from a native implementation of the UIComponent (oh, and while you’re at it, put in a native implementation for Group and GraphicElement as well).
You know, it was in 2006 when the last speed increase in the order of a magnitude was revealed by the Player team at Max 2006 2005. We need an encore! Only this time, please make that two orders of magnitude.
11 Comments
Follow me on Twitter!
Other services
Please donate testicle. We could use the speed.
Furthermore …
Adobe advises to not use TLF on mobile devices because it’s to heavy and CPU demanding and instead use the classic TextField for now.
I was told by a member of the TLF team that TLF releases are aligned with the release of Flash Pro / Flash Builder so advantage 1 is a theoretical one.
On the other hand TextField suffers from various bugs which have been there since the introduction of the TextField. TLF at least gives you some opportunity to debug things yourself, so I would definitely add this to your advantages list.
Um, I don’t know if “beeing able to debug a feature which should simply work” qualifies as an advantage.
true … in a perfect world
… but the bugs of TextField have been bugging me a lot and it was a hell to work around, when possible at all. So in that respect I think the option to debug is an advantage in the not so perfect world 
Unfortunately the tactic Adobe took with Flex and now with the TLF wasn’t to add features to the Flash Player/Platform with new ideas, instead they’ve just re-implemented the respective FP libs “better.” To them, “better” means more features. To me, it means the same tired ideas, just with more bloat.
Having extensively studied the source of both the Flex Framework and the TLF, I’d jump ship if either of the two were natively implemented in the player. Fortunately, the lower-level player libraries seem to be of much higher quality, perhaps the result of more rigorous coding standards.
Writing a rich text framework myself, I have to say, the FTE is damn near perfect. Even if all the classes weren’t final, I can’t think of any meaningful features I’d add; text decoration/interaction/layout are completely different problems than the FTE solves, and it’s an incredibly inefficient design to solve them using the same techniques as the FTE.
I’m sorry, this comment sounds amazingly arrogant and that’s not what I wish to convey at all. I like Microsoft’s ideas with Silverlight, implementing the component framework into the player itself and whatnot. But Microsoft has 1. literally decades of domain knowledge solving these types of problems, and 2. an unlimited amount of money to invest in research and development.
Adobe has so far spent lots of their R&D money on FP features, and it’s starting to pay off in a big way. But without that foundation, I feel higher level APIs in the player would simply be DOA.
I agree to a certain extent. I definitely don’t see any point for Adobe to include the whole Flex framework into the player. If you think of how much the framework has changed over the years, that would be an awfull lot of bloat to carry around in one Player. However, I still feel that the biggest problem with the Player is it’s speed of AS execution. I wouldn’t be advocating native implementations if only the Player would be able to run AS faster. (check out JITB: http://blog.joa-ebert.com/2010/08/19/introducing-jitb/).
Hell yes. Joa is a crazy inspiration to us all, and I’m excited to see all his awesome shit take off. At the same time, we can’t simply rely on faster VMs, we always have a responsibility to write efficient code and apps (noted here: http://blog.joa-ebert.com/2010/02/11/the-advantage-of-actionscript/ ).
Yeah, that responsibility is always there, no matter how fast the VM is. Anyways, I’m looking forward to using your tinytlf framework in one of my next projects.
fyi — I think your blog posts are being used by others to give credibility to their shop.
http://techliance.com/blog/frameworks/less-as3-frameworks-more-native-implementations-please.html
Jamie, thanks for letting me know.