flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: New Flex to JS project
Date Wed, 09 Jul 2014 05:56:37 GMT

On 7/8/14 11:22 AM, "DarkStone" <darkstone@163.com> wrote:
>My point is, the mobile applications made with the current Flex SDK are
>running very smooth in modern cheap mobile devices, and they will be
>running even smoother in every 3 months.
Hi Darkstone,  Thanks for that info.  At one point I was told that battery
life was going to limit device cpu performance growth rates.  Is that no
longer the case?
>So I believe the performance issue of Flex is not our primary concerns,
>no need to re-design the FlexJS architecture from the ground up, just
>base on the current Spark architecture and make improvements, that's fair
>enough in my opinion.
It is nice to know that more apps have a chance to work running on JS
emulations of Flash-isms like e4x, weak references and xml notifications,
but are you sure "all" apps will?

At one point in Flex's history, lots of apps worked as long as you had
recent desktop hardware and a fast intranet.  Then apps got bigger, folks
tried to deploy those bigger apps on slower networks, and then a new wave
of mobile devices came out that had performance constraints and Flex lost
momentum.  Could that happen again?  Could there be some other frontier of
new technology that will run JS in a constrained environment?

I've already spent a lot of time trying to improve the current SDK.  I've
given up and am starting over, designing it for what we want it to do,
instead of trying to emulate things we wish the JS platform had, because,
at the end of the day, if you are running on top of emulations, folks can
still point fingers at it and say that is isn't as good as "native".
Every time there is additional CPU capability, eventually the OS and other
apps starting eating away at it.  We would never have deployed
auto-updaters 10 years ago, but guess how many are now running on my Mac?
More and more people have faster networks, but will your app be the one
that works when the network is busy with other traffic?

One of the reasons I "gave up" is because the SDK is very fragile and full
of interconnected class dependencies.  It is hard to separate things into
smaller chunks.  Folks have mentioned that as an inhibitor to contributing
to the project.  The components I'm working on and their beads are
intended to make contributing easier.  By having good separation, you can
hopefully put together another bead and contribute it without fear of
breaking something else.  Yes, there will be a lot of beads but I'm
hopeful that tools and documentation will help you manage.  If folks can
manage choosing things in a WalMart, hopefully they can choose beads.

It will be interesting to see how Erik codes up the JS side.  I would
build it out of JS beads so there is that separation.  But doing it for
all of current Flex sounds like a considerable task.  You can probably
make good progress in the early going, but as you get closer to emulating
all of current Flex you have to start reproducing those awful
interconnected class dependencies and things may become fragile again (or
fat and slow)  But there's no way to know for sure until folks dive in.
In my presentations I talk about doing an "80% Spark" component set that
never does "everything" the current SDK can do.  It simply doesn't
implement the hard stuff, but that means that folks have to do more work
during migration.

Anyway, I don't think we have to decide on one approach now.  I don't
think anything Erik said weakens the potential of FlexJS.  I still hope to
convince him he is simply implementing one of many component sets.  I
think it will be good to offer folks different trade-offs on how much
migration work vs options on using different JS frameworks under the
covers or having a lighter weight JS download.  But I do hope folks jump
in an help on either effort.  My biggest fear is that folks will sit on
the sidelines hoping that someone can in fact produce the zero-migration
JS framework that has little additional overhead.  We've got a lot of work
ahead of us, no matter what.

>I do agree the current Flex SDK is fat and old.
>For fat: I think we should get rid of the halo (mx) legacy stuff, and
>continue improving the Spark architecture to lose weight and gain
That probably won't help Spark.  It lives on top of a lot of mx stuff.

>For old: I think we should focus more on the mobile supports of Spark
>framework, like adding more mobile components and skin themes (I know Om
>is working on one).
Any one interested in doing so is welcome to do so.  That's the Apache
Way.  For now, I'll still be plugging away at making Flex the fastest way
to create JS apps on any JS framework.


View raw message