Hi Alex, One very important thing I have to point out:
The hardware of the mobile devices are improving rapidly, way faster than the way of the desktop devices do. In China, there are already millions of Android phones with 2GB RAM + 4 Core CPU, under the price of $100, and I just bought a 2GB RAM + 8 Core CPU + 5 inches screen of Android phone for my mom last month, cost me ￥680 ($108). Chinese mobile hardware companies are rising, the price war is reaching its climax. My point is, the mobile applications made with the current Flex SDK are running very smooth in modern cheap mobile devices, and they will be running even smoother in every 3 months. So I believe the performance issue of Flex is not our primary concerns, no need to re-design the FlexJS architecture from the ground up, just base on the current Spark architecture and make improvements, that's fair enough in my opinion. I do agree the current Flex SDK is fat and old. For fat: I think we should get rid of the halo (mx) legacy stuff, and continue improving the Spark architecture to lose weight and gain performance. For old: I think we should focus more on the mobile supports of Spark framework, like adding more mobile components and skin themes (I know Om is working on one). DarkStone 2014-07-09 At 2014-07-09 01:10:03, "Alex Harui" <aha...@adobe.com> wrote: >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 >
