flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Newman <Capta...@unFocus.com>
Subject Re: [FalconJx] New JavaScript runtime format prototype
Date Fri, 21 Dec 2012 16:43:23 GMT
My personal preference is to prioritize runtime performance over startup 
times, though keeping in mind that startup time can be an issue, 
especially for mobile. We don't want this thing to start up horrendously 
slowly (I don't think that'll be the case here though). The best way to 
measure will be to actually measure. Maybe a jsperf comparison of the 
linked JS file, and a closure method is worth exploring (both startup 
and runtime).

BTW, what do you mean by startup times - do you mean the actual parsing, 
loading and setting up of the classes (I think this)? Or is there an 
speed issue with class instantiation as well (it seems like no)? I'm not 
actually familiar enough with require.js just yet to know how that works.

For those on the list that may not be aware, AMD/require.js modules are 
[likely] coming to JS as they are currently in the ES-harmony spec:

So are classes for that matter:

These are the patterns that TypeScript is currently targeting 
(AMD/require), and they are also increasingly popular by JS programmers 
(being spec backed to a degree helps), so Flex would be in good company 
if we choose to go the require.js/modules route, as Frank has done with 
his vanilla.js with require.js prototype.

Kevin N.

P.S. It sounds like a bad idea, but I wonder if anyone has ever tried to 
to use IE's Element as the base class for everything (instead of 
Object), to gain access to getter/setter in IE lt 9. Does an Element 
have to be on the DOM tree for get/set to work? I guess that would blow 
up memory use, and maybe slow down all property access, so it's maybe 
not useful for serious work (unless some jsperf charts shows it is), but 
I'm still curious if it could work.

On 12/21/12 5:56 AM, Frank Wienberg wrote:
> We could also move all the AS3 helper functions (as, is, bind, cast, etc.)
> into one module (maybe even the same module), but that would actually
> introduce one more property dereferencing when using these functions at
> application run time (in contrast to start-up time, at which classes and
> interfaces are defined, where ultimate performance is not so much of an
> issue).
> What do you think?

View raw message