Re: [flexcoders] Re: Flex alternatives

2013-05-10 Thread Alex Harui
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"  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"  wrote:








 Thank you again.

  Although

Re: [flexcoders] Re: Flex alternatives

2013-05-10 Thread John McCormack

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"  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

Re: [flexcoders] Re: Flex alternatives

2012-12-23 Thread Alex Harui
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"  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"  wrote:









--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Re: [flexcoders] Re: Flex alternatives

2012-12-23 Thread John McCormack

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"  wrote:





Re: [flexcoders] Re: Flex alternatives

2012-12-21 Thread Alex Harui
Actually, I’m not just hanging in there, I’m still paid by Adobe to spend all 
of my time on Flex.  My teammates are now folks like you who have spare cycles 
to contribute to the future of Flex.  Apache Flex just “graduated” to being an 
official “top-level” project at Apache which means it will be around for as 
long as folks want it to.  Adobe has no say in its future.

Working in Apache has been interesting because these new contributors have lots 
of diverse knowledge and experience.  The Apache Flex community is now 
investigating was to leverage a cross-compiler that can take in ActionScript 
and spit out JavaScript and allow you to use a Flex-like workflow to create 
RIAs that run without Flash.

My thoughts on that topic and prototype is written up here: 
https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype

On 12/21/12 12:50 PM, "John McCormack"  wrote:







On 21/12/2012 18:52, Alex Harui wrote:


  Re: [flexcoders] Re: Flex alternatives
  To not allow existing SWFs to play where they currently play would “break the 
web” and Adobe has no interest in doing that.

 The next generation of AS is supposed to be easy to migrate to if you just 
want to get your code to run, but there is a chance that to fully leverage the 
performance benefits of the new language you will have to learn some new 
constructs and refactor existing code.

 FlashBuilder will definitely be the IDE for developing applications for the 
new VM and new AS.



 That's all good to know. Looks like I am all set for a while, at least.

 I noticed you still hanging in there...
 http://incubator.apache.org/flex/team.html

 Thanks again.
 John






--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Re: [flexcoders] Re: Flex alternatives

2012-12-21 Thread John McCormack

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

2012-12-21 Thread Alex Harui
To not allow existing SWFs to play where they currently play would “break the 
web” and Adobe has no interest in doing that.

The next generation of AS is supposed to be easy to migrate to if you just want 
to get your code to run, but there is a chance that to fully leverage the 
performance benefits of the new language you will have to learn some new 
constructs and refactor existing code.

FlashBuilder will definitely be the IDE for developing applications for the new 
VM and new AS.


On 12/21/12 10:41 AM, "John McCormack"  wrote:







Brilliant.
 Thank you.

 I am pleased that existing SWF's will run in an embedded VM in the new player.

 Do you think the next-generation of ActionScript will be similar enough to 
make migration easy?
 and
 Is FlashBuilder likely to be the IDE that creates code for the new VM?

 John

 On 20/12/2012 05:50, Alex Harui wrote:


  Re: [flexcoders] Re: Flex alternatives  Well, there are several pieces.  
ActionScript is a language.  It is really only the dozen classes or so in the 
“top-level” in the ASDoc.  String, int, RegEx, Array, Vector, a few functions 
like unescape, etc, plus a bunch of keywords and stuff like “var”, “class”, 
plus a grammar of how you put it all together.  It hasn’t changed much in 
years, other than the addition of Vector.  There are no plans to improve on its 
specification by adding things it is missing compared to other languages like 
Java such as method overloading, or mutiple inheritance.  Instead, Adobe is 
tossing out the whole specification and developing a next-generation of 
ActionScript.  It will have some of the same things you see in the current 
ActionScript, but there will be new keywords and grammar.  The goal is to give 
up on backward compatibility in order to get significant speed improvements by 
making the language easier to execute at runtime.

 ActionScript currently only runs in a Virtual Machine embedded in the 
FlashPlayer or AIR.  Both runtimes provide additional APIs that allow you to 
draw stuff and get network i/o, etc.  The current APIs use ActionScript 3 
syntax and are focused primarily on Sprites, Shapes and MovieClips on a display 
list.  New features were added in every major release.

 Now, Adobe is working on embedding a new Virtual Machine that runs the 
