flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Wienberg <fr...@jangaroo.net>
Subject Re: [FalconJx] New JavaScript runtime format prototype
Date Fri, 21 Dec 2012 20:50:28 GMT
On Fri, Dec 21, 2012 at 5:43 PM, Kevin Newman <CaptainN@unfocus.com> wrote:

> 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.

Only the former one. The require() (or rather define()) callbacks are only
needed for getting "acquainted to your dependencies". As class
instantiation is performed synchronously, you wouldn't even have the chance
to wait for a dependent class to load. In my prototype, the only runtime
overhead of a class instantiation (new A()) comes from the support for
"lazy class initialization".

Thanks for supporting my AMD approach by pointing at the ES-harmony spec!
That was what I meant by being "more standard" than goog.require().

I also had a closer look at TypeScript and because it claims "enabling
ECMAScript 6 today", thought of using it as a compile target. I scrapped
that idea in the meantime for reasons I'll explain in an upcoming blog post
on the Jangaroo blog.

About your idea to use DOM elements to have JavaScript objects with
functioning getters/setters in IE8, yes, it's a wild idea. But I am afraid
that a) DOM elements inherit too many members you don't want to have and
you'd have to hide / get rid of and b) there will probably a performance
problem. Bernd Paradies once said on his blog that there were even
performance problems with getters/setters in several browsers that fully
supported the feature and thus he wanted to emulate them through normal
methods. While I assume the performance problem has gone away in the
meantime, we could still follow that approach to support IE8. After all, we
should have all the information at hand whether a property is a "real"
field or actually a getter/setter and rewrite the calling code accordingly.
The downside is that such properties could not be used straight-forwardly
from plain JavaScript code.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message