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