> > Om, Justin, please read the following. If it does not change your mind > about taking Erik's change then we will take it since I will have then been > outvoted. > > 1. You only get once chance to make a first impression. Even if the app > starts fast when your JS or RSL is cached, the fact is that there are times > when it isn't cached. In early 2011, a vendor of a very popular consumer > desktop app was looking to port their app to Flex. They could not because > of the startup time for first time users. A couple of banks reported the > same issue trying to build consumer facing apps. I think that helped seal > Flex's fate. We were never able to use Flex to deliver a popular app that > everyone had to have. >
I agree with almost everything you said. But any code anyone writes will add to the file size. Do you think that your approach will result in lesser code? Will it support all the use cases (other than IE6/7 support) that Erik wants to support by using this library? Why do we want to spend time on a problem that has already been solved and has been proven to be a very robust solution? Other than adding to file size, what are your arguments against it? > 2. At home, I get about 80K/sec download speed. This 6K I won't feel, but > if we keep adding 6K just because we think it will have fewer bugs, it > won't > take long before I feel it. > You are implying that we are adding 6K worth of code for no reason. I am not sure if that is the case. > 3. I would like to do a poll to see if we need to support IE6 and/or IE7, > but will it change your opinion if we don't need to support these old > browsers? If not, then the votes have been cast. > I wouldn't want to spend time writing and testing code for IE6 and IE7. But if it comes as pre-packaged deal like this instance, I dont see the harm in using it. > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > >
