1. Luckily we are not under any deadline at this time, but we did get a zing from a code review we had. They recommended we should migrate at some point. However our branch is always behind the industry curve for certain things. For instance we have a large population of Win7 users still.
2. It would be based on perspective, luckily we use most of the common components and charts. 90% could be acceptable for conversion. This is of course removing any customization to components from the equation. Those will always require a change. 3. I might here and there, but I've received a few new people that are consuming additional time getting them up to speed. Causing me to catch up on work. I like the idea of your comparison list. It would be a large table, but very functional. Could we have a new namespace of AS components that are stripped down that are 100% compatible to the FlexJS side? People could start converting over existing apps slowly while still being able to deploy to their current targets. Could also allow a bit more decoupling from the core player AS. I would find this more interesting of an avenue. -Mark -----Original Message----- From: Alex Harui [mailto:aha...@adobe.com] Sent: Tuesday, January 17, 2017 4:29 PM To: dev@flex.apache.org Subject: [Non-DoD Source] Re: [FlexJS] Some things still missing ni FlexJS On 1/17/17, 3:43 AM, "Kessler CTR Mark J" <mark.kessler....@usmc.mil> wrote: > I do not use AMF for enterprise level applications. AMF falls short >of our requirements. But the bottom line for us for converting to FlexJS >would be seamless operation(look / feel / interaction) in all major >browsers (excluding IE) and the ability to compile it using our existing >spark based projects without having to having to create hundreds of JS >beads / customizations. Understandably heavier, but compatibility is >more important. > > The only selling point to me for converting to FlexJS would be that I >could cross compile Adobe Air apps and FlexJS. If not, then it would be >creating everything from scratch again. If that's the case I would have >to consider all the available SDK's out there before making a decision. Thanks for posting this. Some questions: 1) Are you under any deadline to migrate off of Flash? 2) If it turned out that 80% or 90% of your code would cross-compile would you still consider a full port to other SDKs? I doubt we'll ever get to 100%. 3) Would you have time to help get us to 80% or 90% or 99.5%? This got me thinking about whether Falcon could easily be tweaked to output a list of all APIs used by a code base. Then we could see how much of the Flex SDK and Flash APIs and other third-party APIs someone was using. It turns out that Spark Button has about 120 public APIs! It will be awhile if ever before FlexJS reproduces all 120. But my bet is that most of you only use about 12 APIs. While we have the Express set, and I've shown that porting most of Spark and MX on top of UIBase is "possible", in between there is the possibility of a "Spark-ish" set that builds on top of Basic like Express did and only supports the 12 popular Spark APIs for Button, etc, eventually adds a few more, but never promises to do all 120. Thoughts? -Alex
