Actually it would be more easy, if adobe just convert their flashplayer to
render on webgl and that would work for all...

2017-01-13 15:15 GMT+00:00 Dev LFM <>:

> Hi all,
> For me, as I since 8 years constantly developed content editors for
> printing labs (basically I would use a Canvas on FlexJS), it was the no
> crossbrowsing differences, one player that behaves the same on all targets
> (This is the key). My company currently relies on Flash to sell.. and
> html/js fails on this hard... so in the end I will probably deploy a Air
> release..
> Then it was the IDE with good tools for productivity and debug. It is a
> waste of time patching to solve some IE/Firefox/Chrome issue..
> Thats why, and listen to this pls, the most valuable thing that FlexJS can
> sell, is the Stage3D/WebGL targets as replacement to flashplayer. Then with
> Cordova for mobile, and Electron for desktop, we would target everywhere
> and win marketshare like in flex/flash did.
> We should get that flexjsstage3d from
> html5/flexjsstage3d/bin/js-release/ and help him finish all compatibility
> with flash stage3d, then port the starling/feathers and we would be on top
> again.
> AMF and ResourcesBundles / I18N are a must, modules could wait..
> This is my vision for the future.
> 2017-01-13 13:58 GMT+00:00 Harbs <>:
>> I agree with Chris that target #1 is developers migrating from Flash.
>> But, #2 is a very close second with JS developers looking for better
>> productivity.
>> #2 is where we can have a real win in terms of adoption. I think the
>> reason js developers seem to always flutter from framework to framework is
>> that they’re looking for better efficiency and not really finding it.
>> I’m not sure what the minimal feature set for version 1 is, but I’m not
>> sure what percentage of enterprise apps use AMF modules and resource
>> bundles. It would be interesting to know if there’s any indicators on that.
>> On Jan 13, 2017, at 10:44 AM, Christofer Dutz <>
>> wrote:
>> > 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.
>> >
>> > Chris
>> >
>> >
>> > Am 13.01.17, 00:24 schrieb "Alex Harui" <>:
>> >
>> >
>> >
>> >    On 1/12/17, 12:46 AM, " on behalf of Carlos
>> Rovira"
>> >    < on behalf of>
>> 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
>> >> move
>> >> 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,
>> >    -Alex
>> >
>> >
>> >

Reply via email to