Hi Erik, Thanks for the list. I think this is a valuable discussion. I'm going to respond out of order: hopefully the easiest answers first. Then at the end is more of my continually evolving thoughts on FlexJS that may be hard to capture from the slides.
First, keep in mind that one of the FlexJS goals is to support multiple component sets. Unlike current Flex's Spark or MX, the "basic" components isn't intended to be a one-size-fits-all component set. There are already the beginnings of component sets for JQUery and CreateJS and Cordova. Anyway, regarding #4 (MVC). I originally thought that there would be some advantage when cross-compiling to having folks separate business and controller logic from view. However, folks have complained about it, and I haven't really seen any advantages so far so in FlexJS 0.0.3 or 0.0.4 I'll probably remove the MVC requirement. Having the option of creating single-file apps is much more friendly. #5 (lack of direction). I call that "exploring", but yeah, I don't have a crystal ball to know where we need to end up. We are changing as we discover things and our users provide feedback. I think that's a good strategy and fits with the Apache Way. #1 (Migration Path). There is a migration path. I think it is very similar to what you envision for your approach. You simply switch from a current Flex SDK to a FlexJS SDK. You choose between replacing all mx and spark prefixes or replacing just the URI in the xmlns. Could we add an option to Falcon to override xmlns URIs? Sure, if that's what folks want. #2 (writing both AS and JS code). Actually, it is turning out that we are not writing both AS and JS as much as I thought we would. The FlexJSJX SWC and components like DataGrid and BarChart don't have any JS equivalents in the repo. The AS in that SWC is cross-compiled. It is looking like lots of components are "higher-level" and can be composed of widgets from the FlexJSUI SWC. But yes, we are writing enough AS so the SWF version is operational. This should provide several developer benefits: runtime verification of your code for highly dynamic applications, reduced testing if you can deploy SWFs on most browsers, a way to support older browsers. #3 (beads). There is no requirement that the application developers have to deal with a ton of beads. Only component developers that want to make general-purpose components may want to take advantage of beads. The "basic" components Peter and I (and hopefully others someday) are working on are trying to leverage beads in order to make sure there is clean separation of concerns in the framework code (vs 13,000 line base classes) so that some of these pieces can be re-used for other component sets. Then we're testing the waters to see whether application developers like beads or not. If not, we can always "bake-in" beads into higher-level components. But at least we'll know that if someone is desperately trying to shave off code it is possible. And from your other post about GCC optimization: Maybe download size doesn't matter and maybe GCC is so good you can add more code without any performance and size implications, but that sort of defies logic to me. It has been my experience that frameworks grow over time as you add features and fix bugs. And it has been my experience that folks will give up on frameworks for size and performance. That's why a significant number of mobile AIR apps do not use Flex and are written in bare-bones AS. I want Apache Flex to have a next-generation framework composed of pieces so fewer folks have to bail out. As we add more features to FlexJS, I hope the examples don't grow in size. IMO, they will for your VJS implementation because eventually, the VJS Button needs to wire in the code for tooltips even on mobile apps that will never use them. Or a heavy ResourceManager implementation for apps that only need to localize strings. There are 120+ public APIs on Spark Button most apps only use a small fraction. Another thing about FlexJS that has evolved over time is that I am thinking that the key advantage of FlexJS is simply in being the best way to glue JS together into an application. The "basic" components will be useful to many, but some folks have requirements to use certain JS frameworks. With the SWF version checking your code at runtime, with MXML giving you a schematic diagram, I hope to see component sets for Angular and other JS frameworks as well as the filling out of the Jquery and CreateJS sets, and possible different back-ends outputting to TypeScript and/or Dart. The beads create highly re-usable pieces for folks to build out these component sets and the result has little overhead compared to a manual port to that same JS framework. I believe we will always be compared to how fast and small a true JS application will be. So, the way I see it based on my understanding of the VJS approach you want to take is that you are just building another component set. You don't have to use beads although I hope you do find some sort of modular approach otherwise your UIComponent.js will be 13,000 lines of JS. My hope was that you would build your JS Spark and MX equivalents by compositing beads and helping create new beads that we can use in other component sets. Right now you want to hide your AS SWCs and switch to them under the covers, but I was thinking you could just make them public SWCs that are wrappers of the existing MX and Spark SWCs with some sort of metadata that works like the [Deprecated] metadata tag. I want to teach Falcon to warn folks about e4x usage and other things so we both want some sort of warning/errors for certain APIs. But I'm hoping to move the warning phase to the AS compile phase instead of waiting until you attempt to cross-compile. So, that's why I see way more similarities than differences. I'm glad you like the current SDK, but I think it has gotten too old, fat, and slow, so I am embarking on a next-generation. I say in one of my slides "if you have 10,000 lines of MXML and 100,000 lines of AS, without FlexJS you would have to port all of it, with FlexJS you will have to port less." It would be awesome to have some sort of component set where you have to port even less. I'm not clear you can get to zero porting because of things like weak references or if you do implement weak references, if there will be some cost to it that people will notice when comparing against a true JS app. But then folks can compare and choose. I think the basic components will result in smaller faster apps than one that has to support all of the ugly interdependencies in the current SDK. But if I'm wrong, that's ok. We will still have built lots of re-usable pieces to be used in the component sets for Jquery, Angular, etc. I don't know how folks will feel about making API changes to the current SDK to support cross-compilation. By making a wrapper component set, I think you won't need to make any changes. Folks just switch to your VJS component set and off they go. In summary, FlexJS totally supports a component set that is tries to emulate Spark and MX. It just isn't the component set I'm focused on. If we can find common ground on how to warn folks about missing APIs and move the warnings to the Falcon compiler, then I think we will truly be on the same team, just working on different component sets. -Alex On 7/8/14 1:29 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >OK, here goes - why I think the FlexJS concept can be improved upon (in no >particular order): > >1 - there is no migration path for existing Flex applications; this will >make enterprise users reluctant to accept the new framework, even though >during development FlexJS is limiting itself because it aims to please the >enterprise user (IE 'old' support) >2 - FlexJS requires a brand new framework on both the AS and JS side >(apart >from some stuff that may cross compile), effectively doubling the effort >to >bring it up to speed with other frameworks - including regular Flex >3 - Strands/Beads: it forces developers to know the insides of components, >adding a level of complexity and a steeper learning curve to the framework > I - by the time there are enough components/strands and beads to have >a >useful framework, the set of beads will be too big to easily work with >(e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData" or >"org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController >") > II - making beads work on all strands makes beads complicated; making >beads that don't work on all strands makes beads confusing for the >developer >4 - forced MVC: as an option it would be great, as a 'feature' not so >much: >it makes smaller projects unnecessarily complicated (e.g. all examples) >5 - lack of direction: FlexJS is a collection of proofs of concept, >created >top down to make nice looking demos that are then abandoned or superseded >by other proofs of concept or demos. > >I think we already have a pretty nice AS framework, the Flex SDK, which I >intend to offer as-is. Rather, I plan to make the 'export to JS' feature a >part of the regular Flex SDK. That way the user can open any Flex project, >run the export and get a fully functional, identical looking application >in >JS, or, worst case, a nice list from the compiler explaining which >components/properties don't (yet) work in JS and how to fix that. > >I'm interested to hear more about how you think this approach is related >to >FlexJS. If there is any synergy to be had, I'm all for it! > >EdB > > > >On Mon, Jul 7, 2014 at 6:27 PM, Alex Harui <aha...@adobe.com> wrote: > >> I'm not sure what you mean by "philosophical". I see more similarities >> than differences between FlexJS and your approach of trying to mimic >>more >> of the current SDK in JS. In fact, I still hope to convince you that >>what >> you want to do is within the FlexJS charter so we can work together >> instead appearing to work on separate efforts. And then what you are >> working on would also be weakened by whatever it is you want to say. If >> you have a killer argument why folks should not be trying to compile >>MXML >> and AS to JS, I think the whole community will be better served by >>finding >> out why now. >> >> -Alex >> >> On 7/7/14 8:40 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >> >> >There are no technical issues per se that would need addressing to keep >> >FlexJS healthy. I made sure of that. >> > >> >My argument is basically philosophical, and I think my ranting about >>it in >> >public would weaken FlexJS' case, so I won't. >> > >> >EdB >> > >> > >> > >> >On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui <aha...@adobe.com> wrote: >> > >> >> I think it has to be in public. This is open development. I'm >>hoping >> >>you >> >> will save me time by doing so. If we are doing something we >>shouldn't >> >>we >> >> should correct it now otherwise we'll waste time and energy doing >>more >> >> work in that direction only to find out that customers have the same >> >> feedback. >> >> >> >> Not that all of your feedback is guaranteed to be addressed: there's >> >> always a chance that what you don't like is philosophical rather than >> >> technical. That's why there are dozens of JS frameworks already and >>why >> >> you want to try a different approach. >> >> >> >> -Alex >> >> >> >> On 7/3/14 12:00 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >> >> >> >> >You want to hear that in public, or do you want to take this off >>list? >> >> > >> >> >EdB >> >> > >> >> > >> >> > >> >> > >> >> >On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <aha...@adobe.com> wrote: >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >I've been doing that as well for the last couple of years. I >>spent >> >> >>most of >> >> >> >my time getting FlexJS off the ground. But I don't agree with >>some >> >>of >> >> >>the >> >> >> >basic assumptions and choices that FlexJS has made. I said >>little or >> >> >> >nothing about it to give FlexJS a proper head start and to keep >>you >> >>and >> >> >> >Peter going. But now that I have re-evaluated what the project >> >>means to >> >> >> >me, >> >> >> >and what I would like to spend my time on when contributing, and >>I >> >> >>have to >> >> >> >give my take on Flex to JS a try. >> >> >> I'd love to hear your thoughts on what you don't agree with >>regarding >> >> >> FlexJS. >> >> >> >> >> >> -Alex >> >> >> >> >> >> >> >> > >> >> > >> >> >-- >> >> >Ix Multimedia Software >> >> > >> >> >Jan Luykenstraat 27 >> >> >3521 VB Utrecht >> >> > >> >> >T. 06-51952295 >> >> >I. www.ixsoftware.nl >> >> >> >> >> > >> > >> >-- >> >Ix Multimedia Software >> > >> >Jan Luykenstraat 27 >> >3521 VB Utrecht >> > >> >T. 06-51952295 >> >I. www.ixsoftware.nl >> >> > > >-- >Ix Multimedia Software > >Jan Luykenstraat 27 >3521 VB Utrecht > >T. 06-51952295 >I. www.ixsoftware.nl
