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:
http://wiki.ecmascript.org/doku.php?id=harmony:modules
So are classes for that matter:
http://wiki.ecmascript.org/doku.php?id=harmony:classes
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?