next-generation ActionScript in the FlashPlayer and AIR.  The focus is on 
gaming, and a new set of APIs that talk to a 3d rendering engine is being 
devloped in the next-generation ActionScript syntax.  There will be no support 
for the old Sprites/Shapes/MovieClips and display list.

 However, the old virtual machine that runs ActionScript 3 will continue to be 
embedded in the FlashPlayer and AIR that run on tradtional desktops/laptops.  I 
would not expect it to be co-existent on mobile versions of AIR because the new 
focus is on the captive runtime workflow where you pre-process your 
ActionScript code and the runtime libraries into a device-dependent executable.

 So, given all of that, you can continue to deliver ActionScript 3 content in 
AIR or FlashPlayer on desktops/laptops “forever”.  And unless you have heard 
otherwise from the PDF team, they probably won’t eliminate support for Flash in 
PDF on desktop/laptops soon.

 I think Apache Flex exists because folks have found the Flex workflow easy and 
productive and also safe because it uses structured programming, and former 
Flex customers are now pitching in to continue to evolve Flex as much as we can 
given the constraints of the current environment.  The problem for many is 
that, because Adobe is not evolving the ActionScript 3 language, VM and runtime 
APIs related to it, folks see it as a dead end and no longer want to develop 
apps on it.  I can see their point, but there is a reason why DOS is still 
around on some custom handheld devices: it works, it is well known, and has a 
small footprint for a constrained environment.  Flash/AIR and Flex on 
ActionScript3 continue to be excellent ways to create apps quickly, but it has 
been difficult to convince customers to stick with it.

 Anyway, so far, the most interest in Apache Flex seems to be around trying to 
leverage the Flex workflow to create apps that run on the HTML/CSS/JS stack 
(without Flash).  It will have growing pains for sure, but to me, a question 
about CPU load is premature.  There is 1000’s of people from all over the world 
working on improving the runtime environment for HTML/CSS/JS.  They have made 
significant advances in the past several years and I don’t see a cap on it.  So 
any pain points you experience now are likely to be solved in the near future.  
If you can continue to use Flash/AIR and let others suffer through the growing 
pains, consider yourself lucky.  Otherwise, put on some pads and join the 
battle.

 On 12/19/12 9:29 AM, "John McCormack"  wrote:








 Thank you again.

  Although ActionScript is not being developed for the FlashPlayer, is it 
possible that 

Re: [flexcoders] Re: Flex alternatives

2012-12-21 Thread John McCormack

Brilliant.
Thank you.

I am pleased that existing SWF's will run in an embedded VM in the new 
player.


Do you think the next-generation of ActionScript will be similar enough 
to make migration easy?

and
Is FlashBuilder likely to be the IDE that creates code for the new VM?

John

On 20/12/2012 05:50, Alex Harui wrote:

Re: [flexcoders] Re: Flex alternatives

Well, there are several pieces.  ActionScript is a language.  It is 
really only the dozen classes or so in the “top-level” in the ASDoc. 
 String, int, RegEx, Array, Vector, a few functions like unescape, 
etc, plus a bunch of keywords and stuff like “var”, “class”, plus a 
grammar of how you put it all together.  It hasn’t changed much in 
years, other than the addition of Vector.  There are no plans to 
improve on its specification by adding things it is missing compared 
to other languages like Java such as method overloading, or mutiple 
inheritance.  Instead, Adobe is tossing out the whole specification 
and developing a next-generation of ActionScript.  It will have some 
of the same things you see in the current ActionScript, but there will 
be new keywords and grammar.  The goal is to give up on backward 
compatibility in order to get significant speed improvements by making 
the language easier to execute at runtime.


ActionScript currently only runs in a Virtual Machine embedded in the 
FlashPlayer or AIR.  Both runtimes provide additional APIs that allow 
you to draw stuff and get network i/o, etc.  The current APIs use 
ActionScript 3 syntax and are focused primarily on Sprites, Shapes and 
MovieClips on a display list.  New features were added in every major 
release.


