flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Starting with the Whiteboard Code
Date Tue, 07 Feb 2012 12:46:13 GMT

On 2/6/12 8:51 PM, "Justin Mclean" <justin@classsoftware.com> wrote:

> Anything in particular you thinking of breaking or is this just a general
> statement and more long term than short term thinking?
Nothing specific at this time.  Mainly, I will be willing to break
compatibility to achieve a significant goal, whether it is performance, DI,
unit-testing, cross-compilation to HTML/CSS/JS, accessibility, size, etc.

For sure, making the porting effort too large would cause folks to not port.
But my thoughts after the summit was that if Flex is at one extreme and
HTML/CSS/JS is at the other and we are clearly hearing the pain of going
from one to the other, I believe we could find a midpoint (not necessarily
at 50%) where all of the above goals and more are achieved such that it is
worth making a significant (although much less significant) port effort than
going the whole distance.  And I hope that with a composition-based
framework, you can make your own trade-offs as to where the midpoint is.  If
you need to bake in some heavy Flex feature because your whole existing
infrastructure is based on it, you can mix that feature/behavior in, but
then you might suffer when cross-compiling or in performance.

This is a good opportunity to point out one of the counter arguments to my
philosophy: these kinds of frameworks tend to require more configuration and
make it less approachable to newbies.  For example, today you add in a List
control, turn on dragEnabled and you can drag/drop.  That's because List has
a hard dependency on DragManager.  Once you re-package that into a behavior,
you have to configure that behavior in, otherwise turning on dragEnabled
won't do anything useful, and in some API designs, there is no dragEnabled
flag and you have to find the class/behavior to mix in out of the 1000's of
classes out there.

One of the analogies I used in the past is with screwdrivers (although
wrenches work just as well).  In the current Flex SDK, we sell only one
screwdriver.  It is that one with the fat handle that stores several tips.
That's it.  Only one to choose from, and you don't have to look ahead to
know if the screw you need to drive is phillips, regular, star, etc.  Just
grab it and go.

I do own such a screwdriver at home, but if you look through my tool
cabinet, you will also find several of those sets of screwdrivers, all lines
up with slightly different tip sizes.  And I've always preferred these sets
despite the fact that I often grab the wrong one and have to put it back and
try a couple more until I find the one I need.  Why?  Because every once in
a while, I need to drive a screw in a tight spot or carry the tool behind my
ear (mobile apps).  IOW, I'm ok with the pain because it allows
optimization.  But it is less approachable.  The choices can overwhelm and
we still need to make newbies successful.  However, I think there are other
ways to help folks manage choices, and I think I would rather we make it
possible to finish the "last mile" of optimization better than we do now so
we can have some killer showcase apps out there that folks can actually
touch and use.
Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message