On 7/8/14 11:22 AM, "DarkStone" <darkst...@163.com> wrote: >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. Hi Darkstone, Thanks for that info. At one point I was told that battery life was going to limit device cpu performance growth rates. Is that no longer the case? > > >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. It is nice to know that more apps have a chance to work running on JS emulations of Flash-isms like e4x, weak references and xml notifications, but are you sure "all" apps will?
At one point in Flex's history, lots of apps worked as long as you had recent desktop hardware and a fast intranet. Then apps got bigger, folks tried to deploy those bigger apps on slower networks, and then a new wave of mobile devices came out that had performance constraints and Flex lost momentum. Could that happen again? Could there be some other frontier of new technology that will run JS in a constrained environment? I've already spent a lot of time trying to improve the current SDK. I've given up and am starting over, designing it for what we want it to do, instead of trying to emulate things we wish the JS platform had, because, at the end of the day, if you are running on top of emulations, folks can still point fingers at it and say that is isn't as good as "native". Every time there is additional CPU capability, eventually the OS and other apps starting eating away at it. We would never have deployed auto-updaters 10 years ago, but guess how many are now running on my Mac? More and more people have faster networks, but will your app be the one that works when the network is busy with other traffic? One of the reasons I "gave up" is because the SDK is very fragile and full of interconnected class dependencies. It is hard to separate things into smaller chunks. Folks have mentioned that as an inhibitor to contributing to the project. The components I'm working on and their beads are intended to make contributing easier. By having good separation, you can hopefully put together another bead and contribute it without fear of breaking something else. Yes, there will be a lot of beads but I'm hopeful that tools and documentation will help you manage. If folks can manage choosing things in a WalMart, hopefully they can choose beads. It will be interesting to see how Erik codes up the JS side. I would build it out of JS beads so there is that separation. But doing it for all of current Flex sounds like a considerable task. You can probably make good progress in the early going, but as you get closer to emulating all of current Flex you have to start reproducing those awful interconnected class dependencies and things may become fragile again (or fat and slow) But there's no way to know for sure until folks dive in. In my presentations I talk about doing an "80% Spark" component set that never does "everything" the current SDK can do. It simply doesn't implement the hard stuff, but that means that folks have to do more work during migration. Anyway, I don't think we have to decide on one approach now. I don't think anything Erik said weakens the potential of FlexJS. I still hope to convince him he is simply implementing one of many component sets. I think it will be good to offer folks different trade-offs on how much migration work vs options on using different JS frameworks under the covers or having a lighter weight JS download. But I do hope folks jump in an help on either effort. My biggest fear is that folks will sit on the sidelines hoping that someone can in fact produce the zero-migration JS framework that has little additional overhead. We've got a lot of work ahead of us, no matter what. > >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. That probably won't help Spark. It lives on top of a lot of mx stuff. >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). Any one interested in doing so is welcome to do so. That's the Apache Way. For now, I'll still be plugging away at making Flex the fastest way to create JS apps on any JS framework. -Alex