Now, Adobe is working on embedding a new Virtual Machine that runs the 
next-generation ActionScript in the FlashPlayer and AIR.  The focus is 
on gaming, and a new set of APIs that talk to a 3d rendering engine is 
being devloped in the next-generation ActionScript syntax.  There will 
be no support for the old Sprites/Shapes/MovieClips and display list.


However, the old virtual machine that runs ActionScript 3 will 
continue to be embedded in the FlashPlayer and AIR that run on 
tradtional desktops/laptops.  I would not expect it to be co-existent 
on mobile versions of AIR because the new focus is on the captive 
runtime workflow where you pre-process your ActionScript code and the 
runtime libraries into a device-dependent executable.


So, given all of that, you can continue to deliver ActionScript 3 
content in AIR or FlashPlayer on desktops/laptops “forever”.  And 
unless you have heard otherwise from the PDF team, they probably won’t 
eliminate support for Flash in PDF on desktop/laptops soon.


I think Apache Flex exists because folks have found the Flex workflow 
easy and productive and also safe because it uses structured 
programming, and former Flex customers are now pitching in to continue 
to evolve Flex as much as we can given the constraints of the current 
environment.  The problem for many is that, because Adobe is not 
evolving the ActionScript 3 language, VM and runtime APIs related to 
it, folks see it as a dead end and no longer want to develop apps on 
it.  I can see their point, but there is a reason why DOS is still 
around on some custom handheld devices: it works, it is well known, 
and has a small footprint for a constrained environment.  Flash/AIR 
and Flex on ActionScript3 continue to be excellent ways to create apps 
quickly, but it has been difficult to convince customers to stick with it.


Anyway, so far, the most interest in Apache Flex seems to be around 
trying to leverage the Flex workflow to create apps that run on the 
HTML/CSS/JS stack (without Flash).  It will have growing pains for 
sure, but to me, a question about CPU load is premature.  There is 
1000’s of people from all over the world working on improving the 
runtime environment for HTML/CSS/JS.  They have made significant 
advances in the past several years and I don’t see a cap on it.  So 
any pain points you experience now are likely to be solved in the near 
future.  If you can continue to use Flash/AIR and let others suffer 
through the growing pains, consider yourself lucky.  Otherwise, put on 
some pads and join the battle.


On 12/19/12 9:29 AM, "John McCormack"  wrote:







Thank you again.

 Although ActionScript is not being developed for the FlashPlayer,
is it possible that it may still be developed separately for use
in AIR? I could deliver content through AIR instead of PDFs.

 My problem is that the FlashBuilder / Flash Professional workflow
is such a seductive one, with that easy marriage of graphics and
code, that I don't want to lose it. I have used C++ to produce
graphical programs and the AS3 route is a godsend in comparison.

 One wonders "Is HMTL5 going to use any less CPU cycles than AS3,
once it is doing similar work?"

 John

 On 18/12/2012 05:38, Al

Re: [flexcoders] Re: Flex alternatives

2012-12-19 Thread Alex Harui
Well, there are several pieces.  ActionScript is a language.  It is really only 
the dozen classes or so in the “top-level” in the ASDoc.  String, int, RegEx, 
Array, Vector, a few functions like unescape, etc, plus a bunch of keywords and 
stuff like “var”, “class”, plus a grammar of how you put it all together.  It 
hasn’t changed much in years, other than the addition of Vector.  There are no 
plans to improve on its specification by adding things it is missing compared 
to other languages like Java such as method overloading, or mutiple 
inheritance.  Instead, Adobe is tossing out the whole specification and 
developing a next-generation of ActionScript.  It will have some of the same 
things you see in the current ActionScript, but there will be new keywords and 
grammar.  The goal is to give up on backward compatibility in order to get 
significant speed improvements by making the language easier to execute at 
runtime.

ActionScript currently only runs in a Virtual Machine embedded in the 
FlashPlayer or AIR.  Both runtimes provide additional APIs that allow you to 
draw stuff and get network i/o, etc.  The current APIs use ActionScript 3 
syntax and are focused primarily on Sprites, Shapes and MovieClips on a display 
list.  New features were added in every major release.

