Re: [flexcoders] Re: Flex alternatives
Alex I pointed someone to this on Flashcoders: http://www.mail-archive.com/flashcoders@chattyfig.figleaf.com/msg58770.html Do you have any new views on where Flash is heading? 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 j...@easypeasy.co.uk 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] Re: Flex alternatives Things get lost in translation, but one goal
Re: [flexcoders] Re: Flex alternatives
Looks like Mike Chambers is responding on that thread. He is a better person to ask than me. Even though I work for Adobe, my main focus is on Apache Flex. I barely keep up with the plans and goals of the other teams, even the Flash Runtime, because at this time, Apache Flex isn’t counting on any new awesome features from Flash itself. Apache Flex is looking at publishing Flex apps for HTML5. One approach is described here: https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype Now, IMO, Flex apps are quite different from other Flash swfs, especially those that are timeline driven, so Apache Flex isn’t going to be the solution for everyone. On 5/10/13 12:42 PM, John McCormack j...@easypeasy.co.uk wrote: Alex I pointed someone to this on Flashcoders: http://www.mail-archive.com/flashcoders@chattyfig.figleaf.com/msg58770.html Do you have any new views on where Flash is heading? 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 j...@easypeasy.co.uk wrote: Thank you again
Re: [flexcoders] Re: Flex alternatives
That is a very interesting diagram showing a way forward for Flex users. I have only used ActionScript Projects, rather than Flex, and have mainly been concerned not to lose a way to deliver my SWFs. I can see myself developing in JavaScript but not wishing to go back near the beginning with programming, and liking the way SWCs are used in my projects, I rather want things to stay as they are. On that subject, will later FlashPlayers have separate Virtual Machines for: (1) interpreting AIR (legacy) and (2) Browser (legacy) as well as (3) new code which is CPU dependent machine code? I understand that PDFs have their own built-in player and, according to Dave Merchant on Acrobat.com, we don't know what tje future of that might be. It would be a great shame to lose the PDF SWFs since if they worked properly with the PDF container it would be the best way to deliver high quality Text/Photo/Video/SWF combinations. At the moment the SWFs and PDF container don't thoroughly know about each other. Have I got that right about the PDF SWF player? Forgive my delayed posts but I have been teaching three days a week and busy winding up the apprentices assessments for the end of term. It's a great thing that Adobe have continued to keep you involved with the project. John On 21/12/2012 21:43, Alex Harui wrote: 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 j...@easypeasy.co.uk wrote:
Re: [flexcoders] Re: Flex alternatives
On desktops/laptops, I will be surprised if you lose the ability to view SWFs. I can’t imagine you are the only person to leverage SWFs in PDF and I would expect major backlash if that was to stop working. But the question for you is, in the future will your customers be using desktop/laptops? In the home, tablets are becoming all the rage. This is also true in some upper executive ranks. Tablets may not support SWF in PDF. There aren’t separate VMs for AIR vs Web. AIR is a delivery package of the same AS VM that you get with the FlashPlayer but with some extensions and the ability to hook into the OS, so I don’t quite know how to answer your questions. Both the current AS VM and AS Next VM use JIT to convert AS byte code to machine code at runtime. For mobile apps you have to pre-process the entire SWF and the AIR runtime into a single machine-dependent package. PDF is using a special player but I think that, even if that player does not stay in sync with Flash Player Next, it doesn’t matter to you. It should still run your content. So, I think the big question is what kind of devices your customers will be using. I think Adobe will support legacy content on desktop/laptops for a long time. -Alex On 12/23/12 10:43 AM, John McCormack j...@easypeasy.co.uk wrote: That is a very interesting diagram showing a way forward for Flex users. I have only used ActionScript Projects, rather than Flex, and have mainly been concerned not to lose a way to deliver my SWFs. I can see myself developing in JavaScript but not wishing to go back near the beginning with programming, and liking the way SWCs are used in my projects, I rather want things to stay as they are. On that subject, will later FlashPlayers have separate Virtual Machines for: (1) interpreting AIR (legacy) and (2) Browser (legacy) as well as (3) new code which is CPU dependent machine code? I understand that PDFs have their own built-in player and, according to Dave Merchant on Acrobat.com, we don't know what tje future of that might be. It would be a great shame to lose the PDF SWFs since if they worked properly with the PDF container it would be the best way to deliver high quality Text/Photo/Video/SWF combinations. At the moment the SWFs and PDF container don't thoroughly know about each other. Have I got that right about the PDF SWF player? Forgive my delayed posts but I have been teaching three days a week and busy winding up the apprentices assessments for the end of term. It's a great thing that Adobe have continued to keep you involved with the project. John On 21/12/2012 21:43, Alex Harui wrote: 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 j...@easypeasy.co.uk wrote: -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
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 j...@easypeasy.co.uk 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] 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 j...@easypeasy.co.uk 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 j...@easypeasy.co.uk wrote: Thank you again. Although ActionScript is not being developed for the FlashPlayer, is it possible
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
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 j...@easypeasy.co.uk 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
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] Re: Flex alternatives Things get lost in translation, but one goal of the parallel frameworks is to not leverage things that get lost in translation. Otherwise, since JS and AS are ECMA-based, the translation works pretty well. Keep in mind that, while Adobe is no longer investing in ActionScript 3 on the Flash Player, and not developing Flash Player for mobile devices, and AIR may not run on all mobile devices, where the FlashPlayer is today, it will likely be there “forever”. So, if alll of your users are using desktops/laptops that have browsers that have Flash, you can continue to use Flex and/or ActionScript 3 to build applications and they will likely run there not just in five years, but even after that. There is no time-bomb in the players that will go off and stop running. Even though ActionScript Next and FlashPlayer Next are not compatibile with ActionScript 3, the AS3 VM will ship in the FlashPlayers that Adobe ships in the future. There is the possibility that the browser vendors will stop supporting plugins, but I would imagine they will keep a compatibility-mode somehow. I think there is too much Flash content out there and to block it from existing desktops/laptops would “break the web” and I don’t expect the browser vendors or Adobe take such a risk. There would be too much negative press. That doesn’t mean that new computers with new OS’s may not support Flash (that’s what Apple did with IOS), and many home users may forgo traditional computers for tablets in the future, so keep that in mind as well. I don’t know the PDF market that well, but again, I would expect PDFs to continue to support Flash “forever” as well. At least for the readers on traditional desktops/laptops. On 12/17/12 10:48 AM, John McCormack j...@easypeasy.co.uk wrote: Thank you. That's interesting and very helpful. One does wonder if a separate translation tool would do the job faithfully, and so creates doubt. For someone that wants to use SWFs in PDFs to deliver educational content that is fully interactive, what workflow would you suggest using for the next three to five years? John On 17/12/2012 16:31, Alex Harui wrote: Re: [flexcoders] Re: Flex alternatives Adobe has no plans that I know of to get ActionScript to work with HTML5 in the same way that Google is proposing Dart as an alternative to JavaScript. The Apache Flex project is working on a compiler that will translate ActionScript to JavaScript. In addition, the link I posted proposes a component framework that would enable you to build or prototype your app in Flash using FlashBuilder and ActionScript and then run a separate tool outside of FlashBuilder to translate it to JavaScript where it will run and leverage HTML or HTML5 components. Alternatively, the same ActionScript to JavaScript compiler would let you write the script portions of your website as ActionScript using FlashBuilder and have separate HTML files, then use the same separate tool outside of FlashBuilder to translate the ActionScript to JavaScript. And maybe variations will be created that can output to various JS frameworks. At this time, there are no plans to change FlashBuilder to integrate the translation workflow. Adobe’s focus for FlashBuilder is on building ActionScript gaming and premium video projects that run on the Flash player. I suppose if the JS workflow became wildly popular and Adobe could see a revenue stream by supporting such a workflow things might change, but I wouldn’t count on it. There is a better chance that someone in Apache Flex will start creating plugins for Eclipse to support the workflow or one of the other tool vendors will provide an integrated workflow. The future of ActionScript 3 in Rich Internet Applications (as opposed to ActionScript “Next” as mentioned in the Flash roadmap) is actually being given more attention by Apache Flex than Adobe. If you want to continue to use ActionScript 3 to develop RIAs, I would encourage you to get involved
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 j...@easypeasy.co.uk 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] Re: Flex alternatives Things get lost in translation, but one goal of the parallel frameworks is to not leverage things that get lost in translation. Otherwise, since JS and AS are ECMA-based, the translation works pretty well. Keep in mind that, while Adobe is no longer investing in ActionScript 3 on the Flash Player, and not developing Flash Player for mobile devices, and AIR may not run on all
Re: [flexcoders] Re: Flex alternatives
On 17/12/2012 05:12, Alex Harui wrote: Re: [flexcoders] Re: Flex alternatives Adobe has spent the year donating the Flex SDK and Falcon compilers to the Apache Software Foundation. While Adobe has a small set of people contributing to Flex in Apache and a team that shipped Flash Builder 4.7 and is working on subsequent Flash Builder release, Adobe is not leading the development of Flex and has not been for a full year. The future of Flex is in the hands of the Apache Flex community. This document should have made Adobe’s plans clear: http://www.adobe.com/devnet/flex/whitepapers/roadmap.html I followed this link through to http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html Under Flash Player Next this says... and provide a foundation on which Flash can move forward over the next decade. Does this imply ActionScript working collaboratively with HTML5 or is it an alternative to HTML5? I am asking because I am hoping Flash Builder will continue to offer me a way forward (AS3+HTML5). John
Re: [flexcoders] Re: Flex alternatives
Adobe has no plans that I know of to get ActionScript to work with HTML5 in the same way that Google is proposing Dart as an alternative to JavaScript. The Apache Flex project is working on a compiler that will translate ActionScript to JavaScript. In addition, the link I posted proposes a component framework that would enable you to build or prototype your app in Flash using FlashBuilder and ActionScript and then run a separate tool outside of FlashBuilder to translate it to JavaScript where it will run and leverage HTML or HTML5 components. Alternatively, the same ActionScript to JavaScript compiler would let you write the script portions of your website as ActionScript using FlashBuilder and have separate HTML files, then use the same separate tool outside of FlashBuilder to translate the ActionScript to JavaScript. And maybe variations will be created that can output to various JS frameworks. At this time, there are no plans to change FlashBuilder to integrate the translation workflow. Adobe’s focus for FlashBuilder is on building ActionScript gaming and premium video projects that run on the Flash player. I suppose if the JS workflow became wildly popular and Adobe could see a revenue stream by supporting such a workflow things might change, but I wouldn’t count on it. There is a better chance that someone in Apache Flex will start creating plugins for Eclipse to support the workflow or one of the other tool vendors will provide an integrated workflow. The future of ActionScript 3 in Rich Internet Applications (as opposed to ActionScript “Next” as mentioned in the Flash roadmap) is actually being given more attention by Apache Flex than Adobe. If you want to continue to use ActionScript 3 to develop RIAs, I would encourage you to get involved with the Apache Flex project. On 12/17/12 2:16 AM, John McCormack j...@easypeasy.co.uk wrote: On 17/12/2012 05:12, Alex Harui wrote: Re: [flexcoders] Re: Flex alternatives Adobe has spent the year donating the Flex SDK and Falcon compilers to the Apache Software Foundation. While Adobe has a small set of people contributing to Flex in Apache and a team that shipped Flash Builder 4.7 and is working on subsequent Flash Builder release, Adobe is not leading the development of Flex and has not been for a full year. The future of Flex is in the hands of the Apache Flex community. This document should have made Adobe’s plans clear: http://www.adobe.com/devnet/flex/whitepapers/roadmap.html I followed this link through to http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html Under Flash Player Next this says... and provide a foundation on which Flash can move forward over the next decade. Does this imply ActionScript working collaboratively with HTML5 or is it an alternative to HTML5? I am asking because I am hoping Flash Builder will continue to offer me a way forward (AS3+HTML5). John -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [flexcoders] Re: Flex alternatives
Adobe’s focus for FlashBuilder is on building ActionScript gaming and premium video projects that run on the Flash player. I think many people assumed that the driver was legacy in-browser flex apps, plus AIR apps for mobile devices. That the older, legacy support had been farmed out to Apache, leaving the Flash Builder products as 'premium value-added design tools' fit consistently with what Adobe does elsewhere. The (baffling) removal of design view in 4.7 puts that impression to the sword, however. I'm not saying it's the wrong way to go - it's after all up to Adobe to choose where to invest their product development. It's in a sense good to know that Adobe has ceded all hope of competing with Google or Microsoft for HTML5 application building - that makes the choices a bit easier.
Re: [flexcoders] Re: Flex alternatives
Thank you. That's interesting and very helpful. One does wonder if a separate translation tool would do the job faithfully, and so creates doubt. For someone that wants to use SWFs in PDFs to deliver educational content that is fully interactive, what workflow would you suggest using for the next three to five years? John On 17/12/2012 16:31, Alex Harui wrote: Re: [flexcoders] Re: Flex alternatives Adobe has no plans that I know of to get ActionScript to work with HTML5 in the same way that Google is proposing Dart as an alternative to JavaScript. The Apache Flex project is working on a compiler that will translate ActionScript to JavaScript. In addition, the link I posted proposes a component framework that would enable you to build or prototype your app in Flash using FlashBuilder and ActionScript and then run a separate tool outside of FlashBuilder to translate it to JavaScript where it will run and leverage HTML or HTML5 components. Alternatively, the same ActionScript to JavaScript compiler would let you write the script portions of your website as ActionScript using FlashBuilder and have separate HTML files, then use the same separate tool outside of FlashBuilder to translate the ActionScript to JavaScript. And maybe variations will be created that can output to various JS frameworks. At this time, there are no plans to change FlashBuilder to integrate the translation workflow. Adobe’s focus for FlashBuilder is on building ActionScript gaming and premium video projects that run on the Flash player. I suppose if the JS workflow became wildly popular and Adobe could see a revenue stream by supporting such a workflow things might change, but I wouldn’t count on it. There is a better chance that someone in Apache Flex will start creating plugins for Eclipse to support the workflow or one of the other tool vendors will provide an integrated workflow. The future of ActionScript 3 in Rich Internet Applications (as opposed to ActionScript “Next” as mentioned in the Flash roadmap) is actually being given more attention by Apache Flex than Adobe. If you want to continue to use ActionScript 3 to develop RIAs, I would encourage you to get involved with the Apache Flex project. On 12/17/12 2:16 AM, John McCormack j...@easypeasy.co.uk wrote: On 17/12/2012 05:12, Alex Harui wrote: Re: [flexcoders] Re: Flex alternatives Adobe has spent the year donating the Flex SDK and Falcon compilers to the Apache Software Foundation. While Adobe has a small set of people contributing to Flex in Apache and a team that shipped Flash Builder 4.7 and is working on subsequent Flash Builder release, Adobe is not leading the development of Flex and has not been for a full year. The future of Flex is in the hands of the Apache Flex community. This document should have made Adobe’s plans clear: http://www.adobe.com/devnet/flex/whitepapers/roadmap.html I followed this link through to http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html Under Flash Player Next this says... and provide a foundation on which Flash can move forward over the next decade. Does this imply ActionScript working collaboratively with HTML5 or is it an alternative to HTML5? I am asking because I am hoping Flash Builder will continue to offer me a way forward (AS3+HTML5). John -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [flexcoders] Re: Flex alternatives
I’m not sure I understood. These roadmaps are nearly a year old. Folks still thought that Flash Builder was being developed for Rich Internet Apps? I guess we failed again to get the message out. DesignView, as was discussed several times on the Apache Flex mailing list, is tied to specific SDK versions and as such, it was not possible for Adobe to certify DV against Apache Flex versions. Adobe is investing in a whole new set of tools to address new workflows for HTML5 development. If you are near a large city, try to find out when the “Create The Web” tour comes to your city. On 12/17/12 8:54 AM, Nigel Magnay nigel.mag...@gmail.com wrote: Adobe’s focus for FlashBuilder is on building ActionScript gaming and premium video projects that run on the Flash player. I think many people assumed that the driver was legacy in-browser flex apps, plus AIR apps for mobile devices. That the older, legacy support had been farmed out to Apache, leaving the Flash Builder products as 'premium value-added design tools' fit consistently with what Adobe does elsewhere. The (baffling) removal of design view in 4.7 puts that impression to the sword, however. I'm not saying it's the wrong way to go - it's after all up to Adobe to choose where to invest their product development. It's in a sense good to know that Adobe has ceded all hope of competing with Google or Microsoft for HTML5 application building - that makes the choices a bit easier. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [flexcoders] Re: Flex alternatives
Things get lost in translation, but one goal of the parallel frameworks is to not leverage things that get lost in translation. Otherwise, since JS and AS are ECMA-based, the translation works pretty well. Keep in mind that, while Adobe is no longer investing in ActionScript 3 on the Flash Player, and not developing Flash Player for mobile devices, and AIR may not run on all mobile devices, where the FlashPlayer is today, it will likely be there “forever”. So, if alll of your users are using desktops/laptops that have browsers that have Flash, you can continue to use Flex and/or ActionScript 3 to build applications and they will likely run there not just in five years, but even after that. There is no time-bomb in the players that will go off and stop running. Even though ActionScript Next and FlashPlayer Next are not compatibile with ActionScript 3, the AS3 VM will ship in the FlashPlayers that Adobe ships in the future. There is the possibility that the browser vendors will stop supporting plugins, but I would imagine they will keep a compatibility-mode somehow. I think there is too much Flash content out there and to block it from existing desktops/laptops would “break the web” and I don’t expect the browser vendors or Adobe take such a risk. There would be too much negative press. That doesn’t mean that new computers with new OS’s may not support Flash (that’s what Apple did with IOS), and many home users may forgo traditional computers for tablets in the future, so keep that in mind as well. I don’t know the PDF market that well, but again, I would expect PDFs to continue to support Flash “forever” as well. At least for the readers on traditional desktops/laptops. On 12/17/12 10:48 AM, John McCormack j...@easypeasy.co.uk wrote: Thank you. That's interesting and very helpful. One does wonder if a separate translation tool would do the job faithfully, and so creates doubt. For someone that wants to use SWFs in PDFs to deliver educational content that is fully interactive, what workflow would you suggest using for the next three to five years? John On 17/12/2012 16:31, Alex Harui wrote: Re: [flexcoders] Re: Flex alternatives Adobe has no plans that I know of to get ActionScript to work with HTML5 in the same way that Google is proposing Dart as an alternative to JavaScript. The Apache Flex project is working on a compiler that will translate ActionScript to JavaScript. In addition, the link I posted proposes a component framework that would enable you to build or prototype your app in Flash using FlashBuilder and ActionScript and then run a separate tool outside of FlashBuilder to translate it to JavaScript where it will run and leverage HTML or HTML5 components. Alternatively, the same ActionScript to JavaScript compiler would let you write the script portions of your website as ActionScript using FlashBuilder and have separate HTML files, then use the same separate tool outside of FlashBuilder to translate the ActionScript to JavaScript. And maybe variations will be created that can output to various JS frameworks. At this time, there are no plans to change FlashBuilder to integrate the translation workflow. Adobe’s focus for FlashBuilder is on building ActionScript gaming and premium video projects that run on the Flash player. I suppose if the JS workflow became wildly popular and Adobe could see a revenue stream by supporting such a workflow things might change, but I wouldn’t count on it. There is a better chance that someone in Apache Flex will start creating plugins for Eclipse to support the workflow or one of the other tool vendors will provide an integrated workflow. The future of ActionScript 3 in Rich Internet Applications (as opposed to ActionScript “Next” as mentioned in the Flash roadmap) is actually being given more attention by Apache Flex than Adobe. If you want to continue to use ActionScript 3 to develop RIAs, I would encourage you to get involved with the Apache Flex project. On 12/17/12 2:16 AM, John McCormack j...@easypeasy.co.uk wrote: On 17/12/2012 05:12, Alex Harui wrote: Re: [flexcoders] Re: Flex alternatives Adobe has spent the year donating the Flex SDK and Falcon compilers to the Apache Software Foundation. While Adobe has a small set of people contributing to Flex in Apache and a team that shipped Flash Builder 4.7 and is working on subsequent Flash Builder release, Adobe is not leading the development of Flex and has not been for a full year. The future of Flex is in the hands of the Apache Flex community. This document should have made Adobe’s plans clear: http://www.adobe.com/devnet/flex/whitepapers/roadmap.html I followed this link through to http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html Under Flash Player Next this says... and provide a foundation on which Flash can move forward over the next decade. Does
Re: [flexcoders] Re: Flex alternatives
Hello I recently found an interesting product : http://cappuccino.org which seems to be technically a good alternative for flex (if needed). I have not investigated at all, just had a look. Of course, if even Adobe's flex is not reliable from the perennity point of view, there is no reason why capuccino can be more reliable. And you may invest in it and loose all, just like for flex as tablet browser plugin. I can only hope that one beautiful day, all browser will be 100% html5 compatible (will it be html6 at this time ?) and our developer's anxiety will be solved. (I don't beleive to that too, anyway.) On 16/12/12 01:01, Carlos Rovira wrote: Real alternative?... Nothing. There's only Flex ;) El sábado, 15 de diciembre de 2012, Sal escribió: __ --- In flexcoders@yahoogroups.com, Sal sal.celli@... wrote: hi, as i can sadly see from the message history bottom grid, many programmers are leaving flex. So this thread is to ask you all, if you have already found a valid alternative to flex for RIA development. After almost 1 year, it seems that Adobe itself gave us the answer releasing Adobe Flash Builder 4.7 without the design view. This is a straight message to all flex programmers telling us that Adobe has no more intention, and maybe neither a project group, to continue flex developing. So now, after this year of reflections and testing new products, what is the real alternative to flex? -- Sent from Gmail Mobile -- Riccardo Cohen +33 (0)6 09 83 64 49 Société Realty-Property.com 1 rue de la Monnaie 37000 Tours France http://www.appartement-maison.fr -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Alternative FAQ location: https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) * To change settings via email: flexcoders-dig...@yahoogroups.com flexcoders-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: flexcoders-unsubscr...@yahoogroups.com * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: Flex alternatives
Real alternative?... Nothing. There's only Flex ;)
El sábado, 15 de diciembre de 2012, Sal escribió:
**
--- In flexcoders@yahoogroups.com javascript:_e({}, 'cvml',
'flexcoders%40yahoogroups.com');, Sal sal.celli@... wrote:
hi,
as i can sadly see from the message history bottom grid, many
programmers are leaving flex.
So this thread is to ask you all, if you have already found a valid
alternative to flex for RIA development.
After almost 1 year, it seems that Adobe itself gave us the answer
releasing Adobe Flash Builder 4.7 without the design view. This is a
straight message to all flex programmers telling us that Adobe has no more
intention, and maybe neither a project group, to continue flex developing.
So now, after this year of reflections and testing new products, what is
the real alternative to flex?
--
Sent from Gmail Mobile
Re: [flexcoders] Re: Flex alternatives
Adobe has spent the year donating the Flex SDK and Falcon compilers to the Apache Software Foundation. While Adobe has a small set of people contributing to Flex in Apache and a team that shipped Flash Builder 4.7 and is working on subsequent Flash Builder release, Adobe is not leading the development of Flex and has not been for a full year. The future of Flex is in the hands of the Apache Flex community. This document should have made Adobe’s plans clear: http://www.adobe.com/devnet/flex/whitepapers/roadmap.html Meanwhile, there is plenty of activity in the Apache Flex community, including an effort to leverage ActionScript and MXML to write applications that can run without Flash, by translating ActionScript to JavaScript. If you like to use Flex, you may want to find a way to contribute to the Apache Flex project. The main page for the Apache Flex project is currently: http://incubator.apache.org/flex/ but will change if/when we become an official Apache top-level project. This document describes one approach to Flex without Flash. There are other approaches being investigated at this time. -Alex On 12/15/12 1:59 AM, Sal sal.ce...@yahoo.com wrote: --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Sal sal.celli@... wrote: hi, as i can sadly see from the message history bottom grid, many programmers are leaving flex. So this thread is to ask you all, if you have already found a valid alternative to flex for RIA development. After almost 1 year, it seems that Adobe itself gave us the answer releasing Adobe Flash Builder 4.7 without the design view. This is a straight message to all flex programmers telling us that Adobe has no more intention, and maybe neither a project group, to continue flex developing. So now, after this year of reflections and testing new products, what is the real alternative to flex? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [flexcoders] Re: Flex alternatives
Real alternative?... Nothing. There's only Flex ;)
El sábado, 15 de diciembre de 2012, Sal escribió:
**
--- In flexcoders@yahoogroups.com javascript:_e({}, 'cvml',
'flexcoders%40yahoogroups.com');, Sal sal.celli@... wrote:
hi,
as i can sadly see from the message history bottom grid, many
programmers are leaving flex.
So this thread is to ask you all, if you have already found a valid
alternative to flex for RIA development.
After almost 1 year, it seems that Adobe itself gave us the answer
releasing Adobe Flash Builder 4.7 without the design view. This is a
straight message to all flex programmers telling us that Adobe has no more
intention, and maybe neither a project group, to continue flex developing.
So now, after this year of reflections and testing new products, what is
the real alternative to flex?
--
Sent from Gmail Mobile
Re: [flexcoders] Re: Flex alternatives
I'll use what I've always used. Visual SlickEdit and Apache ant. And from what I've heard, FlashDevelop (http://www.flashdevelop.org), which is mature, robust, free and open source, is also pretty good. From: Ron G rgri...@sinclairoil.com To: flexcoders@yahoogroups.com Sent: Saturday, January 14, 2012 10:37 PM Subject: [flexcoders] Re: Flex alternatives Whoaaa! Just re-read that, and if there is any one statement in all this thread that readers should pay attention to, it is this statement from Alex (quoted below). If FlashBuilder is going to be geared toward gaming in Flash, I wonder which IDE Flex developers are planning on using for the future? From Alex statement, Adobe is retaining FlashBuilder and its roadmap will be geared toward being optimal for gaming development. Clearly then, the Flex community can't even modify it beyond 4.6 to accommodate future features of Flex. The Flex community is clearly going to have to develop their own IDE in addition to enhancing and maintaining the SDK. That is, if I read Alex Harui's statement correctly. Am I wrong? Or is Adobe going to both retool FlashBuilder for gaming, but continue to enhance it was well for future Flex SDK enhancements. Seems to me that goals of Adobe and the Apache Flex community might be at odds in FlashBuilder's roadmap. Flex community now either has to rely upon two proprietary products from Adobe to accommodate its own roadmap, or it must rely upon just one (Flashplayer) and decouple themselves from FlashBuilder by building their own IDE. Ron --- In flexcoders@yahoogroups.com, Alex Harui aharui@... wrote: FlashBuilder is being directed towards Gaming in Flash, Flex is being donated to the community. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Alternative FAQ location: https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: Flex alternatives
On 18 January 2012 02:05, Merrill, Jason jason.merr...@bankofamerica.comwrote: The problem isn’t even that large companies are in bed with Microsoft (that is a problem), but it’s that they have many many existing legacy enterprise apps that only work or have only been tested to work in IE, and those systems need to be supported and in place for years to come. It is also worth mentioning that if any of you have spent any time being a Windows desktop system administrator, you will appreciate the management features that only IE has in conjunction with group policy. Changing/enforcing proxy settings, certificate authorities, cache policies, homepages, look and feel settings and more can be done by just flicking a few settings in Group Policy. To do the same with Firefox, you'll have to modify a bunch of files on installation, and on every change, push out a new prefs.js file. Sounds easy enough, but try doing that when you have different settings that apply depending on the site the user is at, the groups they're a part of, etc. Unfortunately, none of the alternative browsers seem to pay much attention to the enterprise, so IE is pretty safe until there is a reasonable alternative. Jason Merrill Instructional Technology Architect II** *Bank of America* Global Learning ** ** ** ** ** ** ** ** ** ** ___ ** ** *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] *On Behalf Of *valdhor *Sent:* Monday, January 16, 2012 9:20 AM *To:* flexcoders@yahoogroups.com *Subject:* [flexcoders] Re: Flex alternatives ** ** Good luck on convincing IT departments in large corporations who are generally Microsoft shops. --- In flexcoders@yahoogroups.com, Guy Morton guy@... wrote: A thought on cross-browser hell… If every web developer in the world today decided to drop support for IE, everyone would go get Chrome or Firefox. This would be a win-win, as they would get a better browser, and we would get a better development environment. Who's with me? Guy On 16/01/2012, at 6:31 AM, Ron G wrote: Valdhor: You are right about that. That is precisely why we went with Flex originally (it insulated us from X-Browser issues). But, since we can't count on that lasting, and even Adobe is telling developers to plan on moving to HTML5, it seems like they're pushing us back into x-browser hell. I didn't want to go there, which is why we chose ZKoss. Yes, there is still going to be HTML/JS/CSS ultimately used, but it's how much. Even Flex SWFs are wrapped in HTML and JS when deployed. So, it's not that I'm against using any amount of HTML/JS; it's how little can I get away with to avoid these issues. Even with HTML5 libraries, such as the much touted jQuery, is, to a large degree, an insulator against x-browser issues. If you read the actual jQuery code, it deals with those issues for you. Now, ZK has a ZK Client JS library, which includes jQuery, that is designed to be a communicator mechanism between the client and the bulk of app logic that resides on the server. So, your normal editing and data manipulation that you might write in JS in a full blown HTML5 app is actually stored as Java on the server, and executed as needed per the EDA (event driven architecture). This type of JS is typically what breaks the page on different browsers and versions thereof. By limiting the amount of client-side JS, as does a jQuery type library, yes, you have some exposure to potential x-browser issues, but not as much as a HTML5 app that does everything on the client. And, when there are issues, they can be resolved in the ZK Client library as a patch/fix. So, now it seems to me that developers have several choices. Stick with Flex and you won't break the browser; you just won't be able to have your app viewed by millions on iOS products. If that seems like a better solution that minimal exposure to x-browser issues by using ZK or some other technology, well, that's certainly a choice each company has to make. Ron --- In flexcoders@yahoogroups.com, valdhor valdhorlists@ wrote: On a side note, I like the look of ZKoss. I don't know if there are cross browser issues with it seeing as we use older versions of browsers. One of the great features of Flex is we don't have to bother coding for compatibility between different browsers and versions. When IT deployed IE7, Flex applications worked just as they had before. Anyway, just my 2c from the enterprise perspective. -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and
Re: [flexcoders] Re: Flex alternatives
Out of interest... why does ZK marketing material never mention HTML5? They used to say direct RIA though I can't see that on the site anymore. I thought HTML5 was the new buzzword and that it would make sense to state it at least 3 times on every page? John 2012/1/17 Ron G rgri...@sinclairoil.com ** Hi Joaoak: You can make the coupling as tight or loose as you want. Each UI object can have a client side widget that is primarily the appearance, and a server side component that should contain the more complex logic. So, you can hide as much as want by placing it in the server side component as Java code, or keep in the client side widget as JS. In fact, since you indicate you are moving to HTML5, ZKoss actually might be a good choice, since it relies heavily on jQuery, which is considered a favorite HTML5 library. The difference is ZK lets you choose where client side logic is stored - as JS on the client or Java on the server. Another type of HTML5 approach won't offer that. Ron
Re: [flexcoders] Re: Flex alternatives
I have said this before, look at google closure. you code in javascript, annotate your types a compiler which gives you real errors, it has a component library with a well defined livecycle. it is what gmail, docs, goog+ is written in. it is really really good. On Tue, Jan 17, 2012 at 8:58 AM, John Fletcher fletch...@gmail.com wrote: ** Out of interest... why does ZK marketing material never mention HTML5? They used to say direct RIA though I can't see that on the site anymore. I thought HTML5 was the new buzzword and that it would make sense to state it at least 3 times on every page? John 2012/1/17 Ron G rgri...@sinclairoil.com ** Hi Joaoak: You can make the coupling as tight or loose as you want. Each UI object can have a client side widget that is primarily the appearance, and a server side component that should contain the more complex logic. So, you can hide as much as want by placing it in the server side component as Java code, or keep in the client side widget as JS. In fact, since you indicate you are moving to HTML5, ZKoss actually might be a good choice, since it relies heavily on jQuery, which is considered a favorite HTML5 library. The difference is ZK lets you choose where client side logic is stored - as JS on the client or Java on the server. Another type of HTML5 approach won't offer that. Ron -- j:pn \\no comment
RE: [flexcoders] Re: Flex alternatives
The problem isn't even that large companies are in bed with Microsoft (that is a problem), but it's that they have many many existing legacy enterprise apps that only work or have only been tested to work in IE, and those systems need to be supported and in place for years to come. Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of valdhor Sent: Monday, January 16, 2012 9:20 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Flex alternatives Good luck on convincing IT departments in large corporations who are generally Microsoft shops. --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, Guy Morton guy@... wrote: A thought on cross-browser hell... If every web developer in the world today decided to drop support for IE, everyone would go get Chrome or Firefox. This would be a win-win, as they would get a better browser, and we would get a better development environment. Who's with me? Guy On 16/01/2012, at 6:31 AM, Ron G wrote: Valdhor: You are right about that. That is precisely why we went with Flex originally (it insulated us from X-Browser issues). But, since we can't count on that lasting, and even Adobe is telling developers to plan on moving to HTML5, it seems like they're pushing us back into x-browser hell. I didn't want to go there, which is why we chose ZKoss. Yes, there is still going to be HTML/JS/CSS ultimately used, but it's how much. Even Flex SWFs are wrapped in HTML and JS when deployed. So, it's not that I'm against using any amount of HTML/JS; it's how little can I get away with to avoid these issues. Even with HTML5 libraries, such as the much touted jQuery, is, to a large degree, an insulator against x-browser issues. If you read the actual jQuery code, it deals with those issues for you. Now, ZK has a ZK Client JS library, which includes jQuery, that is designed to be a communicator mechanism between the client and the bulk of app logic that resides on the server. So, your normal editing and data manipulation that you might write in JS in a full blown HTML5 app is actually stored as Java on the server, and executed as needed per the EDA (event driven architecture). This type of JS is typically what breaks the page on different browsers and versions thereof. By limiting the amount of client-side JS, as does a jQuery type library, yes, you have some exposure to potential x-browser issues, but not as much as a HTML5 app that does everything on the client. And, when there are issues, they can be resolved in the ZK Client library as a patch/fix. So, now it seems to me that developers have several choices. Stick with Flex and you won't break the browser; you just won't be able to have your app viewed by millions on iOS products. If that seems like a better solution that minimal exposure to x-browser issues by using ZK or some other technology, well, that's certainly a choice each company has to make. Ron --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, valdhor valdhorlists@ wrote: On a side note, I like the look of ZKoss. I don't know if there are cross browser issues with it seeing as we use older versions of browsers. One of the great features of Flex is we don't have to bother coding for compatibility between different browsers and versions. When IT deployed IE7, Flex applications worked just as they had before. Anyway, just my 2c from the enterprise perspective. -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or
RE: [flexcoders] Re: Flex alternatives
Out of interest... why does ZK marketing material never mention HTML5? Speculating here, but probably because it doesn't use HTML 5 tags at all, - everything I saw on their site indicates it's an AJAX solution using an older version of HTML. Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of John Fletcher Sent: Tuesday, January 17, 2012 3:59 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: Flex alternatives Out of interest... why does ZK marketing material never mention HTML5? They used to say direct RIA though I can't see that on the site anymore. I thought HTML5 was the new buzzword and that it would make sense to state it at least 3 times on every page? John 2012/1/17 Ron G rgri...@sinclairoil.commailto:rgri...@sinclairoil.com Hi Joaoak: You can make the coupling as tight or loose as you want. Each UI object can have a client side widget that is primarily the appearance, and a server side component that should contain the more complex logic. So, you can hide as much as want by placing it in the server side component as Java code, or keep in the client side widget as JS. In fact, since you indicate you are moving to HTML5, ZKoss actually might be a good choice, since it relies heavily on jQuery, which is considered a favorite HTML5 library. The difference is ZK lets you choose where client side logic is stored - as JS on the client or Java on the server. Another type of HTML5 approach won't offer that. Ron -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
Re: [flexcoders] Re: Flex alternatives
It is not just that... I remember in the 90's there was IE and Netscape... then came Opera... and then Gekko/Firefox replaced Netscape... now, there is Chrome. There are so many browsers, because each one of then thinks that he is the best for some kind of need of the user. that means: each one of then implements things as pleases then. the beautiful of the FP is that you (theoretical) don´t need to concern about browsers. I work with flash since 99 and that is true until now, even with iPad discussion (air rules!). Tell me one technology that accomplished that for 10 years. regards! Rogério Gonzalez On Mon, Jan 16, 2012 at 12:20 PM, valdhor valdhorli...@embarqmail.comwrote: ** Good luck on convincing IT departments in large corporations who are generally Microsoft shops. --- In flexcoders@yahoogroups.com, Guy Morton guy@... wrote: A thought on cross-browser hell… If every web developer in the world today decided to drop support for IE, everyone would go get Chrome or Firefox. This would be a win-win, as they would get a better browser, and we would get a better development environment. Who's with me? Guy On 16/01/2012, at 6:31 AM, Ron G wrote: Valdhor: You are right about that. That is precisely why we went with Flex originally (it insulated us from X-Browser issues). But, since we can't count on that lasting, and even Adobe is telling developers to plan on moving to HTML5, it seems like they're pushing us back into x-browser hell. I didn't want to go there, which is why we chose ZKoss. Yes, there is still going to be HTML/JS/CSS ultimately used, but it's how much. Even Flex SWFs are wrapped in HTML and JS when deployed. So, it's not that I'm against using any amount of HTML/JS; it's how little can I get away with to avoid these issues. Even with HTML5 libraries, such as the much touted jQuery, is, to a large degree, an insulator against x-browser issues. If you read the actual jQuery code, it deals with those issues for you. Now, ZK has a ZK Client JS library, which includes jQuery, that is designed to be a communicator mechanism between the client and the bulk of app logic that resides on the server. So, your normal editing and data manipulation that you might write in JS in a full blown HTML5 app is actually stored as Java on the server, and executed as needed per the EDA (event driven architecture). This type of JS is typically what breaks the page on different browsers and versions thereof. By limiting the amount of client-side JS, as does a jQuery type library, yes, you have some exposure to potential x-browser issues, but not as much as a HTML5 app that does everything on the client. And, when there are issues, they can be resolved in the ZK Client library as a patch/fix. So, now it seems to me that developers have several choices. Stick with Flex and you won't break the browser; you just won't be able to have your app viewed by millions on iOS products. If that seems like a better solution that minimal exposure to x-browser issues by using ZK or some other technology, well, that's certainly a choice each company has to make. Ron --- In flexcoders@yahoogroups.com, valdhor valdhorlists@ wrote: On a side note, I like the look of ZKoss. I don't know if there are cross browser issues with it seeing as we use older versions of browsers. One of the great features of Flex is we don't have to bother coding for compatibility between different browsers and versions. When IT deployed IE7, Flex applications worked just as they had before. Anyway, just my 2c from the enterprise perspective.
Re: [flexcoders] Re: Flex alternatives
Hi I have been working with Flex and related technologies for last 7 -10 yrs. Recently, in my project I came across this technology http://eclipse.org/rap/ and it converts all your SWT Java components into Qooxdoo Javascript which finally runs on the browser. But here everything is Java. No action script. This is also browser independent and it also works well on mobile devices. It is becoming more and more popular nowdays. Everything displayed is widget and everything is on the server side behind the scenes it uses Ajax. Thanks Rajan From: Rogerio Gonzalez rogerio.gonza...@gmail.com To: flexcoders@yahoogroups.com Sent: Monday, January 16, 2012 11:04 AM Subject: Re: [flexcoders] Re: Flex alternatives It is not just that... I remember in the 90's there was IE and Netscape... then came Opera... and then Gekko/Firefox replaced Netscape... now, there is Chrome. There are so many browsers, because each one of then thinks that he is the best for some kind of need of the user. that means: each one of then implements things as pleases then. the beautiful of the FP is that you (theoretical) don´t need to concern about browsers. I work with flash since 99 and that is true until now, even with iPad discussion (air rules!). Tell me one technology that accomplished that for 10 years. regards! Rogério Gonzalez On Mon, Jan 16, 2012 at 12:20 PM, valdhor valdhorli...@embarqmail.com wrote: Good luck on convincing IT departments in large corporations who are generally Microsoft shops. --- In flexcoders@yahoogroups.com, Guy Morton guy@... wrote: A thought on cross-browser hell… If every web developer in the world today decided to drop support for IE, everyone would go get Chrome or Firefox. This would be a win-win, as they would get a better browser, and we would get a better development environment. Who's with me? Guy On 16/01/2012, at 6:31 AM, Ron G wrote: Valdhor: You are right about that. That is precisely why we went with Flex originally (it insulated us from X-Browser issues). But, since we can't count on that lasting, and even Adobe is telling developers to plan on moving to HTML5, it seems like they're pushing us back into x-browser hell. I didn't want to go there, which is why we chose ZKoss. Yes, there is still going to be HTML/JS/CSS ultimately used, but it's how much. Even Flex SWFs are wrapped in HTML and JS when deployed. So, it's not that I'm against using any amount of HTML/JS; it's how little can I get away with to avoid these issues. Even with HTML5 libraries, such as the much touted jQuery, is, to a large degree, an insulator against x-browser issues. If you read the actual jQuery code, it deals with those issues for you. Now, ZK has a ZK Client JS library, which includes jQuery, that is designed to be a communicator mechanism between the client and the bulk of app logic that resides on the server. So, your normal editing and data manipulation that you might write in JS in a full blown HTML5 app is actually stored as Java on the server, and executed as needed per the EDA (event driven architecture). This type of JS is typically what breaks the page on different browsers and versions thereof. By limiting the amount of client-side JS, as does a jQuery type library, yes, you have some exposure to potential x-browser issues, but not as much as a HTML5 app that does everything on the client. And, when there are issues, they can be resolved in the ZK Client library as a patch/fix. So, now it seems to me that developers have several choices. Stick with Flex and you won't break the browser; you just won't be able to have your app viewed by millions on iOS products. If that seems like a better solution that minimal exposure to x-browser issues by using ZK or some other technology, well, that's certainly a choice each company has to make. Ron --- In flexcoders@yahoogroups.com, valdhor valdhorlists@ wrote: On a side note, I like the look of ZKoss. I don't know if there are cross browser issues with it seeing as we use older versions of browsers. One of the great features of Flex is we don't have to bother coding for compatibility between different browsers and versions. When IT deployed IE7, Flex applications worked just as they had before. Anyway, just my 2c from the enterprise perspective.
Re: [flexcoders] Re: Flex alternatives
For me it's easy...there's no replacement for Flex...so... ;) 2012/1/15 Ron G rgri...@sinclairoil.com ** Michael, In my deliberations as to whether to stick with Flex or not, I weighed the likelihood of a successful open-source Flex community. And, I must say I am not as hopeful as you. For one, we already seen how people failed to find interest in Open Laszlo. Second, the best and brightest contributors of open source communities often do so with the motivation/hope that one day their open-source project will be bought out by a major company and the top contributors will be duly compensated at that time. Well, who is going to buy out open-source Flex when it has already proved a failure to be a profitable product line for a major company? Ron --- In flexcoders@yahoogroups.com, michael_regert@... wrote: But for now, I'm actually excited to have a greater role in the direction Flex takes for now, and welcome any challenges making it Open Source may bring. Michael J. Regert -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 35 57 77 CODEOSCOPIC S.A. http://www.codeoscopic.com Avd. del General Perón, 32 Planta 10, Puertas P-Q 28020 Madrid
RE: [flexcoders] Re: Flex alternatives
The fact that there is this discussion at all tells me something is up. I've been burned by Adobe before as an Authorware user, and again now as a Flash / Flex user, and that's twice too many times for this little black duck. From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Mark Sent: 13 January 2012 13:26 To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Flex alternatives I work on a very large flex application that runs within a web page. Most of the functionality is built within the flex application, but it does communicate to the server to get data and post results. I'm in the process of moving all this to a combination of restful web services written in C# and Javascript on the client. For the client my plan is to use Dojo. Moving a lot of code to javascript scares me since it's not as structured as actionscript or other compiled languages, but I really see no other choice. The main point I want to make is that I love Flex. I love how you can write an application to embed in a web page, then take that same code, put an air wrapper around it and have it run on mulitple OSes as a stand alone application with very little work, and believe it or not, it actually works everywhere. The unfortunate thing is that for web based applications, if you want to support the IPAD, and your application needs to be embeded in a webpage, you're screwed. I work for a major publisher that supplies colleges and high schools web based course management systems and we are getting a lot of pressure to have our stuff work on IPADs. For this reason alone, we need to convert to HTML5 and javascript. The main reason I'm not considering the ZKoss is that my group is a windows group. We have windows servers and are heavily invested in .Net. I admit the ZKoss stuff looks nice, but for us, it's really not an option. IMO, the bottom line is that the IPAD is killing Flex, and unless you're just writing stand alone applications, you should stop using Flex. It's a shame it's come to this though. --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, Ron G rgrimes@... wrote: I have used Flex since 2006, and I have used ZKoss within the last year. I can tell you that the learning curve of ZKoss is much lower than Flex, and the development cycle is even faster. In your spare time, if you're curious like me and like to check out different technologies, give it a whirl, just so you'll have a good comparison. I think you'll be impressed - even if you don't ever use it for a project. I think you'll agree that HTML/CSS/JS is not a faster development environment, regardless of IDE. Would truly love to hear your assessment of it at some point. Don't get me wrong. I was always a big fan of Flex and touted its virtues whenever I could over the past several years. So, I have nothing against it. I'll be using it for years as I maintain existing projects written in Flex. But, with respect, I think you do a disservice to continue to tell developers to use Flex. You are only telling them to build a backlog of projects that will have to be converted one day. But, I understand you work for Adobe and can't very well say exactly what you think developers should do. Ron --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, Alex Harui aharui@ wrote: Flex and FlashBuilder are not part of Adobe's HTML strategy per-se. FlashBuilder is being directed towards Gaming in Flash, Flex is being donated to the community. It is the community that has lots of investment in the Flex/AS/FP stack that are looking reworking the Flex paradigm to output to the HTML/CSS/JS stack. Meanwhile Adobe is not only updating Dreamweaver (see the PhoneGap features added in 5.5) but also looking at new tools for new development methodologies. While classic Java has been around for a while, and HTML/CSS/JS will likely meet your 15 year requirement, the question remains whether you will be willing to use more efficient and powerful development frameworks and methodologies over those years. If you don't, you might lose competitive advantage as your competition gets their products finished better or faster, but if you do, you run the risk of choosing a new set of tools that turns out not to have lasting power. Tough call, no right answer, the choice is yours. It looks like the Apache Flex folks are going to try to provide one of those new sets of tools by making it possible to use the Flex paradigm for the HTML stack. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not
RE: [flexcoders] Re: Flex alternatives
You bring up some good points. I have been on a few calls between our company and with Adobe on this exact subject right after the announcements were made. We grilled them with questions, and though I won't fully disclose many of their answers here, our development teams were confident enough to stick with Adobe Flex. We realize that long-term, technologies shift. I started out as a C++ developer doing low-level SCSI. Now doing UIs in Flex. In 5 years will I be doing HTML 5, ZK, Silverlight, some other new technology? Who knows. But for now, I'm actually excited to have a greater role in the direction Flex takes for now, and welcome any challenges making it Open Source may bring. The product we developed using Adobe Flex was ranked as one of the top 15 products for 2011 by CRN. Didn't see any HTML 5 apps there. I think this says something about where Flex is, and it still holds some ground. The technology decision should be based on your projects, your long-term direction, and your talent pool. I'd recommend not jumping ship, just to jump ship. You never know where that ship may sail! Michael J. Regert From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Ron G Sent: Thursday, January 12, 2012 11:39 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Flex alternatives Hi James, I certainly respect the decision of those who are sticking with Flex, but I would suggest that developers do so with the recognition that they may be developing with a technology that isn't going to be around that long. I could write at length about this, but, in a nutshell, here's why. On the one hand, you have an open-source project that is geared toward enterprise application development, but it is completely dependent on a proprietary runtime. That runtime is manufactured by a company who has stated its future is digital media and digital marketing, and that it believes the future of enterprise web application development is HTML5. It then begs the question, How long will they bloat their Flashplayer to support an open-source Flex community's enterprise web application development goals and wishes? To accommodate the Flex community, Adobe gets nothing in return for its expenditure of time and money in designing, developing, testing the features the Flex community requires now and in the future. It also means that, by supporting Flex in their runtime, the Flashplayer has an unnecessarily larger footprint than would otherwise be required. So, ask yourself if you truly believe Flex will be a supported product by Adobe in 5-10 years from now. I highly doubt it. On the other hand, I think if a developer uses Flash Pro to develop digital media for their applications, they can probably count on that being around indefinitely. But, not Flex. Ron --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, James Ong yanlilei64@...mailto:yanlilei64@... wrote: Using ZK and Java is great. I'm still sticking to Flex for developing desktop applications and gaming. Of course, many will still using it for animations, there is no such thing as abandon, some developers are just over use Flash and end up hurting user experience than necessary. When it comes to web application, I stick to PHP but will definitely use Flex for mobile, desktop and components within the web browser. On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@...mailto:michael_regert@... wrote: ** Staying with Flex. Not looking elsewhere. ** ** *Michael* ** ** *From:* flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com [mailto:flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com] *On Behalf Of *Ron G *Sent:* Wednesday, January 11, 2012 8:15 PM *To:* flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com *Subject:* [flexcoders] Re: Flex alternatives ** ** Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a Java shop, on the server side, it seemed logical to use a Java based framework on the client-side. The thing I really like about ZK or ZKoss is that it has equivalent components to Flex. In fact, it actually has more components than Flex. It implements an approach that I really like of separating the UI into appearance and behavior - much like the Spark components of Flex. Well, not exactly, but sort of. :) Here's what I mean. For each UI object, it has a client side (widget) and server side (component). I won't go into further detail, but it gives you a nice separation of concerns that you can avail yourself of. This feature also greatly insulates the rendered pages from x-browser compatibility issues. Check it out for yourself at their site (zkoss.org). Ron --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, Sal sal.celli@ wrote: hi, as i can sadly see from the message history bottom
Re: [flexcoders] Re: Flex alternatives
I very much enjoyed my time as a Flex developer, and wish the Apache project well. Some of the criticism of Adobe seems misplaced. The writing was on the wall when the most popular mobile platform (iOS) didn't allow browser plug-ins. I'm not painting Apple as a villain either. It's just business. Though Phonegap looks nice, AIR still seems pretty compelling for cross-platform mobile *app* development. It will be interesting to watch the level of investment in AIR (it is, after all, used by Adobe apps). Now that browser plug-ins are unpopular/impossible, and captive runtime is the way to go, it seems to me Adobe could open-source the AIR runtime, while still retaining control of the Flash Player browser plug-in. Wouldn't that further energize the Apache Flex project? The prospect of a cross-platform mobile app framework with the side-benefit of running on still-ubiquitous-on-desktop Flash Player? Aside: Remember OpenLaszlo? On Fri, Jan 13, 2012 at 6:28 AM, michael_reg...@dell.com wrote: ** You bring up some good points. I have been on a few calls between our company and with Adobe on this exact subject right after the announcements were made. We grilled them with questions, and though I won’t fully disclose many of their answers here, our development teams were confident enough to stick with Adobe Flex. We realize that long-term, technologies shift. I started out as a C++ developer doing low-level SCSI. Now doing UIs in Flex. In 5 years will I be doing HTML 5, ZK, Silverlight, some other new technology? Who knows. But for now, I’m actually excited to have a greater role in the direction Flex takes for now, and welcome any challenges making it Open Source may bring. ** ** The product we developed using Adobe Flex was ranked as one of the top 15 products for 2011 by CRN. Didn’t see any HTML 5 apps there. I think this says something about where Flex is, and it still holds some ground. The technology decision should be based on your projects, your long-term direction, and your talent pool. I’d recommend not jumping ship, just to jump ship. You never know where that ship may sail! ** ** *Michael J. Regert*** ** ** *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] *On Behalf Of *Ron G *Sent:* Thursday, January 12, 2012 11:39 AM *To:* flexcoders@yahoogroups.com *Subject:* [flexcoders] Re: Flex alternatives ** ** Hi James, I certainly respect the decision of those who are sticking with Flex, but I would suggest that developers do so with the recognition that they may be developing with a technology that isn't going to be around that long. I could write at length about this, but, in a nutshell, here's why. On the one hand, you have an open-source project that is geared toward enterprise application development, but it is completely dependent on a proprietary runtime. That runtime is manufactured by a company who has stated its future is digital media and digital marketing, and that it believes the future of enterprise web application development is HTML5. It then begs the question, How long will they bloat their Flashplayer to support an open-source Flex community's enterprise web application development goals and wishes? To accommodate the Flex community, Adobe gets nothing in return for its expenditure of time and money in designing, developing, testing the features the Flex community requires now and in the future. It also means that, by supporting Flex in their runtime, the Flashplayer has an unnecessarily larger footprint than would otherwise be required. So, ask yourself if you truly believe Flex will be a supported product by Adobe in 5-10 years from now. I highly doubt it. On the other hand, I think if a developer uses Flash Pro to develop digital media for their applications, they can probably count on that being around indefinitely. But, not Flex. Ron --- In flexcoders@yahoogroups.com, James Ong yanlilei64@... wrote: Using ZK and Java is great. I'm still sticking to Flex for developing desktop applications and gaming. Of course, many will still using it for animations, there is no such thing as abandon, some developers are just over use Flash and end up hurting user experience than necessary. When it comes to web application, I stick to PHP but will definitely use Flex for mobile, desktop and components within the web browser. On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@... wrote: ** Staying with Flex. Not looking elsewhere. ** ** *Michael* ** ** *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] *On Behalf Of *Ron G *Sent:* Wednesday, January 11, 2012 8:15 PM *To:* flexcoders@yahoogroups.com *Subject:* [flexcoders] Re: Flex alternatives ** ** Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a Java shop, on the
Re: [flexcoders] Re: Flex alternatives
I meant to say prospect of a cross-platform mobile app framework that doesn't depend on a proprietary runtime On Fri, Jan 13, 2012 at 9:17 AM, Richard Rodseth rrods...@gmail.com wrote: I very much enjoyed my time as a Flex developer, and wish the Apache project well. Some of the criticism of Adobe seems misplaced. The writing was on the wall when the most popular mobile platform (iOS) didn't allow browser plug-ins. I'm not painting Apple as a villain either. It's just business. Though Phonegap looks nice, AIR still seems pretty compelling for cross-platform mobile *app* development. It will be interesting to watch the level of investment in AIR (it is, after all, used by Adobe apps). Now that browser plug-ins are unpopular/impossible, and captive runtime is the way to go, it seems to me Adobe could open-source the AIR runtime, while still retaining control of the Flash Player browser plug-in. Wouldn't that further energize the Apache Flex project? The prospect of a cross-platform mobile app framework with the side-benefit of running on still-ubiquitous-on-desktop Flash Player? Aside: Remember OpenLaszlo? On Fri, Jan 13, 2012 at 6:28 AM, michael_reg...@dell.com wrote: ** You bring up some good points. I have been on a few calls between our company and with Adobe on this exact subject right after the announcements were made. We grilled them with questions, and though I won’t fully disclose many of their answers here, our development teams were confident enough to stick with Adobe Flex. We realize that long-term, technologies shift. I started out as a C++ developer doing low-level SCSI. Now doing UIs in Flex. In 5 years will I be doing HTML 5, ZK, Silverlight, some other new technology? Who knows. But for now, I’m actually excited to have a greater role in the direction Flex takes for now, and welcome any challenges making it Open Source may bring. ** ** The product we developed using Adobe Flex was ranked as one of the top 15 products for 2011 by CRN. Didn’t see any HTML 5 apps there. I think this says something about where Flex is, and it still holds some ground. The technology decision should be based on your projects, your long-term direction, and your talent pool. I’d recommend not jumping ship, just to jump ship. You never know where that ship may sail! ** ** *Michael J. Regert*** ** ** *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] *On Behalf Of *Ron G *Sent:* Thursday, January 12, 2012 11:39 AM *To:* flexcoders@yahoogroups.com *Subject:* [flexcoders] Re: Flex alternatives ** ** Hi James, I certainly respect the decision of those who are sticking with Flex, but I would suggest that developers do so with the recognition that they may be developing with a technology that isn't going to be around that long. I could write at length about this, but, in a nutshell, here's why. On the one hand, you have an open-source project that is geared toward enterprise application development, but it is completely dependent on a proprietary runtime. That runtime is manufactured by a company who has stated its future is digital media and digital marketing, and that it believes the future of enterprise web application development is HTML5. It then begs the question, How long will they bloat their Flashplayer to support an open-source Flex community's enterprise web application development goals and wishes? To accommodate the Flex community, Adobe gets nothing in return for its expenditure of time and money in designing, developing, testing the features the Flex community requires now and in the future. It also means that, by supporting Flex in their runtime, the Flashplayer has an unnecessarily larger footprint than would otherwise be required. So, ask yourself if you truly believe Flex will be a supported product by Adobe in 5-10 years from now. I highly doubt it. On the other hand, I think if a developer uses Flash Pro to develop digital media for their applications, they can probably count on that being around indefinitely. But, not Flex. Ron --- In flexcoders@yahoogroups.com, James Ong yanlilei64@... wrote: Using ZK and Java is great. I'm still sticking to Flex for developing desktop applications and gaming. Of course, many will still using it for animations, there is no such thing as abandon, some developers are just over use Flash and end up hurting user experience than necessary. When it comes to web application, I stick to PHP but will definitely use Flex for mobile, desktop and components within the web browser. On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@... wrote: ** Staying with Flex. Not looking elsewhere. ** ** *Michael* ** ** *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] *On Behalf Of *Ron G *Sent:* Wednesday, January 11, 2012 8:15 PM *To:*
Re: [flexcoders] Re: Flex alternatives
Open-sourcing AIR would be an awesome thing, but the Apache project has to assume it won’t happen. On 1/13/12 9:19 AM, Richard Rodseth rrods...@gmail.com wrote: I meant to say prospect of a cross-platform mobile app framework that doesn't depend on a proprietary runtime On Fri, Jan 13, 2012 at 9:17 AM, Richard Rodseth rrods...@gmail.com wrote: I very much enjoyed my time as a Flex developer, and wish the Apache project well. Some of the criticism of Adobe seems misplaced. The writing was on the wall when the most popular mobile platform (iOS) didn't allow browser plug-ins. I'm not painting Apple as a villain either. It's just business. Though Phonegap looks nice, AIR still seems pretty compelling for cross-platform mobile *app* development. It will be interesting to watch the level of investment in AIR (it is, after all, used by Adobe apps). Now that browser plug-ins are unpopular/impossible, and captive runtime is the way to go, it seems to me Adobe could open-source the AIR runtime, while still retaining control of the Flash Player browser plug-in. Wouldn't that further energize the Apache Flex project? The prospect of a cross-platform mobile app framework with the side-benefit of running on still-ubiquitous-on-desktop Flash Player? Aside: Remember OpenLaszlo? On Fri, Jan 13, 2012 at 6:28 AM, michael_reg...@dell.com wrote: You bring up some good points. I have been on a few calls between our company and with Adobe on this exact subject right after the announcements were made. We grilled them with questions, and though I won’t fully disclose many of their answers here, our development teams were confident enough to stick with Adobe Flex. We realize that long-term, technologies shift. I started out as a C++ developer doing low-level SCSI. Now doing UIs in Flex. In 5 years will I be doing HTML 5, ZK, Silverlight, some other new technology? Who knows. But for now, I’m actually excited to have a greater role in the direction Flex takes for now, and welcome any challenges making it Open Source may bring. The product we developed using Adobe Flex was ranked as one of the top 15 products for 2011 by CRN. Didn’t see any HTML 5 apps there. I think this says something about where Flex is, and it still holds some ground. The technology decision should be based on your projects, your long-term direction, and your talent pool. I’d recommend not jumping ship, just to jump ship. You never know where that ship may sail! Michael J. Regert From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Ron G Sent: Thursday, January 12, 2012 11:39 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Flex alternatives Hi James, I certainly respect the decision of those who are sticking with Flex, but I would suggest that developers do so with the recognition that they may be developing with a technology that isn't going to be around that long. I could write at length about this, but, in a nutshell, here's why. On the one hand, you have an open-source project that is geared toward enterprise application development, but it is completely dependent on a proprietary runtime. That runtime is manufactured by a company who has stated its future is digital media and digital marketing, and that it believes the future of enterprise web application development is HTML5. It then begs the question, How long will they bloat their Flashplayer to support an open-source Flex community's enterprise web application development goals and wishes? To accommodate the Flex community, Adobe gets nothing in return for its expenditure of time and money in designing, developing, testing the features the Flex community requires now and in the future. It also means that, by supporting Flex in their runtime, the Flashplayer has an unnecessarily larger footprint than would otherwise be required. So, ask yourself if you truly believe Flex will be a supported product by Adobe in 5-10 years from now. I highly doubt it. On the other hand, I think if a developer uses Flash Pro to develop digital media for their applications, they can probably count on that being around indefinitely. But, not Flex. Ron --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , James Ong yanlilei64@... wrote: Using ZK and Java is great. I'm still sticking to Flex for developing desktop applications and gaming. Of course, many will still using it for animations, there is no such thing as abandon, some developers are just over use Flash and end up hurting user experience than necessary. When it comes to web application, I stick to PHP but will definitely use Flex for mobile, desktop and components within the web browser. On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@... wrote: ** Staying with Flex. Not looking elsewhere. ** ** *Michael* ** ** *From:* flexcoders@yahoogroups.com
Re: [flexcoders] Re: Flex alternatives
Apache FlashKit ! On Fri, Jan 13, 2012 at 11:17 AM, Alex Harui aha...@adobe.com wrote: ** Open-sourcing AIR would be an awesome thing, but the Apache project has to assume it won’t happen. On 1/13/12 9:19 AM, Richard Rodseth rrods...@gmail.com wrote: I meant to say prospect of a cross-platform mobile app framework that doesn't depend on a proprietary runtime On Fri, Jan 13, 2012 at 9:17 AM, Richard Rodseth rrods...@gmail.com wrote: I very much enjoyed my time as a Flex developer, and wish the Apache project well. Some of the criticism of Adobe seems misplaced. The writing was on the wall when the most popular mobile platform (iOS) didn't allow browser plug-ins. I'm not painting Apple as a villain either. It's just business. Though Phonegap looks nice, AIR still seems pretty compelling for cross-platform mobile *app* development. It will be interesting to watch the level of investment in AIR (it is, after all, used by Adobe apps). Now that browser plug-ins are unpopular/impossible, and captive runtime is the way to go, it seems to me Adobe could open-source the AIR runtime, while still retaining control of the Flash Player browser plug-in. Wouldn't that further energize the Apache Flex project? The prospect of a cross-platform mobile app framework with the side-benefit of running on still-ubiquitous-on-desktop Flash Player? Aside: Remember OpenLaszlo? On Fri, Jan 13, 2012 at 6:28 AM, michael_reg...@dell.com wrote: You bring up some good points. I have been on a few calls between our company and with Adobe on this exact subject right after the announcements were made. We grilled them with questions, and though I won’t fully disclose many of their answers here, our development teams were confident enough to stick with Adobe Flex. We realize that long-term, technologies shift. I started out as a C++ developer doing low-level SCSI. Now doing UIs in Flex. In 5 years will I be doing HTML 5, ZK, Silverlight, some other new technology? Who knows. But for now, I’m actually excited to have a greater role in the direction Flex takes for now, and welcome any challenges making it Open Source may bring. The product we developed using Adobe Flex was ranked as one of the top 15 products for 2011 by CRN. Didn’t see any HTML 5 apps there. I think this says something about where Flex is, and it still holds some ground. The technology decision should be based on your projects, your long-term direction, and your talent pool. I’d recommend not jumping ship, just to jump ship. You never know where that ship may sail! *Michael J. Regert * *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.comflexcoders@yahoogroups.com] *On Behalf Of *Ron G *Sent:* Thursday, January 12, 2012 11:39 AM *To:* flexcoders@yahoogroups.com *Subject:* [flexcoders] Re: Flex alternatives Hi James, I certainly respect the decision of those who are sticking with Flex, but I would suggest that developers do so with the recognition that they may be developing with a technology that isn't going to be around that long. I could write at length about this, but, in a nutshell, here's why. On the one hand, you have an open-source project that is geared toward enterprise application development, but it is completely dependent on a proprietary runtime. That runtime is manufactured by a company who has stated its future is digital media and digital marketing, and that it believes the future of enterprise web application development is HTML5. It then begs the question, How long will they bloat their Flashplayer to support an open-source Flex community's enterprise web application development goals and wishes? To accommodate the Flex community, Adobe gets nothing in return for its expenditure of time and money in designing, developing, testing the features the Flex community requires now and in the future. It also means that, by supporting Flex in their runtime, the Flashplayer has an unnecessarily larger footprint than would otherwise be required. So, ask yourself if you truly believe Flex will be a supported product by Adobe in 5-10 years from now. I highly doubt it. On the other hand, I think if a developer uses Flash Pro to develop digital media for their applications, they can probably count on that being around indefinitely. But, not Flex. Ron --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.comflexcoders%40yahoogroups.com , James Ong yanlilei64@... wrote: Using ZK and Java is great. I'm still sticking to Flex for developing desktop applications and gaming. Of course, many will still using it for animations, there is no such thing as abandon, some developers are just over use Flash and end up hurting user experience than necessary. When it comes to web application, I stick to PHP but will definitely use Flex for mobile, desktop and components within the web browser. On Thu,
Re: [flexcoders] Re: Flex alternatives
Using ZK and Java is great. I'm still sticking to Flex for developing desktop applications and gaming. Of course, many will still using it for animations, there is no such thing as abandon, some developers are just over use Flash and end up hurting user experience than necessary. When it comes to web application, I stick to PHP but will definitely use Flex for mobile, desktop and components within the web browser. On Thu, Jan 12, 2012 at 10:16 AM, michael_reg...@dell.com wrote: ** Staying with Flex. Not looking elsewhere. ** ** *Michael* ** ** *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] *On Behalf Of *Ron G *Sent:* Wednesday, January 11, 2012 8:15 PM *To:* flexcoders@yahoogroups.com *Subject:* [flexcoders] Re: Flex alternatives ** ** Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a Java shop, on the server side, it seemed logical to use a Java based framework on the client-side. The thing I really like about ZK or ZKoss is that it has equivalent components to Flex. In fact, it actually has more components than Flex. It implements an approach that I really like of separating the UI into appearance and behavior - much like the Spark components of Flex. Well, not exactly, but sort of. :) Here's what I mean. For each UI object, it has a client side (widget) and server side (component). I won't go into further detail, but it gives you a nice separation of concerns that you can avail yourself of. This feature also greatly insulates the rendered pages from x-browser compatibility issues. Check it out for yourself at their site (zkoss.org). Ron --- In flexcoders@yahoogroups.com, Sal sal.celli@... wrote: hi, as i can sadly see from the message history bottom grid, many programmers are leaving flex. So this thread is to ask you all, if you have already found a valid alternative to flex for RIA development.
RE: [flexcoders] Re: Flex alternatives
Unless I'm not understanding it right, ZKoss looks like it requires some web server configuration in order to run. Flex doesn't, which is nice for people like me who work in server environments they can't control. But it looks like awesome tech! Am I right about it needing server side configuration? Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Ron G Sent: Wednesday, January 11, 2012 9:15 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Flex alternatives Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a Java shop, on the server side, it seemed logical to use a Java based framework on the client-side. The thing I really like about ZK or ZKoss is that it has equivalent components to Flex. In fact, it actually has more components than Flex. It implements an approach that I really like of separating the UI into appearance and behavior - much like the Spark components of Flex. Well, not exactly, but sort of. :) Here's what I mean. For each UI object, it has a client side (widget) and server side (component). I won't go into further detail, but it gives you a nice separation of concerns that you can avail yourself of. This feature also greatly insulates the rendered pages from x-browser compatibility issues. Check it out for yourself at their site (zkoss.org). Ron --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, Sal sal.celli@... wrote: hi, as i can sadly see from the message history bottom grid, many programmers are leaving flex. So this thread is to ask you all, if you have already found a valid alternative to flex for RIA development. -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
Re: [flexcoders] Re: Flex alternatives
Flex is an awesome product.Period. Atleast until version 3. Then they bloated it. The new spark component makes it easy to do the skinning but it costs a big deal in download time. I am not sure there is anything flex specific in the Flash Player Runtime. Flex is totally written with AS3 and the flash player runs AS3. The path I would suggest the Apache Flex guys to go is towards creating a Flex to JS/HTML5 Cross compiler. This would be something that would help them quite a lot. Write code with AS3 and output to JS. There are quite a lot of Flex apps out there ( especially in the corprate world ). Given that adobe has given up on Flex ( which means they wont have any premium support ) these guys will be looking for a solution that can work as good as their current applications. Ofcourse, the big players ( especially in the financial industry ) are going to be slow to move. They wont change something just because Adobe wont support it quite in the future. They would be looking to change. This is the point where the Apache Flex community needs to catch up on. Flex is currently the biggest load on a ship called Flash Player Runtime. There is a significantly large hole in this ship. That would not have been the case, if Adobe had not shot itself in the foot, but that is a different topic altogether. Now, if one of the biggest load happens to unload quite fast onto another boat the rest of the smaller entities on the ship can jump on. If not, the other smaller entities wont die. They will just become a fish :) . Everything evolves, the question is how do you want to evolve! On Thu, Jan 12, 2012 at 5:38 PM, Ron G rgri...@sinclairoil.com wrote: ** Hi James, I certainly respect the decision of those who are sticking with Flex, but I would suggest that developers do so with the recognition that they may be developing with a technology that isn't going to be around that long. I could write at length about this, but, in a nutshell, here's why. On the one hand, you have an open-source project that is geared toward enterprise application development, but it is completely dependent on a proprietary runtime. That runtime is manufactured by a company who has stated its future is digital media and digital marketing, and that it believes the future of enterprise web application development is HTML5. It then begs the question, How long will they bloat their Flashplayer to support an open-source Flex community's enterprise web application development goals and wishes? To accommodate the Flex community, Adobe gets nothing in return for its expenditure of time and money in designing, developing, testing the features the Flex community requires now and in the future. It also means that, by supporting Flex in their runtime, the Flashplayer has an unnecessarily larger footprint than would otherwise be required. So, ask yourself if you truly believe Flex will be a supported product by Adobe in 5-10 years from now. I highly doubt it. On the other hand, I think if a developer uses Flash Pro to develop digital media for their applications, they can probably count on that being around indefinitely. But, not Flex. Ron --- In flexcoders@yahoogroups.com, James Ong yanlilei64@... wrote: Using ZK and Java is great. I'm still sticking to Flex for developing desktop applications and gaming. Of course, many will still using it for animations, there is no such thing as abandon, some developers are just over use Flash and end up hurting user experience than necessary. When it comes to web application, I stick to PHP but will definitely use Flex for mobile, desktop and components within the web browser. On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@... wrote: ** Staying with Flex. Not looking elsewhere. ** ** *Michael* ** ** *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] *On Behalf Of *Ron G *Sent:* Wednesday, January 11, 2012 8:15 PM *To:* flexcoders@yahoogroups.com *Subject:* [flexcoders] Re: Flex alternatives ** ** Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a Java shop, on the server side, it seemed logical to use a Java based framework on the client-side. The thing I really like about ZK or ZKoss is that it has equivalent components to Flex. In fact, it actually has more components than Flex. It implements an approach that I really like of separating the UI into appearance and behavior - much like the Spark components of Flex. Well, not exactly, but sort of. :) Here's what I mean. For each UI object, it has a client side (widget) and server side (component). I won't go into further detail, but it gives you a nice separation of concerns that you can avail yourself of. This feature also greatly insulates the rendered pages from x-browser compatibility issues. Check it out for
RE: [flexcoders] Re: Flex alternatives
Yep, and with no ability to access or make mods to the server like that, it would be a no-go for us unfortunately. Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Ron G Sent: Thursday, January 12, 2012 12:13 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Flex alternatives Hi Jason, The only configuration is that I had to drop several of their jar files into the endorsed directory of Tomcat. Ron --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, Merrill, Jason jason.merrill@... wrote: Unless I'm not understanding it right, ZKoss looks like it requires some web server configuration in order to run. Flex doesn't, which is nice for people like me who work in server environments they can't control. But it looks like awesome tech! Am I right about it needing server side configuration? Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ From: flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com [mailto:flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com] On Behalf Of Ron G Sent: Wednesday, January 11, 2012 9:15 PM To: flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com Subject: [flexcoders] Re: Flex alternatives Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a Java shop, on the server side, it seemed logical to use a Java based framework on the client-side. The thing I really like about ZK or ZKoss is that it has equivalent components to Flex. In fact, it actually has more components than Flex. It implements an approach that I really like of separating the UI into appearance and behavior - much like the Spark components of Flex. Well, not exactly, but sort of. :) Here's what I mean. For each UI object, it has a client side (widget) and server side (component). I won't go into further detail, but it gives you a nice separation of concerns that you can avail yourself of. This feature also greatly insulates the rendered pages from x-browser compatibility issues. Check it out for yourself at their site (zkoss.org). Ron --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.commailto:flexcoders%40yahoogroups.com, Sal sal.celli@ wrote: hi, as i can sadly see from the message history bottom grid, many programmers are leaving flex. So this thread is to ask you all, if you have already found a valid alternative to flex for RIA development. -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or
RE: [flexcoders] Re: Flex alternatives
I think it will be interesting to see how many people actually show up at MAX this year. Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of ganaraj p r Sent: Thursday, January 12, 2012 1:15 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: Flex alternatives Flex is an awesome product.Period. Atleast until version 3. Then they bloated it. The new spark component makes it easy to do the skinning but it costs a big deal in download time. I am not sure there is anything flex specific in the Flash Player Runtime. Flex is totally written with AS3 and the flash player runs AS3. The path I would suggest the Apache Flex guys to go is towards creating a Flex to JS/HTML5 Cross compiler. This would be something that would help them quite a lot. Write code with AS3 and output to JS. There are quite a lot of Flex apps out there ( especially in the corprate world ). Given that adobe has given up on Flex ( which means they wont have any premium support ) these guys will be looking for a solution that can work as good as their current applications. Ofcourse, the big players ( especially in the financial industry ) are going to be slow to move. They wont change something just because Adobe wont support it quite in the future. They would be looking to change. This is the point where the Apache Flex community needs to catch up on. Flex is currently the biggest load on a ship called Flash Player Runtime. There is a significantly large hole in this ship. That would not have been the case, if Adobe had not shot itself in the foot, but that is a different topic altogether. Now, if one of the biggest load happens to unload quite fast onto another boat the rest of the smaller entities on the ship can jump on. If not, the other smaller entities wont die. They will just become a fish :) . Everything evolves, the question is how do you want to evolve! On Thu, Jan 12, 2012 at 5:38 PM, Ron G rgri...@sinclairoil.commailto:rgri...@sinclairoil.com wrote: Hi James, I certainly respect the decision of those who are sticking with Flex, but I would suggest that developers do so with the recognition that they may be developing with a technology that isn't going to be around that long. I could write at length about this, but, in a nutshell, here's why. On the one hand, you have an open-source project that is geared toward enterprise application development, but it is completely dependent on a proprietary runtime. That runtime is manufactured by a company who has stated its future is digital media and digital marketing, and that it believes the future of enterprise web application development is HTML5. It then begs the question, How long will they bloat their Flashplayer to support an open-source Flex community's enterprise web application development goals and wishes? To accommodate the Flex community, Adobe gets nothing in return for its expenditure of time and money in designing, developing, testing the features the Flex community requires now and in the future. It also means that, by supporting Flex in their runtime, the Flashplayer has an unnecessarily larger footprint than would otherwise be required. So, ask yourself if you truly believe Flex will be a supported product by Adobe in 5-10 years from now. I highly doubt it. On the other hand, I think if a developer uses Flash Pro to develop digital media for their applications, they can probably count on that being around indefinitely. But, not Flex. Ron --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, James Ong yanlilei64@... wrote: Using ZK and Java is great. I'm still sticking to Flex for developing desktop applications and gaming. Of course, many will still using it for animations, there is no such thing as abandon, some developers are just over use Flash and end up hurting user experience than necessary. When it comes to web application, I stick to PHP but will definitely use Flex for mobile, desktop and components within the web browser. On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@... wrote: ** Staying with Flex. Not looking elsewhere. ** ** *Michael* ** ** *From:* flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com [mailto:flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com] *On Behalf Of *Ron G *Sent:* Wednesday, January 11, 2012 8:15 PM *To:* flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com *Subject:* [flexcoders] Re: Flex alternatives ** ** Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a Java shop, on the server side, it seemed logical to use a Java based framework on the client-side. The thing I really like about ZK or ZKoss is that it has equivalent components to Flex. In fact, it actually has
Re: [flexcoders] Re: Flex alternatives
I can’t think of anything the FlashPlayer could unload from its footprint that wouldn’t just “break the web” for lots of other non-Flex swfs. Adobe has no interest in “breaking the web” and thus it will continue to invest in not doing so. I’m not sure of your definition of “supported product”. If you mean that you can get a support contract from Adobe, we are still deciding on whether to offer extended support. If you mean that Adobe will be developing and selling Flex, it has already stopped. Adobe will be continuing to release FlashBuilder, but all significant Flex work will be done in the Apache project. So, how long will Flex be around? Probably forever, since once you get in the enterprise infrastructure, it is hard to get out. There are still COBOL programs running in the world. How long will Flex be a choice as a development technology? It could be forever as well, it will depend on how you define what Flex is. If you say that it is ActionScript and the Flash Platform, then when HTML5 delivers on its promise of power and productivity, the need for Flash in the browser will likely diminish, but AIR will still remain an attractive way to develop cross-platform desktop apps. But under the definition that Flex is a development paradigm (declarative markup for UI, some script mixed in that supports OOP), Flex may transform to become a popular paradigm for creating HTML5 apps. On 1/12/12 9:38 AM, Ron G rgri...@sinclairoil.com wrote: Hi James, I certainly respect the decision of those who are sticking with Flex, but I would suggest that developers do so with the recognition that they may be developing with a technology that isn't going to be around that long. I could write at length about this, but, in a nutshell, here's why. On the one hand, you have an open-source project that is geared toward enterprise application development, but it is completely dependent on a proprietary runtime. That runtime is manufactured by a company who has stated its future is digital media and digital marketing, and that it believes the future of enterprise web application development is HTML5. It then begs the question, How long will they bloat their Flashplayer to support an open-source Flex community's enterprise web application development goals and wishes? To accommodate the Flex community, Adobe gets nothing in return for its expenditure of time and money in designing, developing, testing the features the Flex community requires now and in the future. It also means that, by supporting Flex in their runtime, the Flashplayer has an unnecessarily larger footprint than would otherwise be required. So, ask yourself if you truly believe Flex will be a supported product by Adobe in 5-10 years from now. I highly doubt it. On the other hand, I think if a developer uses Flash Pro to develop digital media for their applications, they can probably count on that being around indefinitely. But, not Flex. Ron --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , James Ong yanlilei64@... wrote: Using ZK and Java is great. I'm still sticking to Flex for developing desktop applications and gaming. Of course, many will still using it for animations, there is no such thing as abandon, some developers are just over use Flash and end up hurting user experience than necessary. When it comes to web application, I stick to PHP but will definitely use Flex for mobile, desktop and components within the web browser. On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@... wrote: ** Staying with Flex. Not looking elsewhere. ** ** *Michael* ** ** *From:* flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com [mailto:flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com ] *On Behalf Of *Ron G *Sent:* Wednesday, January 11, 2012 8:15 PM *To:* flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com *Subject:* [flexcoders] Re: Flex alternatives ** ** Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a Java shop, on the server side, it seemed logical to use a Java based framework on the client-side. The thing I really like about ZK or ZKoss is that it has equivalent components to Flex. In fact, it actually has more components than Flex. It implements an approach that I really like of separating the UI into appearance and behavior - much like the Spark components of Flex. Well, not exactly, but sort of. :) Here's what I mean. For each UI object, it has a client side (widget) and server side (component). I won't go into further detail, but it gives you a nice separation of concerns that you can avail yourself of. This feature also greatly insulates the rendered pages from x-browser compatibility issues. Check it out for yourself at their site (zkoss.org). Ron --- In flexcoders@yahoogroups.com
Re: [flexcoders] Re: Flex alternatives
I’ve never used COBOL, but I haven’t heard anyone say they really liked working in with it. That’s not true for Flex so even if it gets marginalized because it always remains locked to ActionScript and FlashPlayer, it may not be the subject of cursing. I’m not in disagreement that in the long term, the advantages of Flex/ActionScript/FlashPlayer will be diminished by advances in the HTML/CSS/JS stack. That’s why Adobe has made a major strategic shift to become the tooling leader in the HTML stack. But that doesn’t mean that you should stop using Flex/ActionScript/FlashPlayer right now. Many folks who work with HTML/CSS/JS, even using the many libraries and development methodologies available for it, still feel like the Flex paradigm is superior. Apparently, even Google agrees because they are trying to create their own version of that paradigm with DART. While translated code is never as good, the productivity advantages of a better paradigm have been pretty much proven to be worth it, otherwise, Flex wouldn’t have been that successful either since MXML isn’t as efficient as pure ActionScript, and Google wouldn’t have invested so much in writing their website logic in Java and/or Google Closure and/or DART. There is general support in the Apache Flex project for exploring ways of using the Flex paradigm to create HTML5 apps. Those working on the project are motivated to future-proof their investment in Flex. I don’t see any technical issue blocking us from translating the paradigm to HTML5, and I invite all those who like the Flex paradigm to participate. But at the same time, there is lots of work to be done, lots of solutions to be built, and lots of money to be made on the Flex/AS/FP stack while we wait for the HTML5 stack to deliver on its promises. On 1/12/12 3:37 PM, Ron G rgri...@sinclairoil.com wrote: I think you make my point for me by comparing the future of Flex to COBOL. Yes, it's still around, but we all wish it wasn't and curse it everytime we have to deal with it. As you say, it is hard to get out. So, yes, I still have projects written in Flex that will undoubtedly continue to run for years to come. But, it's hardly a justification for continuing to develop in COBOL...er, uh, I mean Flex. As you say, the need for Flash in the browser will likely diminish. Again, you help make my point against using Flex or FlashBuilder. I find it amusing that some have suggested that Flex and FlashBuilder could be retooled to render HTML5 pages. It confounds me as to why I would want to write MXML and AS3 so it can be translated to HTML and JS. If that is the desired end product, then I suggest developers just develop in HTML and JS to begin with. Translated code is never as efficient as code specifically written in that sytax. Ron --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Alex Harui aharui@... wrote: So, how long will Flex be around? Probably forever, since once you get in the enterprise infrastructure, it is hard to get out. There are still COBOL programs running in the world. How long will Flex be a choice as a development technology? It could be forever as well, it will depend on how you define what Flex is. If you say that it is ActionScript and the Flash Platform, then when HTML5 delivers on its promise of power and productivity, the need for Flash in the browser will likely diminish, but AIR will still remain an attractive way to develop cross-platform desktop apps. But under the definition that Flex is a development paradigm (declarative markup for UI, some script mixed in that supports OOP), Flex may transform to become a popular paradigm for creating HTML5 apps. On 1/12/12 9:38 AM, Ron G rgrimes@... wrote: Hi James, I certainly respect the decision of those who are sticking with Flex, but I would suggest that developers do so with the recognition that they may be developing with a technology that isn't going to be around that long. I could write at length about this, but, in a nutshell, here's why. On the one hand, you have an open-source project that is geared toward enterprise application development, but it is completely dependent on a proprietary runtime. That runtime is manufactured by a company who has stated its future is digital media and digital marketing, and that it believes the future of enterprise web application development is HTML5. It then begs the question, How long will they bloat their Flashplayer to support an open-source Flex community's enterprise web application development goals and wishes? To accommodate the Flex community, Adobe gets nothing in return for its expenditure of time and money in designing, developing, testing the features the Flex community requires now and in the future. It also means that, by supporting Flex in their runtime, the Flashplayer has an unnecessarily larger footprint than would otherwise be
Re: [flexcoders] Re: Flex alternatives
Well Ron, I don't agree with you. There is a difference between a reality and our own perception. I have seen a huge demand for flex based solution in Education (hmh, piersons) Finance (j p morgon, boa) Healthcare (hospira) Entertainment (directv) Ecommerce ( eBay ) and the list goes on and on... If as of today companies decide to change the strategy and port all the existing flex based application into HTML 5, then it would take around 5 years to do so as HTML 5 is still not mature for web and desktop. Check the percent of browser which support HTML 5. N what about desktop apps that are so beautifully created using adobe air. My personal thought is that some people are trying to take advantage of this bad rumours and advertising the dead tools which were existed for years. Please be patience and watch the change. N Stop spreading the rumours. Regards Rishi Tandon Software Development Adviser Flex Sent from my iPad On 13-Jan-2012, at 7:40 AM, Ron G rgri...@sinclairoil.com wrote: So, I think we have a similar vision for where things are going with respect to Adobe supporting HTML5 for the enterprise. But, I fail to see why Flex and FlashBuilder would have any part of that. Why not just fall back to your excellent product, Dreamweaver, and enhance it as the IDE for building HTML5 style web applications? No translation is then required. I too like the FlashBuilder/Flex paradigm for development. But, it seems to me that, sooner or later, what you end up with is the FlashBuilder paradigm that allows the user to code with a pseudo OO type of HTML5 as an alternative option to MXML and AS3, since we agree that it's not the translation from as3 to HTML5 that makes sense, but the paradigm itself. As for that doesn't mean you should stop using Flex/ActionScript/FlashPlayer right now, I would disagree. Over the past dozen years, I have already gone through 4 generations of web architecture: 1) CGI 2) server side XSLT transformation rendering a DHTML web page for client side 3) Flash 2004 until Adobe abandoned the push for developers to use Flash for applications and created... 4) Flex I would like to settle upon a single client-side technology that I can rely upon to be here in 15 years. Novell and Adobe have failed me in this regard. The only piece of my stack to not drop the ball on me is Java, which is why we are going with a Java based framework where the UI logic can reside server side. Do you know how hard it is to hire someone that can come in and be competent in all 4 of my web architecture generations? Very difficult. So, it's better to stop developing in Flex now so that I have less older generation architectures to eventually convert to ZKoss. Once that is done, finding someone who can help maintain all of our projects becomes a much easier task. Anyway, I very much appreciate hearing from an Adobe Flex SDK staff member. You have helped clarify that the direction I am taking is the right one. Hopefully, it's convinced a few others to not waste time writing in a technology that will one day require migration of an even greater backlog of projects to their inevitably new chosen technology stack. Ron --- In flexcoders@yahoogroups.com, Alex Harui aharui@... wrote: I'm not in disagreement that in the long term, the advantages of Flex/ActionScript/FlashPlayer will be diminished by advances in the HTML/CSS/JS stack. That's why Adobe has made a major strategic shift to become the tooling leader in the HTML stack. But that doesn't mean that you should stop using Flex/ActionScript/FlashPlayer right now. Many folks who work with HTML/CSS/JS, even using the many libraries and development methodologies available for it, still feel like the Flex paradigm is superior. Apparently, even Google agrees because they are trying to create their own version of that paradigm with DART. While translated code is never as good, the productivity advantages of a better paradigm have been pretty much proven to be worth it, otherwise, Flex wouldn't have been that successful either since MXML isn't as efficient as pure ActionScript, and Google wouldn't have invested so much in writing their website logic in Java and/or Google Closure and/or DART. There is general support in the Apache Flex project for exploring ways of using the Flex paradigm to create HTML5 apps. Those working on the project are motivated to future-proof their investment in Flex. I don't see any technical issue blocking us from translating the paradigm to HTML5, and I invite all those who like the Flex paradigm to participate. But at the same time, there is lots of work to be done, lots of solutions to be built, and lots of money to be made on the Flex/AS/FP stack while we wait for the HTML5 stack to deliver on its promises.
Re: [flexcoders] Re: Flex alternatives
Hi All, someone said adobe will not support flex in 5 to 10 years time and hence it poses a threat to flex developers. I beg to deffer because we need to clearly distinct a vendor from her products. A vendor changes focus to another phase of technology does not mean the vendor will outrightly discard her old and stable products.Its discouraging though that flex will not practically evolve to a better framework if adobe denies support in the nearest future but the consolation is the relative strength,robustness and stability of the framework when compared with other RIAs If technologies like cobol, powerbuilder,Vb6, classic ASP (though not RIAs) are still existing in the industry even though they are no longer in vogue i dont see a framework that is rich, stable ,platform independent and shows cross browser compatibility face out in the market at all. Look, i cant imagine a standard browser (in existence or still to come) that will deny compatibility with flash and yet expect to be widely used? No browser vendor will shoot herself on the leg by taking such a weak strategy. If you see a possible end for flex, what would you say of silverlight? (lol) Yet silverlight users are optimistic that Microsoft will find a way to integrate the framework to all other browsers The advent of RIAs addresses a critical need that is so significant, it saves you from the hassles of html/JS/CSS in the areas of presentation consistency across browsers and business security (though .swf files can be decompiled but its not a piece of cake) and i strongly believe flex is the most powerful RIA in the market, i cant even compare zkoss with it. Such frameworks are not abandoned, they come to stay !!! Warm Regards Tunde Majolagbe +2348028320370, 018782170. *Exchange a Dollar, we still have ONE each, exchange an idea, we have TWO each. *Calm Down!!! It’s just a mirage, like other worries it will soon fade away. From: Alex Harui aha...@adobe.com To: flexcoders@yahoogroups.com flexcoders@yahoogroups.com Sent: Thursday, 12 January 2012, 16:19 Subject: Re: [flexcoders] Re: Flex alternatives I’ve never used COBOL, but I haven’t heard anyone say they really liked working in with it. That’s not true for Flex so even if it gets marginalized because it always remains locked to ActionScript and FlashPlayer, it may not be the subject of cursing. I’m not in disagreement that in the long term, the advantages of Flex/ActionScript/FlashPlayer will be diminished by advances in the HTML/CSS/JS stack. That’s why Adobe has made a major strategic shift to become the tooling leader in the HTML stack. But that doesn’t mean that you should stop using Flex/ActionScript/FlashPlayer right now. Many folks who work with HTML/CSS/JS, even using the many libraries and development methodologies available for it, still feel like the Flex paradigm is superior. Apparently, even Google agrees because they are trying to create their own version of that paradigm with DART. While translated code is never as good, the productivity advantages of a better paradigm have been pretty much proven to be worth it, otherwise, Flex wouldn’t have been that successful either since MXML isn’t as efficient as pure ActionScript, and Google wouldn’t have invested so much in writing their website logic in Java and/or Google Closure and/or DART. There is general support in the Apache Flex project for exploring ways of using the Flex paradigm to create HTML5 apps. Those working on the project are motivated to future-proof their investment in Flex. I don’t see any technical issue blocking us from translating the paradigm to HTML5, and I invite all those who like the Flex paradigm to participate. But at the same time, there is lots of work to be done, lots of solutions to be built, and lots of money to be made on the Flex/AS/FP stack while we wait for the HTML5 stack to deliver on its promises. On 1/12/12 3:37 PM, Ron G rgri...@sinclairoil.com wrote: I think you make my point for me by comparing the future of Flex to COBOL. Yes, it's still around, but we all wish it wasn't and curse it everytime we have to deal with it. As you say, it is hard to get out. So, yes, I still have projects written in Flex that will undoubtedly continue to run for years to come. But, it's hardly a justification for continuing to develop in COBOL...er, uh, I mean Flex. As you say, the need for Flash in the browser will likely diminish. Again, you help make my point against using Flex or FlashBuilder. I find it amusing that some have suggested that Flex and FlashBuilder could be retooled to render HTML5 pages. It confounds me as to why I would want to write MXML and AS3 so it can be translated to HTML and JS. If that is the desired end product, then I suggest developers just develop in HTML and JS to begin with. Translated code is never as efficient as code specifically written
Re: [flexcoders] Re: Flex alternatives
Flex and FlashBuilder are not part of Adobe’s HTML strategy per-se. FlashBuilder is being directed towards Gaming in Flash, Flex is being donated to the community. It is the community that has lots of investment in the Flex/AS/FP stack that are looking reworking the Flex paradigm to output to the HTML/CSS/JS stack. Meanwhile Adobe is not only updating Dreamweaver (see the PhoneGap features added in 5.5) but also looking at new tools for new development methodologies. While classic Java has been around for a while, and HTML/CSS/JS will likely meet your 15 year requirement, the question remains whether you will be willing to use more efficient and powerful development frameworks and methodologies over those years. If you don’t, you might lose competitive advantage as your competition gets their products finished better or faster, but if you do, you run the risk of choosing a new set of tools that turns out not to have lasting power. Tough call, no right answer, the choice is yours. It looks like the Apache Flex folks are going to try to provide one of those new sets of tools by making it possible to use the Flex paradigm for the HTML stack. On 1/12/12 6:10 PM, Ron G rgri...@sinclairoil.com wrote: So, I think we have a similar vision for where things are going with respect to Adobe supporting HTML5 for the enterprise. But, I fail to see why Flex and FlashBuilder would have any part of that. Why not just fall back to your excellent product, Dreamweaver, and enhance it as the IDE for building HTML5 style web applications? No translation is then required. I too like the FlashBuilder/Flex paradigm for development. But, it seems to me that, sooner or later, what you end up with is the FlashBuilder paradigm that allows the user to code with a pseudo OO type of HTML5 as an alternative option to MXML and AS3, since we agree that it's not the translation from as3 to HTML5 that makes sense, but the paradigm itself. As for that doesn't mean you should stop using Flex/ActionScript/FlashPlayer right now, I would disagree. Over the past dozen years, I have already gone through 4 generations of web architecture: 1) CGI 2) server side XSLT transformation rendering a DHTML web page for client side 3) Flash 2004 until Adobe abandoned the push for developers to use Flash for applications and created... 4) Flex I would like to settle upon a single client-side technology that I can rely upon to be here in 15 years. Novell and Adobe have failed me in this regard. The only piece of my stack to not drop the ball on me is Java, which is why we are going with a Java based framework where the UI logic can reside server side. Do you know how hard it is to hire someone that can come in and be competent in all 4 of my web architecture generations? Very difficult. So, it's better to stop developing in Flex now so that I have less older generation architectures to eventually convert to ZKoss. Once that is done, finding someone who can help maintain all of our projects becomes a much easier task. Anyway, I very much appreciate hearing from an Adobe Flex SDK staff member. You have helped clarify that the direction I am taking is the right one. Hopefully, it's convinced a few others to not waste time writing in a technology that will one day require migration of an even greater backlog of projects to their inevitably new chosen technology stack. Ron --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Alex Harui aharui@... wrote: I'm not in disagreement that in the long term, the advantages of Flex/ActionScript/FlashPlayer will be diminished by advances in the HTML/CSS/JS stack. That's why Adobe has made a major strategic shift to become the tooling leader in the HTML stack. But that doesn't mean that you should stop using Flex/ActionScript/FlashPlayer right now. Many folks who work with HTML/CSS/JS, even using the many libraries and development methodologies available for it, still feel like the Flex paradigm is superior. Apparently, even Google agrees because they are trying to create their own version of that paradigm with DART. While translated code is never as good, the productivity advantages of a better paradigm have been pretty much proven to be worth it, otherwise, Flex wouldn't have been that successful either since MXML isn't as efficient as pure ActionScript, and Google wouldn't have invested so much in writing their website logic in Java and/or Google Closure and/or DART. There is general support in the Apache Flex project for exploring ways of using the Flex paradigm to create HTML5 apps. Those working on the project are motivated to future-proof their investment in Flex. I don't see any technical issue blocking us from translating the paradigm to HTML5, and I invite all those who like the Flex paradigm to participate. But at the same time, there is lots of work to be done, lots of solutions to be
RE: [flexcoders] Re: Flex alternatives
Staying with Flex. Not looking elsewhere. Michael From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Ron G Sent: Wednesday, January 11, 2012 8:15 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Flex alternatives Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a Java shop, on the server side, it seemed logical to use a Java based framework on the client-side. The thing I really like about ZK or ZKoss is that it has equivalent components to Flex. In fact, it actually has more components than Flex. It implements an approach that I really like of separating the UI into appearance and behavior - much like the Spark components of Flex. Well, not exactly, but sort of. :) Here's what I mean. For each UI object, it has a client side (widget) and server side (component). I won't go into further detail, but it gives you a nice separation of concerns that you can avail yourself of. This feature also greatly insulates the rendered pages from x-browser compatibility issues. Check it out for yourself at their site (zkoss.org). Ron --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, Sal sal.celli@...mailto:sal.celli@... wrote: hi, as i can sadly see from the message history bottom grid, many programmers are leaving flex. So this thread is to ask you all, if you have already found a valid alternative to flex for RIA development.
Re: [flexcoders] Re: Flex alternatives
Staying with Flex until I see what happens with it during its first year as an Apache project. I expect big improvements and many new and cool features, it will only depend on Adobe if it will follow with the player. Haykel Ben Jemia Allmas Web RIA Development http://www.allmas-tn.com On Thu, Jan 12, 2012 at 3:16 AM, michael_reg...@dell.com wrote: ** Staying with Flex. Not looking elsewhere. ** ** *Michael* ** ** *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] *On Behalf Of *Ron G *Sent:* Wednesday, January 11, 2012 8:15 PM *To:* flexcoders@yahoogroups.com *Subject:* [flexcoders] Re: Flex alternatives ** ** Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a Java shop, on the server side, it seemed logical to use a Java based framework on the client-side. The thing I really like about ZK or ZKoss is that it has equivalent components to Flex. In fact, it actually has more components than Flex. It implements an approach that I really like of separating the UI into appearance and behavior - much like the Spark components of Flex. Well, not exactly, but sort of. :) Here's what I mean. For each UI object, it has a client side (widget) and server side (component). I won't go into further detail, but it gives you a nice separation of concerns that you can avail yourself of. This feature also greatly insulates the rendered pages from x-browser compatibility issues. Check it out for yourself at their site (zkoss.org). Ron --- In flexcoders@yahoogroups.com, Sal sal.celli@... wrote: hi, as i can sadly see from the message history bottom grid, many programmers are leaving flex. So this thread is to ask you all, if you have already found a valid alternative to flex for RIA development.
