Hi Alex and Chris, I don't say we should *drop* support, but we should not think or plan things based on if that will work on a legacy IDE. Or in other words. We should not see anymore reference to FB when talking about FlexJS, since no body cares about it. That's all.
About Trevor's proposal, for me there's 3 important tasks now: AMF, SwizJS and Express Look'n Feel. I was in the need to end MDL to go to other task since don't like left things at a half. For example SwizJS could be a quick port, but I need to look at it. Hope other people that told as they had some kind of working AMF could donate what they had in order to start from a good place. For Design, I think is important to start figuring how we should prepare art to feed FlexJS component set. I have Sketch App open for several days but didn't have the time to look at it yet... 2017-02-03 18:29 GMT+01:00 Alex Harui <aha...@adobe.com>: > I don't claim to know the right answer so other folks should certainly > give their thoughts. IMO, if you want to encourage migration, you change > as few things as possible. > > We don't spend a ton of time on supporting the old IDEs. Not mucking with > the contents of the SWCs saves me time to work on other things. > Everything is a trade-off. If someone needs help on modules or AMF, > should I not help because I am spending time rewriting the compiler and > build scripts for packing more stuff into the SWCs? We've sort of dropped > the ball on Trevor's proposals for a new look. Should I spend time on > that or on this SWC packaging? > > -Alex > > On 2/3/17, 1:32 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: > > >Hi, > > > >(coming from the other thread and removing test and renaming thread) > > > >in all this conversation I have the sense that Alex is always looking to > >be > >compliant with old IDEs (I'm specially talking about FB) and don't > >understand the reason behind. I think this is making us far to get a > >solution for the real problem and even could be counterproductive. > > > >Let me try to explain my way of thinking: People using FB today are people > >using Flex SDK, no other people is using it (or at least should be > >residual) since is a product without maintenance for 6-7 years and stuck > >in > >the past. Many people coming to FlexJS already made a transition from FB > >to > >other IDEs (mainly IntelliJ IDEA) for many reasons, better refactoring, a > >great tech stack, maven support for Flex,... > > > >Now let's try to think in FlexJS...we are creating a technology from > >scratch. There's almost no legacy internals in what we are doing, but > >since > >there was so many great things in the old Flex philosophy we are importing > >it into FlexJS, but integrating with many new ones. Remember how many work > >we need in the past to get rid of SVN and adopt GIT? Thanks to god we did > >it. Remember how hard was to get Maven building? (only Chris knows the > >deep > >implications of this one). Those are only two examples of things with lot > >of impact in what we are today. All this things has bring us the > >possibilities that we have now. Talking now about me, without Git and > >Maven, I'll be not here, since it would be so hard to me think in older > >terms than that. > > > >So please, people working on Flex SDK, should has FB in mind, that's ok > >for > >me...is legacy sdk maintenance and many of them sure is still using FB, > >break that will be bad from a maintenance perspective. > > > >But all of us working on a modern technology that we call "FlexJS", should > >be running away from FB since instead doing something for us is penalizing > >us. Each time I read some explanation based on what would be in FB terms, > >or how should do it to make FB happy I think we are in the opposite > >direction. For me those kind of things are very dangerous since not doing > >the right change at a time can kill us before we reach the goal. > > > >If we need to change something that will need some IDE change, we should > >think in new IDEs and talk with their devs to support it. For commercial > >products, like IntelliJ, knowing their politic, I'll let it to them, and > >will concentrate in get as many costumers as we can with our open source > >tools (included OS IDEs), so we get the interest to support us. > > > >FlexJS is not Flex SDK, and even more, people doing Flex apps can't > >migrate > >to FlexJS with the same code base. People will need to start from scratch, > >but they could use their Flex codebase as a guide to implement their new > >codebase. So there are absolutely no points to stand with FB in 2017 for > >crafting a state of the art technology like FlexJS that tries to compite > >with the main ones out there. > > > >So we'll need to look forward always. Hope people here that is using FB > >for > >FlexJS could consider to move to other IDEs (specially open source), so > >this will make us truly open source in all means (only can think in flash > >player output dependency, but as a flavor, I think that's not bad and is > >optional) and get rid of any chains that some commercial product could > >impose to us. > > > >All of you working with old tooling, please consider this, since I think > >is > >very serious thing to take into account. > > > >Thanks! > > > > > >-- > >Carlos Rovira > >http://about.me/carlosrovira > > -- 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.