Now, Adobe is working on embedding a new Virtual Machine that runs the 
next-generation ActionScript in the FlashPlayer and AIR.  The focus is on 
gaming, and a new set of APIs that talk to a 3d rendering engine is being 
devloped in the next-generation ActionScript syntax.  There will be no support 
for the old Sprites/Shapes/MovieClips and display list.

However, the old virtual machine that runs ActionScript 3 will continue to be 
embedded in the FlashPlayer and AIR that run on tradtional desktops/laptops.  I 
would not expect it to be co-existent on mobile versions of AIR because the new 
focus is on the captive runtime workflow where you pre-process your 
ActionScript code and the runtime libraries into a device-dependent executable.

So, given all of that, you can continue to deliver ActionScript 3 content in 
AIR or FlashPlayer on desktops/laptops “forever”.  And unless you have heard 
otherwise from the PDF team, they probably won’t eliminate support for Flash in 
PDF on desktop/laptops soon.

I think Apache Flex exists because folks have found the Flex workflow easy and 
productive and also safe because it uses structured programming, and former 
Flex customers are now pitching in to continue to evolve Flex as much as we can 
given the constraints of the current environment.  The problem for many is 
that, because Adobe is not evolving the ActionScript 3 language, VM and runtime 
APIs related to it, folks see it as a dead end and no longer want to develop 
apps on it.  I can see their point, but there is a reason why DOS is still 
around on some custom handheld devices: it works, it is well known, and has a 
small footprint for a constrained environment.  Flash/AIR and Flex on 
ActionScript3 continue to be excellent ways to create apps quickly, but it has 
been difficult to convince customers to stick with it.

Anyway, so far, the most interest in Apache Flex seems to be around trying to 
leverage the Flex workflow to create apps that run on the HTML/CSS/JS stack 
(without Flash).  It will have growing pains for sure, but to me, a question 
about CPU load is premature.  There is 1000’s of people from all over the world 
working on improving the runtime environment for HTML/CSS/JS.  They have made 
significant advances in the past several years and I don’t see a cap on it.  So 
any pain points you experience now are likely to be solved in the near future.  
If you can continue to use Flash/AIR and let others suffer through the growing 
pains, consider yourself lucky.  Otherwise, put on some pads and join the 
battle.

On 12/19/12 9:29 AM, "John McCormack"  wrote:







Thank you again.

 Although ActionScript is not being developed for the FlashPlayer, is it 
possible that it may still be developed separately for use in AIR? I could 
deliver content through AIR instead of PDFs.

 My problem is that the FlashBuilder / Flash Professional workflow is such a 
seductive one, with that easy marriage of graphics and code, that I don't want 
to lose it. I have used C++ to produce graphical programs and the AS3 route is 
a godsend in comparison.

 One wonders "Is HMTL5 going to use any less CPU cycles than AS3, once it is 
doing similar work?"

 John

 On 18/12/2012 05:38, Alex Harui wrote:


  Re: [flexcoders] 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 

Re: [flexcoders] Re: Flex alternatives

2012-12-19 Thread John McCormack

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"  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 t

Re: [flexcoders] Re: Flex alternatives

2012-12-17 Thread Alex Harui
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"  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"  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.&

Re: [flexcoders] Re: Flex alternatives

2012-12-17 Thread Alex Harui
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"  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

2012-12-17 Thread John McCormack

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"  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

2012-12-17 Thread Nigel Magnay
>
> 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

2012-12-17 Thread Alex Harui
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"  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

2012-12-17 Thread John McCormack

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

2012-12-16 Thread Alex Harui
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"  wrote:








--- In flexcoders@yahoogroups.com  , "Sal" 
 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

2012-12-16 Thread Carlos Rovira
Real alternative?... Nothing. There's only Flex  ;)

El sábado, 15 de diciembre de 2012, Sal escribió:

> **
>
>
>
>
> --- In flexcoders@yahoogroups.com  'flexcoders%40yahoogroups.com');>, "Sal"  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

2012-12-16 Thread Riccardo Cohen
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"  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






--
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

2012-12-15 Thread Carlos Rovira
Real alternative?... Nothing. There's only Flex  ;)

