On 4/25/13 11:53 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
>>
>> 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?
The way I see it, there is already a working event subsystem. There isn't
much code to it, it mostly leverages the event system in the browsers which
as far as I know is complete. Erik is proposing to replace this subsystem
with the larger goog.events even though we have no hard evidence that there
is a fatal flaw in the current subsystem. IMO, we've already spent the time
on building out a working subsystem that is lighterweight. We can't get that
time back.
So, if it ain't broke, why fix it with something larger? I wish his changes
separate the goog.events change from the other clean up he did. That way,
if we do later find hard evidence of a fatal flaw, we can either choose to
fix the current code or drop in goog.events.
>
>
>> 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.
I'm not sure either. I've been asking for objective reasoning and all I'm
hearing is the prediction that the current code will have more bugs. By
this logic, maybe we should switch to Jquery. It's code has probably even
more mileage on it.
>
>
>> 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.
Because we need to decide whether the entire Flex on JS will support IE6 and
IE7. If so, there's a lot more code we need to add to HTTPService, for
example. I haven't heard anyone ask for anything older than IE8. I'd much
rather not support it and save code and time and testing everywhere.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
