I was speaking to a friend that has some JavaScript developers working for him. They use React and React/Native for their mobile apps. His feeling is that web-centric apps (e.g. Amazon.com) are going to be replaced with mobile apps since mobile devices are cheaper than laptops. They are concentrating their app development to server-side services with native apps delivered via React/Native.
IMO then, what FlexJS needs is the ability to go native. This isn't necessary for a 1.0 launch, but having FlexJS/Native with applications constructed in ActionScript and MXML and then cross-compiled into Swift or Java could go a long way to make FlexJS the platform for cross-device development. ‹peter On 1/13/17, 8:58 AM, "Harbs" <harbs.li...@gmail.com> wrote: >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 <christofer.d...@c-ware.de> >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" <aha...@adobe.com>: >> >> >> >> On 1/12/17, 12:46 AM, "carlos.rov...@gmail.com on behalf of Carlos >>Rovira" >> <carlos.rov...@gmail.com on behalf of carlos.rov...@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 >>> 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 >> >> >> >