El sábado, 15 de diciembre de 2012, Sal escribió:

> **
>
>
>
>
> --- In flexcoders@yahoogroups.com  'flexcoders%40yahoogroups.com');>, "Sal"  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


[flexcoders] Re: Flex alternatives

2012-12-15 Thread Sal


--- In flexcoders@yahoogroups.com, "Sal"  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?



Re: [flexcoders] Re: Flex alternatives

2012-01-19 Thread Dave Glasser
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 
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  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

2012-01-18 Thread Sam Lai
On 18 January 2012 02:05, Merrill, Jason wrote:

>
>
>  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  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"  wrote:
> > > >
> > > >
> > > > On a side note, I like the look of ZKoss. I don't know if there are
> cross browser issues with it

[flexcoders] Re: Flex alternatives

2012-01-17 Thread Ron G
Here's another link on ZK and HTML5: 

http://jaxenter.com/what-s-new-in-zk-5-0-6-35297.html

"Firstly, ZK 6 will bring with it HTML 5 & CSS 3 support as we look to 
integrate features such as local file access, audio, video and canvas support. 
We are looking to implement HTML 5 as we see it as a core component of 
continuing to provide the best cross platform experience possible.
 
The second major improvement will be the introduction of substantial features 
to databinding including easier ways of binding across different scopes, 
loading and saving on changes of a model variable and extended increased EL 
expression support.
 
The third will come as no surprise to our regular users. ZK is based on jQuery 
and as such works in a multitude of browsers including smart phones. We are 
looking to go even further with smart phone and tablet support by integrating 
jQuery mobile technology into ZK 6, enhancing the experience on devices where a 
touch screen is their primary interface method such as, iPhone, iPad and 
Android based phones.
 
Lastly, one of the most anticipated innovations will be the inclusion of 
server-side selector technology for Java. This unique technology affords 
developers an incredibly easy and productive method of selecting and accessing 
server-side components.
 
The above features are only the tip of the iceberg for ZK, not to mention our 
other product line such as ZK Spreadsheet, ZK Calendar and ZK Studio. 2011 will 
be an exciting year for ZK developers."

Currently, they are on RC2 for ZK 6. So, I would anticipate these features 
being GA soon. 

Ron


--- In flexcoders@yahoogroups.com, "Ron G"  wrote:
>
> Just go to Zkoss.org and do a search on HTML5. You'll see a lot about how it 
> is increasing support for HTML5. Here is one neat "small talk" for example: 
> 
> http://books.zkoss.org/wiki/Small_Talks/2011/October/ZK_Html5_Canvas_Charts 
> 
> Also, if you download the source for ZK, and browse through it, you'll see 
> its heavy reliance on jQuery on the client side.
> 
> Ron
> 
> --- In flexcoders@yahoogroups.com, "Merrill, Jason"  wrote:
> >
> > >> 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 mailto:rgrimes@>>
> > 
> > 
> > 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 

[flexcoders] Re: Flex alternatives

2012-01-17 Thread Ron G
Just go to Zkoss.org and do a search on HTML5. You'll see a lot about how it is 
increasing support for HTML5. Here is one neat "small talk" for example: 

http://books.zkoss.org/wiki/Small_Talks/2011/October/ZK_Html5_Canvas_Charts 

Also, if you download the source for ZK, and browse through it, you'll see its 
heavy reliance on jQuery on the client side.

Ron

--- In flexcoders@yahoogroups.com, "Merrill, Jason"  wrote:
>
> >> 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 mailto:rgrimes@...>>
> 
> 
> 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

2012-01-17 Thread Merrill, Jason
>> 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 mailto: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

2012-01-17 Thread Merrill, Jason
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.com<mailto:flexcoders%40yahoogroups.com>, Guy 
Morton  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<mailto:flexcoders%40yahoogroups.com>, 
> > "valdhor"  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 oth

[flexcoders] Re: Flex alternatives

2012-01-17 Thread valdhor
Yes, that is the case with my company as well (300,000+ employees) but there is 
procedures for getting things done. We have all kinds of in house built 
applications and a special installer application for installing them on users 
machines.

