[flexcoders] Re: Flex alternatives

[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

[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

[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

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

[flexcoders] Skinning question

[michael_regert]

I'm still trying to learn solid skinning practices and looking for a 
recommendation.  I need to skin a component based on our UXD design.  I can do 
half of what I need in CSS ,but then I need to actually copy the spark skin and 
modify it for the remain part. My question is, since I'm already creating a new 
skin class to do part of what I need, is there any benefit to declaring the 
remaining pieces in CSS, or should I just hard code all of it in the new skin 
class?  To me, it seems like I'd want all of the changes together for a future 
developer to read rather than half in CSS and half in a skin class.  Thoughts?


Michael J. Regert

Re: [flexcoders] Re: Flex alternatives

[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

[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

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

Re: [flexcoders] Flex alternatives

[Paul Andrews]

Time they remade "Fantasy Island", I think.

They could start with a ship arriving for the Flex Alternatives conference.

Tattoo could feed the SilverLight impostor to the sharks.

LOL

On 16/01/2012 12:23, 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] Flex alternatives

[Guy Morton]

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