All Over Software Jobs: [flexcoders] Re: Flex alternatives

Monday, January 16, 2012

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" <rgrimes@...> wrote:
>
>
>
> Valdhor:
>
> You are right about that. That is precisely why we went with Flex originally (it insulated us from X-Browser issues). But, since we can't count on that lasting, and even Adobe is telling developers to plan on moving to HTML5, it seems like they're pushing us back into x-browser hell.
>
> I didn't want to go there, which is why we chose ZKoss. Yes, there is still going to be HTML/JS/CSS ultimately used, but it's how much. Even Flex SWFs are wrapped in HTML and JS when deployed. So, it's not that I'm against using any amount of HTML/JS; it's how little can I get away with to avoid these issues.
>
> Even with HTML5 libraries, such as the much touted jQuery, is, to a large degree, an insulator against x-browser issues. If you read the actual jQuery code, it deals with those issues for you.
>
> Now, ZK has a ZK Client JS library, which includes jQuery, that is designed to be a communicator mechanism between the client and the bulk of app logic that resides on the server. So, your normal editing and data manipulation that you might write in JS in a full blown HTML5 app is actually stored as Java on the server, and executed as needed per the EDA (event driven architecture). This type of JS is typically what breaks the page on different browsers and versions thereof. By limiting the amount of client-side JS, as does a jQuery type library, yes, you have some exposure to potential x-browser issues, but not as much as a HTML5 app that does everything on the client. And, when there are issues, they can be resolved in the ZK Client library as a patch/fix.
>
> So, now it seems to me that developers have several choices. Stick with Flex and you won't break the browser; you just won't be able to have your app viewed by millions on iOS products. If that seems like a better solution that minimal exposure to x-browser issues by using ZK or some other technology, well, that's certainly a choice each company has to make.
>
> Ron
>
> --- In flexcoders@yahoogroups.com, "valdhor" <valdhorlists@> wrote:
> >
> >
> > On a side note, I like the look of ZKoss. I don't know if there are cross browser issues with it seeing as we use older versions of browsers. One of the great features of Flex is we don't have to bother coding for compatibility between different browsers and versions. When IT deployed IE7, Flex applications worked just as they had before.
> >
> > Anyway, just my 2c from the enterprise perspective.
> >
>