As I said, the AIR apps are only used for building IOS apps.

Flash Player is updated regularly and is pushed to every computer on the 
network.

--- In flexcoders@yahoogroups.com, "Ron G"  wrote:
>
> The problem with that approach is a lot of people are behind corporate 
> firewalls where they also do not have local admin rights and are therefore 
> not allowed to install anything on their desktop. If they want it, they have 
> to call the network guys and get authorization and then have them install it. 
> That's the way my company is and we're over 5000 employees strong. Now, if 
> that's just one company, I can safely say you're still excluding millions by 
> going with an AIR app. This is the reason I never used the AIR feature 
> before, but always deployed my web apps as SWFs. Even that was a problem if 
> someone had an older version of Flashplayer and I had built the app for a 
> newer version of FP. 
> 
> Ron
> 
> 
> --- In flexcoders@yahoogroups.com, "valdhor"  wrote:
> >
> > On the suggestion that I will be leaving IOS devices out, that seems 
> > absurd. You can use the same Flex code and with some modifications make it 
> > into an AIR app that can be compiled for IOS devices.
> > 
> > Again, all just my perspective. I think some people are blowing the open 
> > source announcement out of all perspective.
> >
>




Re: [flexcoders] Re: Flex alternatives

2012-01-17 Thread Johannes Nel
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  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 
>
>> **
>>
>>
>> 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

2012-01-17 Thread John Fletcher
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 

> **
>
>
> 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
>


[flexcoders] Re: Flex alternatives

2012-01-16 Thread Ron G
The problem with that approach is a lot of people are behind corporate 
firewalls where they also do not have local admin rights and are therefore not 
allowed to install anything on their desktop. If they want it, they have to 
call the network guys and get authorization and then have them install it. 
That's the way my company is and we're over 5000 employees strong. Now, if 
that's just one company, I can safely say you're still excluding millions by 
going with an AIR app. This is the reason I never used the AIR feature before, 
but always deployed my web apps as SWFs. Even that was a problem if someone had 
an older version of Flashplayer and I had built the app for a newer version of 
FP. 

Ron


--- In flexcoders@yahoogroups.com, "valdhor"  wrote:
>
> On the suggestion that I will be leaving IOS devices out, that seems absurd. 
> You can use the same Flex code and with some modifications make it into an 
> AIR app that can be compiled for IOS devices.
> 
> Again, all just my perspective. I think some people are blowing the open 
> source announcement out of all perspective.
> 




[flexcoders] Re: Flex alternatives

2012-01-16 Thread Ron G
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


--- In flexcoders@yahoogroups.com, "joaoak"  wrote:
>
> From what I've seen, in Zkoss there's a strong coupling between the server 
> and the client. I might be wrong, but when I tested the demos it looked to me 
> that any user interaction (ex: clicking on a button) ends up in a call to the 
> server. I'm not a big fan of this approach...
> 
> I think you might find this article interesting for this discussion: "After 6 
> years doing Flex, am I moving to HTML5?": 
> https://plus.google.com/109047477151984864676/posts/CVGJKLMMehs
> 
> Bottom line: when working on enterprise RIAs, I would lower my expectations 
> on finding a viable alternative to Flex, at least for the next two years. In 
> the meantime, either you cut on the requirements and UX, or simply stick with 
> Flex.
> 
> JS
>




[flexcoders] Re: Flex alternatives

2012-01-16 Thread joaoak
>From what I've seen, in Zkoss there's a strong coupling between the server and 
>the client. I might be wrong, but when I tested the demos it looked to me that 
>any user interaction (ex: clicking on a button) ends up in a call to the 
>server. I'm not a big fan of this approach...

I think you might find this article interesting for this discussion: "After 6 
years doing Flex, am I moving to HTML5?": 
https://plus.google.com/109047477151984864676/posts/CVGJKLMMehs

Bottom line: when working on enterprise RIAs, I would lower my expectations on 
finding a viable alternative to Flex, at least for the next two years. In the 
meantime, either you cut on the requirements and UX, or simply stick with Flex.

JS



Re: [flexcoders] Re: Flex alternatives

