Malte Ubl has been doing some interesting transforms for AMD and
commonjs code to allow the use of advanced mode optimizations in
Closure Compiler on AMD code, and in particular on Dojo:

https://plus.google.com/u/0/116910304844117268718/posts/5gLAFP4eK9f

See his most recent comment.

James

Search Discussions

  • Chris Mitchell at Dec 2, 2011 at 5:25 pm
    excellent!
    On Fri, Dec 2, 2011 at 5:14 PM, James Burke wrote:
    Malte Ubl has been doing some interesting transforms for AMD and
    commonjs code to allow the use of advanced mode optimizations in
    Closure Compiler on AMD code, and in particular on Dojo:

    https://plus.google.com/u/0/116910304844117268718/posts/5gLAFP4eK9f

    See his most recent comment.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Stephen Chung at Dec 3, 2011 at 7:58 pm
    Sorry to disappoint you, but not so fast... Translating AMD code to Closure
    modules is only the easy part. The really hard part involves automatic
    handling of all property accesses via string names -- and all those
    on("event"...), _setXXXAttr() etc. calls, eliminate/translate-away object
    alias usages, as well as converting Dojo-style docs to Closure-style
    JsDoc-variants.

    - Stephen

    -----Original Message-----
    From: Chris Mitchell
    Sent: Saturday, 3 December, 2011 6:25 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Closure Compiler advanced optimizations
    with dojo/AMD code

    excellent!
    On Fri, Dec 2, 2011 at 5:14 PM, James Burke wrote:
    Malte Ubl has been doing some interesting transforms for AMD and
    commonjs code to allow the use of advanced mode optimizations in
    Closure Compiler on AMD code, and in particular on Dojo:

    https://plus.google.com/u/0/116910304844117268718/posts/5gLAFP4eK9f

    See his most recent comment.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Ben hockey at Dec 3, 2011 at 8:55 pm
    i was wondering about that issue myself...

    have you confirmed that this problem is NOT solved? i haven't looked
    at this in depth yet so i don't know if that was even considered.
    however, i would imagine that it might be possible that if you could
    make the closure compiler understand AMD then you might be able to
    make it also realize that the property names for anything exported
    from a module cannot be minified. that's just a wild guess. i think
    if the compiler understood that much about AMD then it should work.
    is that right?

    ben...
    On Dec 3, 2011, at 7:58 PM, Stephen Chung wrote:

    Sorry to disappoint you, but not so fast... Translating AMD code to
    Closure
    modules is only the easy part. The really hard part involves
    automatic
    handling of all property accesses via string names -- and all those
    on("event"...), _setXXXAttr() etc. calls, eliminate/translate-away
    object
    alias usages, as well as converting Dojo-style docs to Closure-style
    JsDoc-variants.

    - Stephen

    -----Original Message-----
    From: Chris Mitchell
    Sent: Saturday, 3 December, 2011 6:25 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Closure Compiler advanced
    optimizations
    with dojo/AMD code

    excellent!
    On Fri, Dec 2, 2011 at 5:14 PM, James Burke wrote:
    Malte Ubl has been doing some interesting transforms for AMD and
    commonjs code to allow the use of advanced mode optimizations in
    Closure Compiler on AMD code, and in particular on Dojo:

    https://plus.google.com/u/0/116910304844117268718/posts/5gLAFP4eK9f

    See his most recent comment.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Dec 3, 2011 at 9:05 pm
    Isn't the point of using closure [advanced mode] to optimize the export
    names (known in the old world as global variables)? If it was just a
    question of optimizing local variables, shrinksafe etc. can do it. I
    thought the charm of closure was that it converted every reference to
    "getComputedStyle" into "g7" or something.
    On Sun, Dec 4, 2011 at 10:55 AM, ben hockey wrote:

    i was wondering about that issue myself...

    have you confirmed that this problem is NOT solved? i haven't looked
    at this in depth yet so i don't know if that was even considered.
    however, i would imagine that it might be possible that if you could
    make the closure compiler understand AMD then you might be able to
    make it also realize that the property names for anything exported
    from a module cannot be minified. that's just a wild guess. i think
    if the compiler understood that much about AMD then it should work.
    is that right?

    ben...
    On Dec 3, 2011, at 7:58 PM, Stephen Chung wrote:

    Sorry to disappoint you, but not so fast... Translating AMD code to
    Closure
    modules is only the easy part. The really hard part involves
    automatic
    handling of all property accesses via string names -- and all those
    on("event"...), _setXXXAttr() etc. calls, eliminate/translate-away
    object
    alias usages, as well as converting Dojo-style docs to Closure-style
    JsDoc-variants.

    - Stephen

    -----Original Message-----
    From: Chris Mitchell
    Sent: Saturday, 3 December, 2011 6:25 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Closure Compiler advanced
    optimizations
    with dojo/AMD code

    excellent!

    On Fri, Dec 2, 2011 at 5:14 PM, James Burke <jburke at dojotoolkit.org>
    wrote:
    Malte Ubl has been doing some interesting transforms for AMD and
    commonjs code to allow the use of advanced mode optimizations in
    Closure Compiler on AMD code, and in particular on Dojo:

    https://plus.google.com/u/0/116910304844117268718/posts/5gLAFP4eK9f

    See his most recent comment.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111204/cbd8dc3e/attachment.htm
  • Ben hockey at Dec 3, 2011 at 9:41 pm
    optimizing property names of objects is definitely one big part of
    what advanced mode does. as stephen pointed out, renaming
    "_setFooAttr" to "x" breaks/changes all calls to widget.set('foo',
    xyz) since we expect the setter function to be named "_setFooAttr".
    however, if there are other things to be gained by advanced mode
    (which i understand there is) and we can stop (or work around or fix)
    the property name optimizations then we have a net gain.

    hmm... i just had a thought about my recent compose.js ramblings. i
    think you could make something similar to my DefineProperty work in a
    way that property name optimizations would still work. in fact, rawld
    does something similar in backdraft and to be honest, i should give
    backdraft some credit as inspiration for playing with these ideas.

    what i mentioned previously was this:

    var MyWidget = WidgetBase.extend({
    foo: DefineProperty({
    get: function () {
    return this.foo;
    },
    set: function (value) {
    this.foo = value;
    },
    value: 'xyz'
    })
    });

    changing to the form below would probably be safe with property name
    optimizations since DefineProperty would actually return something like:
    {
    foo: ...
    _setFooAttr: ...
    _getFooAttr: ...
    }

    and the usage would be:

    var MyWidget = WidgetBase.extend(DefineProperty('foo', {
    get: function () {
    return this['foo'];
    },
    set: function (value) {
    this['foo'] = value;
    },
    value: 'xyz'
    }));

    that's certainly a more substantial reason to use that style than just
    syntactic sugar or looking cool. some property names probably still
    need to be quoted but "helper" functions like _setFooAttr don't need
    to be quoted everywhere since they're programatically generated and
    not actually mentioned in the source code.

    ben...

    On Dec 3, 2011, at 9:05 PM, Bill Keese wrote:

    Isn't the point of using closure [advanced mode] to optimize the
    export names (known in the old world as global variables)? If it
    was just a question of optimizing local variables, shrinksafe etc.
    can do it. I thought the charm of closure was that it converted
    every reference to "getComputedStyle" into "g7" or something.

    On Sun, Dec 4, 2011 at 10:55 AM, ben hockey wrote:
    i was wondering about that issue myself...

    have you confirmed that this problem is NOT solved? i haven't looked
    at this in depth yet so i don't know if that was even considered.
    however, i would imagine that it might be possible that if you could
    make the closure compiler understand AMD then you might be able to
    make it also realize that the property names for anything exported
    from a module cannot be minified. that's just a wild guess. i think
    if the compiler understood that much about AMD then it should work.
    is that right?

    ben...
    On Dec 3, 2011, at 7:58 PM, Stephen Chung wrote:

    Sorry to disappoint you, but not so fast... Translating AMD code to
    Closure
    modules is only the easy part. The really hard part involves
    automatic
    handling of all property accesses via string names -- and all those
    on("event"...), _setXXXAttr() etc. calls, eliminate/translate-away
    object
    alias usages, as well as converting Dojo-style docs to Closure-style
    JsDoc-variants.

    - Stephen

    -----Original Message-----
    From: Chris Mitchell
    Sent: Saturday, 3 December, 2011 6:25 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Closure Compiler advanced
    optimizations
    with dojo/AMD code

    excellent!

    On Fri, Dec 2, 2011 at 5:14 PM, James Burke <jburke at dojotoolkit.org>
    wrote:
    Malte Ubl has been doing some interesting transforms for AMD and
    commonjs code to allow the use of advanced mode optimizations in
    Closure Compiler on AMD code, and in particular on Dojo:

    https://plus.google.com/u/0/116910304844117268718/posts/5gLAFP4eK9f

    See his most recent comment.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111203/b5a0a2cb/attachment-0001.htm
  • Bill Keese at Dec 3, 2011 at 10:19 pm
    Nothing is more important than looking cool :-). But yes, that would
    definitely be another good reason to switch to that syntax. And also to
    avoid the string manipulations needed in _WidgetBase.js to go from "foo"
    --> _setFooAttr().

    I'm just confused how DefineProperty() could do inheritance though; let us
    know if you find a solution for that.

    2011/12/4 ben hockey <neonstalwart at gmail.com>
    optimizing property names of objects is definitely one big part of what
    advanced mode does. as stephen pointed out, renaming "_setFooAttr" to "x"
    breaks/changes all calls to widget.set('foo', xyz) since we expect the
    setter function to be named "_setFooAttr". however, if there are other
    things to be gained by advanced mode (which i understand there is) and we
    can stop (or work around or fix) the property name optimizations then we
    have a net gain.

    hmm... i just had a thought about my recent compose.js ramblings. i think
    you could make something similar to my DefineProperty work in a way that
    property name optimizations would still work. in fact, rawld does
    something similar in backdraft and to be honest, i should give backdraft
    some credit as inspiration for playing with these ideas.

    what i mentioned previously was this:

    var MyWidget = WidgetBase.extend({
    foo: DefineProperty({
    get: function () {
    return this.foo;
    },
    set: function (value) {
    this.foo = value;
    },
    value: 'xyz'
    })
    });

    changing to the form below would probably be safe with property name
    optimizations since DefineProperty would actually return something like:
    {
    foo: ...
    _setFooAttr: ...
    _getFooAttr: ...
    }

    and the usage would be:

    var MyWidget = WidgetBase.extend(DefineProperty('foo', {
    get: function () {
    return this['foo'];
    },
    set: function (value) {
    this['foo'] = value;
    },
    value: 'xyz'
    }));

    that's certainly a more substantial reason to use that style than just
    syntactic sugar or looking cool. some property names probably still need
    to be quoted but "helper" functions like _setFooAttr don't need to be
    quoted everywhere since they're programatically generated and not actually
    mentioned in the source code.

    ben...



    On Dec 3, 2011, at 9:05 PM, Bill Keese wrote:

    Isn't the point of using closure [advanced mode] to optimize the export
    names (known in the old world as global variables)? If it was just a
    question of optimizing local variables, shrinksafe etc. can do it. I
    thought the charm of closure was that it converted every reference to
    "getComputedStyle" into "g7" or something.
    On Sun, Dec 4, 2011 at 10:55 AM, ben hockey wrote:

    i was wondering about that issue myself...

    have you confirmed that this problem is NOT solved? i haven't looked
    at this in depth yet so i don't know if that was even considered.
    however, i would imagine that it might be possible that if you could
    make the closure compiler understand AMD then you might be able to
    make it also realize that the property names for anything exported
    from a module cannot be minified. that's just a wild guess. i think
    if the compiler understood that much about AMD then it should work.
    is that right?

    ben...
    On Dec 3, 2011, at 7:58 PM, Stephen Chung wrote:

    Sorry to disappoint you, but not so fast... Translating AMD code to
    Closure
    modules is only the easy part. The really hard part involves
    automatic
    handling of all property accesses via string names -- and all those
    on("event"...), _setXXXAttr() etc. calls, eliminate/translate-away
    object
    alias usages, as well as converting Dojo-style docs to Closure-style
    JsDoc-variants.

    - Stephen

    -----Original Message-----
    From: Chris Mitchell
    Sent: Saturday, 3 December, 2011 6:25 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Closure Compiler advanced
    optimizations
    with dojo/AMD code

    excellent!

    On Fri, Dec 2, 2011 at 5:14 PM, James Burke <jburke at dojotoolkit.org>
    wrote:
    Malte Ubl has been doing some interesting transforms for AMD and
    commonjs code to allow the use of advanced mode optimizations in
    Closure Compiler on AMD code, and in particular on Dojo:

    https://plus.google.com/u/0/116910304844117268718/posts/5gLAFP4eK9f

    See his most recent comment.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111204/6d15ec5d/attachment.htm
  • Stephen Chung at Dec 4, 2011 at 10:16 am
    Hi Ben,

    I have it working for 1.6 ? there is a doc here: http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf

    I?ve put my changed scripts into a Github project: https://github.com/schungx/Dojo-Closure-Advanced

    With this and 1.6, I have some stats with a mobile web app I wrote: about 10-15% faster on iPad, 25% faster on an Android tablet. I was able to eliminate (flatten) the ?dojo?, ?dijit? and ?dojox? objects and the entire sub-trees underneath.

    I suppose it can be done much better with 1.7 since AMD is easier to process than the original dojo.require/dojo.provide/dojo.declare combos, and the new build system will be much better since it can process AST instead of relying on regex?s. I have just started looking at 1.7 now it is out...

    - Stephen


    From: ben hockey
    Sent: Sunday, 4 December, 2011 10:41 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Closure Compiler advanced optimizationswith dojo/AMD code

    optimizing property names of objects is definitely one big part of what advanced mode does. as stephen pointed out, renaming "_setFooAttr" to "x" breaks/changes all calls to widget.set('foo', xyz) since we expect the setter function to be named "_setFooAttr". however, if there are other things to be gained by advanced mode (which i understand there is) and we can stop (or work around or fix) the property name optimizations then we have a net gain.

    hmm... i just had a thought about my recent compose.js ramblings. i think you could make something similar to my DefineProperty work in a way that property name optimizations would still work. in fact, rawld does something similar in backdraft and to be honest, i should give backdraft some credit as inspiration for playing with these ideas.

    what i mentioned previously was this:

    var MyWidget = WidgetBase.extend({
    foo: DefineProperty({
    get: function () {
    return this.foo;
    },
    set: function (value) {
    this.foo = value;
    },
    value: 'xyz'
    })
    });

    changing to the form below would probably be safe with property name optimizations since DefineProperty would actually return something like:
    {
    foo: ...
    _setFooAttr: ...
    _getFooAttr: ...
    }

    and the usage would be:

    var MyWidget = WidgetBase.extend(DefineProperty('foo', {
    get: function () {
    return this['foo'];
    },
    set: function (value) {
    this['foo'] = value;
    },
    value: 'xyz'
    }));

    that's certainly a more substantial reason to use that style than just syntactic sugar or looking cool. some property names probably still need to be quoted but "helper" functions like _setFooAttr don't need to be quoted everywhere since they're programatically generated and not actually mentioned in the source code.

    ben...



    On Dec 3, 2011, at 9:05 PM, Bill Keese wrote:


    Isn't the point of using closure [advanced mode] to optimize the export names (known in the old world as global variables)? If it was just a question of optimizing local variables, shrinksafe etc. can do it. I thought the charm of closure was that it converted every reference to "getComputedStyle" into "g7" or something.

    On Sun, Dec 4, 2011 at 10:55 AM, ben hockey wrote:

    i was wondering about that issue myself...

    have you confirmed that this problem is NOT solved? i haven't looked
    at this in depth yet so i don't know if that was even considered.
    however, i would imagine that it might be possible that if you could
    make the closure compiler understand AMD then you might be able to
    make it also realize that the property names for anything exported
    from a module cannot be minified. that's just a wild guess. i think
    if the compiler understood that much about AMD then it should work.
    is that right?

    ben...

    On Dec 3, 2011, at 7:58 PM, Stephen Chung wrote:

    Sorry to disappoint you, but not so fast... Translating AMD code to
    Closure
    modules is only the easy part. The really hard part involves
    automatic
    handling of all property accesses via string names -- and all those
    on("event"...), _setXXXAttr() etc. calls, eliminate/translate-away
    object
    alias usages, as well as converting Dojo-style docs to Closure-style
    JsDoc-variants. >
    - Stephen >
    -----Original Message-----
    From: Chris Mitchell
    Sent: Saturday, 3 December, 2011 6:25 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Closure Compiler advanced
    optimizations
    with dojo/AMD code >
    excellent!
    >
    On Fri, Dec 2, 2011 at 5:14 PM, James Burke wrote:
    Malte Ubl has been doing some interesting transforms for AMD and
    commonjs code to allow the use of advanced mode optimizations in
    Closure Compiler on AMD code, and in particular on Dojo:
    >>
    >>
    See his most recent comment.
    >>
    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors >
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors




    --------------------------------------------------------------------------------
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111204/0ce3d785/attachment-0001.htm
  • Stephen Chung at Dec 4, 2011 at 10:53 am
    Another $0.02 worth: Your DefineProperty suggestion has the disadvantage of retaining the unmangled properties (as well as the unmangled _getXXXAttr/_setXXXAttr functions) in objects ? that reduces one of the attraction of using the compiler, which is obfuscation. In general, it is best have everything renamed/mangled.

    Also, having one extra level of function to build a prototype (which basically is what dojo.declare and dojo.extend does) prevents the compiler from understanding what the prototype methods are (via the /** @extends */ and /** @lends */ tags), so it cannot virtualize them and remove classes.

    My current working method uses a map object to map mangled to unmangled names (and vice versa) ? it probably also defeats obfuscation, but nevertheless it is much more difficult to reverse-engineer or even find the map object (it is renamed).

    - Stephen

    From: ben hockey
    Sent: Sunday, 4 December, 2011 10:41 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Closure Compiler advanced optimizationswith dojo/AMD code

    optimizing property names of objects is definitely one big part of what advanced mode does. as stephen pointed out, renaming "_setFooAttr" to "x" breaks/changes all calls to widget.set('foo', xyz) since we expect the setter function to be named "_setFooAttr". however, if there are other things to be gained by advanced mode (which i understand there is) and we can stop (or work around or fix) the property name optimizations then we have a net gain.

    hmm... i just had a thought about my recent compose.js ramblings. i think you could make something similar to my DefineProperty work in a way that property name optimizations would still work. in fact, rawld does something similar in backdraft and to be honest, i should give backdraft some credit as inspiration for playing with these ideas.

    what i mentioned previously was this:

    var MyWidget = WidgetBase.extend({
    foo: DefineProperty({
    get: function () {
    return this.foo;
    },
    set: function (value) {
    this.foo = value;
    },
    value: 'xyz'
    })
    });

    changing to the form below would probably be safe with property name optimizations since DefineProperty would actually return something like:
    {
    foo: ...
    _setFooAttr: ...
    _getFooAttr: ...
    }

    and the usage would be:

    var MyWidget = WidgetBase.extend(DefineProperty('foo', {
    get: function () {
    return this['foo'];
    },
    set: function (value) {
    this['foo'] = value;
    },
    value: 'xyz'
    }));

    that's certainly a more substantial reason to use that style than just syntactic sugar or looking cool. some property names probably still need to be quoted but "helper" functions like _setFooAttr don't need to be quoted everywhere since they're programatically generated and not actually mentioned in the source code.

    ben...



    On Dec 3, 2011, at 9:05 PM, Bill Keese wrote:


    Isn't the point of using closure [advanced mode] to optimize the export names (known in the old world as global variables)? If it was just a question of optimizing local variables, shrinksafe etc. can do it. I thought the charm of closure was that it converted every reference to "getComputedStyle" into "g7" or something.

    On Sun, Dec 4, 2011 at 10:55 AM, ben hockey wrote:

    i was wondering about that issue myself...

    have you confirmed that this problem is NOT solved? i haven't looked
    at this in depth yet so i don't know if that was even considered.
    however, i would imagine that it might be possible that if you could
    make the closure compiler understand AMD then you might be able to
    make it also realize that the property names for anything exported
    from a module cannot be minified. that's just a wild guess. i think
    if the compiler understood that much about AMD then it should work.
    is that right?

    ben...

    On Dec 3, 2011, at 7:58 PM, Stephen Chung wrote:

    Sorry to disappoint you, but not so fast... Translating AMD code to
    Closure
    modules is only the easy part. The really hard part involves
    automatic
    handling of all property accesses via string names -- and all those
    on("event"...), _setXXXAttr() etc. calls, eliminate/translate-away
    object
    alias usages, as well as converting Dojo-style docs to Closure-style
    JsDoc-variants. >
    - Stephen >
    -----Original Message-----
    From: Chris Mitchell
    Sent: Saturday, 3 December, 2011 6:25 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Closure Compiler advanced
    optimizations
    with dojo/AMD code >
    excellent!
    >
    On Fri, Dec 2, 2011 at 5:14 PM, James Burke wrote:
    Malte Ubl has been doing some interesting transforms for AMD and
    commonjs code to allow the use of advanced mode optimizations in
    Closure Compiler on AMD code, and in particular on Dojo:
    >>
    >>
    See his most recent comment.
    >>
    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors >
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors




    --------------------------------------------------------------------------------
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111204/1f371106/attachment-0001.htm
  • Stephen Chung at Dec 4, 2011 at 10:26 am
    That?s true. It is not just local variables renaming. For starters, it renames *all* properties and variables. It also does: local variable/argument reuse, dead code removal, function in-lining, constants propagating, namespace chains flattening, prototype virtualization, and syntax/type/constant checking.

    Among them, dead-code removal is probably less of a benefit with 1.7 since it is so modularized (it will be important for a single-file library though). Local variable/argument reuse is arguably a bad thing for modern JIT-ing browsers with type inferences. However, in-lining, constants propagating, namespace flattening and prototype virtualization remain beneficial for performance, although it may not be much these days since most browsers are now really fast...

    - Stephen

    From: Bill Keese
    Sent: Sunday, 4 December, 2011 10:05 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Closure Compiler advanced optimizations with dojo/AMD code

    Isn't the point of using closure [advanced mode] to optimize the export names (known in the old world as global variables)? If it was just a question of optimizing local variables, shrinksafe etc. can do it. I thought the charm of closure was that it converted every reference to "getComputedStyle" into "g7" or something.

    On Sun, Dec 4, 2011 at 10:55 AM, ben hockey wrote:

    i was wondering about that issue myself...

    have you confirmed that this problem is NOT solved? i haven't looked
    at this in depth yet so i don't know if that was even considered.
    however, i would imagine that it might be possible that if you could
    make the closure compiler understand AMD then you might be able to
    make it also realize that the property names for anything exported
    from a module cannot be minified. that's just a wild guess. i think
    if the compiler understood that much about AMD then it should work.
    is that right?

    ben...

    On Dec 3, 2011, at 7:58 PM, Stephen Chung wrote:

    Sorry to disappoint you, but not so fast... Translating AMD code to
    Closure
    modules is only the easy part. The really hard part involves
    automatic
    handling of all property accesses via string names -- and all those
    on("event"...), _setXXXAttr() etc. calls, eliminate/translate-away
    object
    alias usages, as well as converting Dojo-style docs to Closure-style
    JsDoc-variants. >
    - Stephen >
    -----Original Message-----
    From: Chris Mitchell
    Sent: Saturday, 3 December, 2011 6:25 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Closure Compiler advanced
    optimizations
    with dojo/AMD code >
    excellent!
    >
    On Fri, Dec 2, 2011 at 5:14 PM, James Burke wrote:
    Malte Ubl has been doing some interesting transforms for AMD and
    commonjs code to allow the use of advanced mode optimizations in
    Closure Compiler on AMD code, and in particular on Dojo:
    >>
    >>
    See his most recent comment.
    >>
    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors >
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors




    --------------------------------------------------------------------------------
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111204/6403daec/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedDec 2, '11 at 5:14p
activeDec 4, '11 at 10:53a
posts10
users5
websitedojotoolkit.org

People

Translate

site design / logo © 2021 Grokbase