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 <developer...@gmail.com>: > 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 http://matrix3d.github.io/assets/ > 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 <harbs.li...@gmail.com>: > >> 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 >> > >> > >> > >> >> >
