flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: [FlexJS] Some things still missing ni FlexJS
Date Fri, 13 Jan 2017 08:44:12 GMT
Well from my point of view it was the whole “write once run everywhere” thing. 
I was totally annoyed of having to write UI things once and then patch and bugfix things for
all the other Browsers.

But in general I think you (Alex) and I have one great difference in our assumption of who
will probably be our generation 1 users.

You assume it’s mainly the people wanting to create new applications. That’s why you see
1.0 the way you do it. 

I, on the other side, think that our generation 1 users would probably be people migrating
legacy Flex applications to FlexJS.

The reason, why I think that way, is that no matter what bank or insurance company I have
worked for in the last 4 years. I always encounter Flashplayer maintenance updates. I usually
ask why Flash? And always get the answer: “We still got some legacy applications that need
that”. A little more investigation usually shows that there are loads of applications still
in production internally which are built in Flex. There are plans to migrate to JavaScript,
but there just isn’t enough budget to simply rewrite something with the only benefit in
the end being no longer to require the Flashplayer. For me “Flex” is stigmatized. Even
if it’s not deserved, it’s still a reality. I doubt that someone wanting to try out the
latest cool stuff will tend to go directly towards a stigmatized technology, not if there’s
all the cool React, Angular2, Typescript and similar stuff out there that does “the same
we promise to provide”. 

If we get FlexJS to a point where it’s easy to migrate we sort of offer the only option
the people stuck in a dead-end with Flash have to migrate to JavaScript at a fraction of the
costs. That’s why I’m continuing to argue to add the most essential Flex features to FlexJS.
It doesn’t matter if AMF support is slower than JSON or than AMF was on Flash. It just have
to be there to ease the migration path. Same with skinning. It’s been used quite a lot and
this I one concept where migrating isn’t just a matter of replacing some classes. If there
is no skinning support all the Components have to be completely rewritten. Eventually we could
do without modules, even if I think they are essential, but for me it’s:

- AMF Support
- Skinning
- Modules
- ResourceBundles and I18N

Which we need in order to ease the migration path.


Am 13.01.17, 00:24 schrieb "Alex Harui" <aharui@adobe.com>:

    On 1/12/17, 12:46 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
    <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
    >We need some strategy, and we must think about what others are giving in
    >comparison with us.
    >In LTE I think our solution win, but right now is complicate convince
    >business to choose us over Angular/React, since is world trending.
    >So I'm with Chris that we need to give things others doesn't have, for me
    >maven is one of that things, but is something in the backstage.
    >We need more things on that make us different. One of those things is AMF,
    >and since many Flex apps out there have it is a key point to make them
    >to FlexJS.
    I guess I'm wondering why folks chose Flex in the first place.  Was it
    some cool feature?  If so, what was it?  My assumption has been that the
    real reason folks chose Flex (or maybe the reason they stayed) was about
    Developer Productivity.  A feature fight will be very difficult for us to
    win without more contributors.  Any feature we can produce as an advantage
    would likely be short-lived:  the other frameworks will simply produce the
    same feature.
    But we can win or at least compare more favorably on helping you get your
    app into production faster and having fewer maintenance issues because we
    are a single-source provider of both a declarative language and an
    object-oriented language and have a tool chain in our workflow.  And, I
    still believe that having a SWF version of your app will be very valuable.
     For those who are interested in modules, without the runtime verification
    that Flash has, you will be at the mercy of any synchronization issues
    between the code that loads the module and the code in the module.  Flash
    will tell you right when the module loads that it doesn't meet the
    interface contract.  When will you find out when running just in JS?
    My 2 cents,

View raw message