2012-01-16 Thread Rajan Jain
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 
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  wrote:

  
>Good luck on convincing IT departments in large corporations who are generally 
>Microsoft shops.
>
>
>--- In flexcoders@yahoogroups.com, Guy Morton  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"  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

2012-01-16 Thread Rogerio Gonzalez
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 wrote:

> **
>
>
> Good luck on convincing IT departments in large corporations who are
> generally Microsoft shops.
>
>
> --- In flexcoders@yahoogroups.com, Guy Morton  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"  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.
> > > >
> > >
> > >
> >
>
>  
>


[flexcoders] Re: Flex alternatives

2012-01-16 Thread valdhor
All of that seems inordinately complex compared to just coding in ActionScript.

I still believe there is a future with Flex (I am planning for 3-5 years). 
Adobe is still developing Flash for the desktop.

Flex is just an ActionScript Framework (Or library if you like to think of it 
that way) of components. It has been free to download for quite some time. Open 
sourcing the code just lets the community fix some bugs, enhance some 
components and create new ones (Although that has been happening for some time 
anyway). There have been patches, workarounds and new components being built by 
members of the community already. The only difference now is Adobe is not the 
only entity that can push official releases. I liken it to how Apple open 
sourced Darwin.

Hopefully Adobe (Or someone else) can build an IDE for HTML5/JS/CSS that is as 
easy to use as Flash Builder and insulates developers from the complexities 
inherent in that workflow. Once that happens I will be moving forward. At the 
moment there is nothing I believe ready for prime time except maybe ZKoss 
(Although I have yet to make that determination).

On the suggestion that I will be leaving IOS devices out, that seems absurd. 
You can use the same Flex code and with some modifications make it into an AIR 
app that can be compiled for IOS devices.

Again, all just my perspective. I think some people are blowing the open source 
announcement out of all perspective.

--- In flexcoders@yahoogroups.com, "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"  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.
> >
>




[flexcoders] Re: Flex alternatives

2012-01-16 Thread valdhor
Good luck on convincing IT departments in large corporations who are generally 
Microsoft shops.

--- In flexcoders@yahoogroups.com, Guy Morton  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"  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.
> > > 
> > 
> >
>




[flexcoders] Re: Flex alternatives

2012-01-15 Thread Ron G


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"  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

2012-01-15 Thread Carlos Rovira
For me it's easy...there's no replacement for Flex...so... ;)

2012/1/15 Ron G 

> **
>
>
> 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,  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. 
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid


[flexcoders] Re: Flex alternatives

2012-01-14 Thread Ron G
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,  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
> 




[flexcoders] Re: Flex alternatives

2012-01-14 Thread Ron G
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  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
>




Re: [flexcoders] Re: Flex alternatives

2012-01-13 Thread Richard Rodseth
Apache FlashKit !

On Fri, Jan 13, 2012 at 11:17 AM, Alex Harui  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"  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 
> 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,   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  wrote:
> >
> > Using ZK an

Re: [flexcoders] Re: Flex alternatives

2012-01-13 Thread Alex Harui
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"  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  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,   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  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,  wrote:
>
> > **
> >
> >
> > Staying with Flex. Not looking els

Re: [flexcoders] Re: Flex alternatives

2012-01-13 Thread Richard Rodseth
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  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,  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  wrote:
>> >
>> > Using ZK a

Re: [flexcoders] Re: Flex alternatives

2012-01-13 Thread Richard Rodseth
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,  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  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,  wrote:
> >
> >

RE: [flexcoders] Re: Flex alternatives

2012-01-13 Thread michael_regert
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 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, 
> mailto: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'

[flexcoders] Re: Flex alternatives

2012-01-13 Thread valdhor
We are staying with Flex as well but keeping an eye on what is happening.

I work for a very large enterprise company and it takes a while for our IT 
department to test software before deployment. They have almost completed 
Windows 7 and have a tentative deployment start of 2012. In late 2011 IE7 was 
ratified and became the company standard for web browsing. Up until then we had 
to stay with IE6!

As far as we are concerned HTML5/JS is not ready for prime time. Many 
enterprise customers are in the same boat and do not deliver the bleeding edge 
to their users.

