Startup Time must meet a certain threshold of acceptability before enough folks will use your app and worry about runtime performance.
IMO, startup time has several metrics: -First visual indicator: a progress bar or splash screen, enough to tell you that something is running -first screen: enough to tell what is running -first interaction: when you can start using the app -first goal: when you feel like you've accomplished some task with the app. Small apps collapse all of these into one, but the framework needs to support them being separate in really large apps. Also, IMO, standards are a double-edged sword. It is nice to have the consistency in your targets, but they can also be heavy and slow. It isn't clear we should just automatically use any standard. We chose the DOM event model in Flash/Flex because Macromedia was all about standards at the time, and I'm not clear it was the right decision. More efficient notification schemes were certainly possible, especially outside the actual display list. I saw a brief overview of Require and it seemed way more difficult than goog.require, but I could be wrong about that. There's some adage about premature optimization. These conversations are starting to feel like that. Let's get more code running, try to get people to use it, then figure out where we need to optimize. One of the good/bad things about JS it that it seems infinitely malleable. On 12/21/12 8:43 AM, "Kevin Newman" <capta...@unfocus.com> wrote: > 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? > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
