The "cross-browser" compatibility is greatly exaggerated by adobe and "widget" programmers who don't have to do heavy application programming. I have been worki

The "cross-browser" compatibility is greatly exaggerated by adobe and "widget" programmers who don't have to do heavy application programming. I have been working with a large team for two years on a website with heavy flex integration and we have had far more browser incompatibility problems with the Flex than the HTML/Javascript portions. Rendering is very consistent across browsers but the network stack is largely handed off to the browser which introduces all kinds of problems. Also, things like transparency and background mode can massively degrade in the wrong browser/OS pair which means testing all of your supported platforms for performance and turning off features accordingly. The network stack is very hard to get right on all browsers. Big surprises like Internet Explorer can't parse an XML file over HTTPS if caching is disabled for the resource. Thats right. Now considering that virtually all XML API calls out there disable caching, this is really annoying. So basically we had to detect when a Flex client was calling our services and remove the no-caching headers. And of course, since you don't want to cache you have to add in a nonce on the url or it will never be called again. Also, Flex can't by default handle anything other than HTTP 200 so better recode all of you server processes to basically be Flex specific, returning Flex friendly HTTP codes and headers. The Flex network stack is simply pathetic. Our QA team tests the Flex application on all supported browsers. They do not even bother anymore with the HTML portion because errors have become so comparatively rare.