Once there is a viable ecosystem available for HTML5/JS (Including mature IDE's 
of the same value as Flash Builder with Flex) we will seriously look at them. I 
really don't see that happening for at least 5 years.

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.

--- In flexcoders@yahoogroups.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<mailto:flexcoders%40yahoogroups.com>, "Sal" 
> 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

2012-01-13 Thread Julian Tenney
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.com<mailto:flexcoders%40yahoogroups.com>, "Ron G" 
 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.com<mailto:flexcoders%40yahoogroups.com>, Alex 
> Harui  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 m

[flexcoders] Re: Flex alternatives

2012-01-13 Thread Mark
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.com, "Ron G"  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.com, Alex Harui  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.
>




[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G

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.com, Alex Harui  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.




Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Alex Harui
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"  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  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

[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G
Rishi Tandon,

Seems to me, from your signature, that you have an invested interest in Flex 
continuing. I would say that makes it difficult for you to see the "difference 
between a reality and our own perception", as you so aptly put it.

The least Adobe could do, after kicking Flex out to go live with the neighbor 
is be honest with their customers and say, "We recommend that you stop 
developing in Flex because targeting web applications for the Flashplayer is a 
dead-end endeavor. We recommend that you begin any new projects (not already in 
progress) in HTML5 or another technology." Instead, being embarrassed at 
pulling the rug out from under their developer base, they feed them the lie 
that they're going to be there for the Flex developers in the long haul. Anyone 
with reading comprehension knows such a declaration, in light of other 
statements from Adobe, is a request that we practice cognitive dissonance 
voluntarily. 

Flee maya, Rishi. 

Ron

--- In flexcoders@yahoogroups.com, Rishi Tandon  wrote:
>
> 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




Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Tunde Majolagbe


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 
To: "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"  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 wit

Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Rishi Tandon
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"  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  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.
> 
> 


[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G


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  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

2012-01-12 Thread Alex Harui
ing, 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>  
> <mailto:flexcoders%40yahoogroups.com> , James Ong  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,  wrote:
> >
> > > **
> > >
> > >
> > > Staying with Flex.  Not looking elsewhere.
> > >
> > > ** **
> > >
> > > *Michael*
> > >
> > > ** **
> > >
> > > *From:* flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com>  
> > > <mailto:flexcoders%40yahoogroups.com>  [mailto:flexcoders@yahoogroups.com 
> > > <mailto:flexcoders%40yahoogroups.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>  
> > > <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 <mailto:flexcoders%40yahoogroups.com>  
> > > <mailto:flexcoders%40yahoogroups.com> , "Sal"  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.
> > > >
> > >
> > > 
> > >
> > >
> > >
> >
>
>
>
>
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>






--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G
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, Alex Harui  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"  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  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,  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:* flexco

Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Alex Harui
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"  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  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,  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
> > cl

RE: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Merrill, Jason
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 
mailto: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  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,  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 al

RE: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Merrill, Jason
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.com<mailto:flexcoders%40yahoogroups.com>, 
"Merrill, Jason"  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.com<mailto:flexcoders%40yahoogroups.com> 
> [mailto:flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com>] On 
> Behalf Of Ron G
> Sent: Wednesday, January 11, 2012 9: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<mailto:flexcoders%40yahoogroups.com><mailto:flexcoders%40yahoogroups.com>,
>  "Sal"  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 

Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread ganaraj p r
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  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  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,  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
> > > co

[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G
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  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,  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"  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.
> > >
> >
> > 
> >
> >  
> >
>




[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G
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.com, "Merrill, Jason"  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.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.com<mailto:flexcoders%40yahoogroups.com>, "Sal" 
>  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

2012-01-12 Thread Merrill, Jason
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.com<mailto:flexcoders%40yahoogroups.com>, "Sal" 
 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

2012-01-12 Thread James Ong
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,  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"  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

2012-01-11 Thread Haykel BEN JEMIA
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,  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"  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

2012-01-11 Thread michael_regert
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<mailto:flexcoders%40yahoogroups.com>, "Sal" 
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.
>



[flexcoders] Re: Flex alternatives

2012-01-11 Thread Ron G
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"  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.
>