Re: [flexcoders] Re: Flex alternatives
Actually, I’m not just hanging in there, I’m still paid by Adobe to spend all of my time on Flex. My teammates are now folks like you who have spare cycles to contribute to the future of Flex. Apache Flex just “graduated” to being an official “top-level” project at Apache which means it will be around for as long as folks want it to. Adobe has no say in its future. Working in Apache has been interesting because these new contributors have lots of diverse knowledge and experience. The Apache Flex community is now investigating was to leverage a cross-compiler that can take in ActionScript and spit out JavaScript and allow you to use a Flex-like workflow to create RIAs that run without Flash. My thoughts on that topic and prototype is written up here: https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype On 12/21/12 12:50 PM, "John McCormack" wrote: On 21/12/2012 18:52, Alex Harui wrote: Re: [flexcoders] Re: Flex alternatives To not allow existing SWFs to play where they currently play would “break the web” and Adobe has no interest in doing that. The next generation of AS is supposed to be easy to migrate to if you just want to get your code to run, but there is a chance that to fully leverage the performance benefits of the new language you will have to learn some new constructs and refactor existing code. FlashBuilder will definitely be the IDE for developing applications for the new VM and new AS. That's all good to know. Looks like I am all set for a while, at least. I noticed you still hanging in there... http://incubator.apache.org/flex/team.html Thanks again. John -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [flexcoders] Re: Flex alternatives
On 21/12/2012 18:52, Alex Harui wrote: Re: [flexcoders] Re: Flex alternatives To not allow existing SWFs to play where they currently play would “break the web” and Adobe has no interest in doing that. The next generation of AS is supposed to be easy to migrate to if you just want to get your code to run, but there is a chance that to fully leverage the performance benefits of the new language you will have to learn some new constructs and refactor existing code. FlashBuilder will definitely be the IDE for developing applications for the new VM and new AS. That's all good to know. Looks like I am all set for a while, at least. I noticed you still hanging in there... http://incubator.apache.org/flex/team.html Thanks again. John
Re: [flexcoders] Re: Flex alternatives
To not allow existing SWFs to play where they currently play would “break the web” and Adobe has no interest in doing that. The next generation of AS is supposed to be easy to migrate to if you just want to get your code to run, but there is a chance that to fully leverage the performance benefits of the new language you will have to learn some new constructs and refactor existing code. FlashBuilder will definitely be the IDE for developing applications for the new VM and new AS. On 12/21/12 10:41 AM, "John McCormack" wrote: Brilliant. Thank you. I am pleased that existing SWF's will run in an embedded VM in the new player. Do you think the next-generation of ActionScript will be similar enough to make migration easy? and Is FlashBuilder likely to be the IDE that creates code for the new VM? John On 20/12/2012 05:50, Alex Harui wrote: Re: [flexcoders] Re: Flex alternatives Well, there are several pieces. ActionScript is a language. It is really only the dozen classes or so in the “top-level” in the ASDoc. String, int, RegEx, Array, Vector, a few functions like unescape, etc, plus a bunch of keywords and stuff like “var”, “class”, plus a grammar of how you put it all together. It hasn’t changed much in years, other than the addition of Vector. There are no plans to improve on its specification by adding things it is missing compared to other languages like Java such as method overloading, or mutiple inheritance. Instead, Adobe is tossing out the whole specification and developing a next-generation of ActionScript. It will have some of the same things you see in the current ActionScript, but there will be new keywords and grammar. The goal is to give up on backward compatibility in order to get significant speed improvements by making the language easier to execute at runtime. ActionScript currently only runs in a Virtual Machine embedded in the FlashPlayer or AIR. Both runtimes provide additional APIs that allow you to draw stuff and get network i/o, etc. The current APIs use ActionScript 3 syntax and are focused primarily on Sprites, Shapes and MovieClips on a display list. New features were added in every major release. Now, Adobe is working on embedding a new Virtual Machine that runs the next-generation ActionScript in the FlashPlayer and AIR. The focus is on gaming, and a new set of APIs that talk to a 3d rendering engine is being devloped in the next-generation ActionScript syntax. There will be no support for the old Sprites/Shapes/MovieClips and display list. However, the old virtual machine that runs ActionScript 3 will continue to be embedded in the FlashPlayer and AIR that run on tradtional desktops/laptops. I would not expect it to be co-existent on mobile versions of AIR because the new focus is on the captive runtime workflow where you pre-process your ActionScript code and the runtime libraries into a device-dependent executable. So, given all of that, you can continue to deliver ActionScript 3 content in AIR or FlashPlayer on desktops/laptops “forever”. And unless you have heard otherwise from the PDF team, they probably won’t eliminate support for Flash in PDF on desktop/laptops soon. I think Apache Flex exists because folks have found the Flex workflow easy and productive and also safe because it uses structured programming, and former Flex customers are now pitching in to continue to evolve Flex as much as we can given the constraints of the current environment. The problem for many is that, because Adobe is not evolving the ActionScript 3 language, VM and runtime APIs related to it, folks see it as a dead end and no longer want to develop apps on it. I can see their point, but there is a reason why DOS is still around on some custom handheld devices: it works, it is well known, and has a small footprint for a constrained environment. Flash/AIR and Flex on ActionScript3 continue to be excellent ways to create apps quickly, but it has been difficult to convince customers to stick with it. Anyway, so far, the most interest in Apache Flex seems to be around trying to leverage the Flex workflow to create apps that run on the HTML/CSS/JS stack (without Flash). It will have growing pains for sure, but to me, a question about CPU load is premature. There is 1000’s of people from all over the world working on improving the runtime environment for HTML/CSS/JS. They have made significant advances in the past several years and I don’t see a cap on it. So any pain points you experience now are likely to be solved in the near future. If you can continue to use Flash/AIR and let others suffer through the growing pains, consider yourself lucky. Otherwise, put on some pads and join the battle. On 12/19/12 9:29 AM, "John McCormack" wrote: Thank you again. Although ActionScript is not being developed for the FlashPlayer, is it possible that it may still be developed separately
Re: [flexcoders] Re: Flex alternatives
Brilliant. Thank you. I am pleased that existing SWF's will run in an embedded VM in the new player. Do you think the next-generation of ActionScript will be similar enough to make migration easy? and Is FlashBuilder likely to be the IDE that creates code for the new VM? John On 20/12/2012 05:50, Alex Harui wrote: Re: [flexcoders] Re: Flex alternatives Well, there are several pieces. ActionScript is a language. It is really only the dozen classes or so in the “top-level” in the ASDoc. String, int, RegEx, Array, Vector, a few functions like unescape, etc, plus a bunch of keywords and stuff like “var”, “class”, plus a grammar of how you put it all together. It hasn’t changed much in years, other than the addition of Vector. There are no plans to improve on its specification by adding things it is missing compared to other languages like Java such as method overloading, or mutiple inheritance. Instead, Adobe is tossing out the whole specification and developing a next-generation of ActionScript. It will have some of the same things you see in the current ActionScript, but there will be new keywords and grammar. The goal is to give up on backward compatibility in order to get significant speed improvements by making the language easier to execute at runtime. ActionScript currently only runs in a Virtual Machine embedded in the FlashPlayer or AIR. Both runtimes provide additional APIs that allow you to draw stuff and get network i/o, etc. The current APIs use ActionScript 3 syntax and are focused primarily on Sprites, Shapes and MovieClips on a display list. New features were added in every major release. Now, Adobe is working on embedding a new Virtual Machine that runs the next-generation ActionScript in the FlashPlayer and AIR. The focus is on gaming, and a new set of APIs that talk to a 3d rendering engine is being devloped in the next-generation ActionScript syntax. There will be no support for the old Sprites/Shapes/MovieClips and display list. However, the old virtual machine that runs ActionScript 3 will continue to be embedded in the FlashPlayer and AIR that run on tradtional desktops/laptops. I would not expect it to be co-existent on mobile versions of AIR because the new focus is on the captive runtime workflow where you pre-process your ActionScript code and the runtime libraries into a device-dependent executable. So, given all of that, you can continue to deliver ActionScript 3 content in AIR or FlashPlayer on desktops/laptops “forever”. And unless you have heard otherwise from the PDF team, they probably won’t eliminate support for Flash in PDF on desktop/laptops soon. I think Apache Flex exists because folks have found the Flex workflow easy and productive and also safe because it uses structured programming, and former Flex customers are now pitching in to continue to evolve Flex as much as we can given the constraints of the current environment. The problem for many is that, because Adobe is not evolving the ActionScript 3 language, VM and runtime APIs related to it, folks see it as a dead end and no longer want to develop apps on it. I can see their point, but there is a reason why DOS is still around on some custom handheld devices: it works, it is well known, and has a small footprint for a constrained environment. Flash/AIR and Flex on ActionScript3 continue to be excellent ways to create apps quickly, but it has been difficult to convince customers to stick with it. Anyway, so far, the most interest in Apache Flex seems to be around trying to leverage the Flex workflow to create apps that run on the HTML/CSS/JS stack (without Flash). It will have growing pains for sure, but to me, a question about CPU load is premature. There is 1000’s of people from all over the world working on improving the runtime environment for HTML/CSS/JS. They have made significant advances in the past several years and I don’t see a cap on it. So any pain points you experience now are likely to be solved in the near future. If you can continue to use Flash/AIR and let others suffer through the growing pains, consider yourself lucky. Otherwise, put on some pads and join the battle. On 12/19/12 9:29 AM, "John McCormack" wrote: Thank you again. Although ActionScript is not being developed for the FlashPlayer, is it possible that it may still be developed separately for use in AIR? I could deliver content through AIR instead of PDFs. My problem is that the FlashBuilder / Flash Professional workflow is such a seductive one, with that easy marriage of graphics and code, that I don't want to lose it. I have used C++ to produce graphical programs and the AS3 route is a godsend in comparison. One wonders "Is HMTL5 going to use any less CPU cycles than AS3, once it is doing similar work?" John On 18/12/2012 05:38, Alex Harui wrote: Re: [flexcoders
