Have a look at the advanced compilation option: https://developers.google.com/closure/compiler/docs/api-tuto...

Basically when enabled it will rewrite normal property access, e.g: `myObj.foo` to something like `a.b` but wont shorten string literal access, e.g `myObj['foo']` just becomes `a.foo` which you would use for any API's you want to export.

For a real-world example I use string literals for declaring jquip's public API:

    p['removeAttr'] = function(name){
        return this['each'](function(){
          if (this.nodeType == 1) this.removeAttribute(name);
        });
    };

Which closure advanced rewrites to:

    q.removeAttr=function(a){return this.each(function(){this.removeAttribute(a)})};

Original: https://github.com/mythz/jquip/blob/master/dist/jquip.all.js

Compiled: https://github.com/mythz/jquip/blob/master/dist/jquip.all.cl...

How did it know it could leave out the `this.nodeType` check?

If it can prove that it will always be 1 (ie by code not shown) it will be removed.

Yeah, I was curious how it could prove that in this specific case. Very neat, in any case.

May i ask why you are using this notation? I honestly can't think of any benefits. Isn't it more convenient and readable to use `p.removeAttr`?

My comment explains the entire purpose for using it - if I didn't, it would've got rewritten into `a.b` and none of the public API's would work!

I wish there were a better way to indicate which properties were renameable, because I need this too and I'm not willing to go as far as you did.

You can tell it which properties to keep with `goog.exportSymbol()`

there is a much better way to deal with this:

https://developers.google.com/closure/compiler/docs/api-tuto...

Thanks - I remember seeing that when looking through the docs, but I don't really like that either, unfortunately. I'm using Uglify right now, and I was thinking of adding a pre-minify step that walks the AST for a JSDoc-style annotation on either the properties themselves or a containing object, and pulls out the list of property names to preserve that way.

You have to restrict your code to a certain style (and there are warnings for whenever you're defeating the DCE, I believe). You'll particularly see this when you're accessing properties via array-index-like lookup (your myObj['f'+'oo']) example) instead of e.g. myObj.foo under advanced compilation, where the property name will have been munged and doesn't exist.

Like anything else, there are tradeoffs, and Closure asks that you restrict yourself to a more predictable set of patterns in return for the benefits it offers.

They explain it here: https://developers.google.com/closure/compiler/docs/limitati...

You tell the compiler a file that it's not allowed to dead-strip. From there, it then computes the transitive closure of the rest of your code that is referenced from the "entry point", and removes everything else. It is, of course, possible to reference things in indirect ways that the compiler can't see, so they provide some mechanisms to force inclusion if necessary.

This kind of indirection is specifically not supported even with simple optimizations: https://developers.google.com/closure/compiler/docs/limitati...

You have to follow a set of rules - your example would not be allowed.

One of the nice things about ClojureScript is that the compiler will output compatible code, so you don't even really have to think about it (except when doing JS interop). If you write valid ClojureScript, it Just Works.

    function add(a,b) { return a+b }
    console.log(add(1,2))

Compiles to

    console.log(3)

I'm not sure about your example, but I think it would work. (Apparently not)