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