The way I see it, folks who are using Javascript frameworks or Flex SDK today are going to first test the waters with FlexJS to see if it supports basic things. They will quickly build some prototypes to share with their team or leads. No one is going to move production code right away to FlexJS.
If folks feel comfortable with the ease of use, extensibility and stability of FlexJS, they will start showing interest. At that point, any missing killer features can be talked about. Enterprise companies can join us in the effort to add any features they think are terribly important for them. We as a group of volunteers cannot anticipate every need and build everything up front. But I am very confident that any such feature requests can be quickly built by the community or by contributors from commercial companies. Just my 2 cents. Thanks, Om On Wed, Jan 11, 2017 at 10:40 AM, Christofer Dutz <christofer.d...@c-ware.de > wrote: > I would rather have a 1.0 that has some killer features the others don't > have. I wouldn't be working that much on something that just wants to catch > up to be on par with something else. Having distinguishable features is > essential, from my point of view, to get people to try something. > > Chris > > > > Von meinem Samsung Galaxy Smartphone gesendet. > > > -------- Ursprüngliche Nachricht -------- > Von: Alex Harui <aha...@adobe.com> > Datum: 11.01.17 17:22 (GMT+01:00) > An: dev@flex.apache.org > Betreff: Re: [FlexJS] Some things still missing ni FlexJS > > > > On 1/11/17, 1:43 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> > wrote: > > >Hi Alex, > > > >I think many people in this thread are saying "No, we'll not go to > >production without AMF and basic module support". IMHO, it would be very > >difficult to say we have 1.0 without that, since AMF/RemoteObject was in > >almost 99% of old Flex SDK, with some HTTPServices and almost no > >WebServices (I mean the MXML object). > > Is it really 99%? IMO, the question is whether calling some near-future > release 1.0 would help bring in more customers and thus more contributors. > There is no doubt that modules and AMF will attract more people, but the > longer people sit on the sidelines waiting for the half-dozen or so folks > who have committed code in the past year to reproduce what a much larger > team produced over 9 years, the less potential customers we will have > because some will be forced to move sooner than we can get all of this > stuff done. > > And when those folks are forced to move, they will have to move off of AMF > anyway. And if AMF turns out not to be performant enough, the other > customers who did wait will have to move off of AMF anyway. > > So, it is a judgement call, and I don't really care too much which release > we call 1.0. My personal opinion is that when somebody who doesn't need > AMF and modules goes to production, that is good enough, because then > another small set of customers might say "ok, that's good enough for me > too" and some of them will become committers. We just need to attract > more committers and waiting for a smaller team to produce more features > may not be the right strategy. Some folks think that the label "1.0" will > bring new customers. I'm not sure how important that is because I see > lots of other JS frameworks at versions < 0, but I don't have to sell > folks on Flex so I don't know. > > I just remembered that back in November, Prashant was trying to get AMF up > and running, but I don't know what happened to that effort. When you > finish up MDL, maybe you can help out there. > > -Alex > > > > >As well, for a basic experiment, people could go without modules, but for > >a > >producction App, a basic load of modules is needed. > > > >Then, i18n, Routing, Unit and Functionality testing and so on should come, > >but for me (If I must to choose) that could come after 1.0 > > > >For example, in my own company, without AMF and Modules I don't have > >enough > >to put FlexJS over React to ask people to use it over the other... (and I > >know that we'll find many other little things we need in the road) > > > >Just my 2ctns > > > > > >2017-01-10 18:11 GMT+01:00 Alex Harui <aha...@adobe.com>: > > > >> In my mind, there is little doubt that someone will someday implement > >>AMF > >> and not-unloadable modules. The question is when? IMO, as soon as > >> someone can tell us they've gone to production with the code we have, > >>I'm > >> willing to call that 1.0, and the people who wrote that app probably > >> migrated a single SWF, single-language, XML or REST app. Regular Flex > >> grew just fine and it didn’t support modules in 1.0. > >> > >> For sure, as we add modules, AMF, I18N, we'll gain more customers, but I > >> am hesitant to say these are all 1.0 required features. > >> > >> Thoughts? > >> -Alex > >> > >> On 1/10/17, 6:28 AM, "Dev LFM" <developer...@gmail.com> wrote: > >> > >> >+1 > >> > > >> >2017-01-10 14:09 GMT+00:00 Fréderic Cox <coxfrede...@gmail.com>: > >> > > >> >> AMF is also essential for us to take FlexJS serious as a replacement > >>to > >> >> Flex > >> >> > >> >> On Tue, Jan 10, 2017 at 2:41 PM, Vincent <vinc...@after24.net> > wrote: > >> >> > >> >> > Hello, > >> >> > > >> >> > Same points than Christopher : AMF and modules. > >> >> > The first is essential for us. > >> >> > > >> >> > Vincent. > >> >> > > >> >> > > >> >> > > >> >> > Le 10/01/2017 à 13:07, Christofer Dutz a écrit : > >> >> > > >> >> >> +1 for the AMF and +1 for not-unloadable modules. > >> >> >> > >> >> >> I see it the same way as Carlos. At the moment I see FlexJS as an > >> >> >> opportunity for companies to get out of the dilemma of being stuck > >> >>in a > >> >> >> dead end with their existing Flex applications. > >> >> >> Supporting things like modules and AMF will ease the migration > >>costs > >> >> >> dramatically. Even if AMF might be a touch slower than JSON I > >>still > >> >> think > >> >> >> it’s worth being supported. > >> >> >> > >> >> >> Chris > >> >> >> > >> >> >> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag > von > >> >> >> Carlos Rovira" <carlos.rov...@gmail.com im Auftrag von > >> >> >> carlos.rov...@codeoscopic.com>: > >> >> >> > >> >> >> "IMO, this has two halves: non-unloadable modules is > >>relatively > >> >> >> straight > >> >> >> forward to do. Unloadable modules will be a ton of work. > >>IIRC, > >> >> >> Flex 1.0 > >> >> >> and I think even Flex 2.x grew its customer base without > >> >>unloadable > >> >> >> modules." > >> >> >> If non-unloadable modules is easy to implement, I think > >>it > >> >> >> should go ASAP. > >> >> >> Then we could left unloadable modules por the future... > >> >> >> For me, AMF is a must, since many companies are using > >>it, > >> >>and > >> >> I > >> >> >> expect many > >> >> >> of them switch from old Flex to FlexJS if it's as easy as > >>change > >> >> >> only the > >> >> >> frontend. Change server code means no easy way to change, so > >> >>stick > >> >> >> in old > >> >> >> code > >> >> >> Thanks > >> >> >> 2017-01-08 9:52 GMT+01:00 Harbs < > >> >> >> harbs.li...@gmail.com>: > >> >> >> > I agree that skinning is harder than it should be. > >> >> >> > > >> >> >> > For one thing: There’s too many attributes which are set > >> >> directly. > >> >> >> More > >> >> >> > extensive use of CSS would make skinning easier. > >> >> >> > > >> >> >> > On Jan 8, 2017, at 10:49 AM, Christofer Dutz < > >> >> >> christofer.d...@c-ware.de> > >> >> >> > wrote: > >> >> >> > > >> >> >> > > From my side I’m missing skinnable components. I really > >> >>loved > >> >> >> the way I > >> >> >> > could create applications with skinning. > >> >> >> > > >> >> >> > > >> >> >> -- > >> >> >> Carlos Rovira > >> >> >> Director General > >> >> >> M: +34 607 22 60 05 > >> >> >> http://www.codeoscopic.com > >> >> >> http://www.avant2.es > >> >> >> Este mensaje se dirige exclusivamente a su destinatario > >>y > >> >> puede > >> >> >> contener > >> >> >> información privilegiada o confidencial. Si ha recibido este > >> >> mensaje > >> >> >> por > >> >> >> error, le rogamos que nos lo comunique inmediatamente por > >>esta > >> >> misma > >> >> >> vía y > >> >> >> proceda a su destrucción. > >> >> >> De la vigente Ley Orgánica de Protección de Datos > >> >>(15/1999), > >> >> le > >> >> >> comunicamos > >> >> >> que sus datos forman parte de un fichero cuyo responsable es > >> >> >> CODEOSCOPIC > >> >> >> S.A. La finalidad de dicho tratamiento es facilitar la > >> >>prestación > >> >> del > >> >> >> servicio o información solicitados, teniendo usted derecho de > >> >> acceso, > >> >> >> rectificación, cancelación y oposición de sus datos > >> >>dirigiéndose a > >> >> >> nuestras > >> >> >> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la > >> >> >> documentación > >> >> >> necesaria. > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > >> > >> > > > > > >-- > > > >Carlos Rovira > >Director General > >M: +34 607 22 60 05 > >http://www.codeoscopic.com > >http://www.avant2.es > > > >Este mensaje se dirige exclusivamente a su destinatario y puede contener > >información privilegiada o confidencial. Si ha recibido este mensaje por > >error, le rogamos que nos lo comunique inmediatamente por esta misma vía y > >proceda a su destrucción. > > > >De la vigente Ley Orgánica de Protección de Datos (15/1999), le > >comunicamos > >que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC > >S.A. La finalidad de dicho tratamiento es facilitar la prestación del > >servicio o información solicitados, teniendo usted derecho de acceso, > >rectificación, cancelación y oposición de sus datos dirigiéndose a > >nuestras > >oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación > >necesaria. > >
