11–20 of 77 posts
How can it determine dead code for such a dynamic language like JavaScript? Is it limited to obvious stuff like things after a "return;" statement that cannot run? Because I don't see how it could remove unused functions when you can invoke them in such indirect ways: myobj['f'+'oo']();
function add(a,b) { return a+b }
console.log(add(1,2))
console.log(3)
How can it determine dead code for such a dynamic language like JavaScript? Is it limited to obvious stuff like things after a "return;" statement that cannot run? Because I don't see how it could remove unused functions when you can invoke them in such indirect ways: myobj['f'+'oo']();
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);
});
};
q.removeAttr=function(a){return this.each(function(){this.removeAttribute(a)})};
Compiled: https://github.com/mythz/jquip/blob/master/dist/jquip.all.cl...
The title of this submission omits the best part; closure provides static type checking. That is more valuable to me than the dead code removal & minification. I just discovered an amazing and nearly undocumented feature of the Closure Compiler: the --module flag. One of the most inconvenient parts of using closure is having to compile each page separately. That's what the Closure docs say to do: https://developers.g…
I think it's likely that long-term, the approach FB took with Flow (or more general Abstract Interpretation methods) should be able to handle more cases with less effort on the developer's side (albeit with increased computational costs). The modules/"code motion" is a bit strange at first glance, but definitely a huge boon for building debuggers/admin interfaces/etc. that you don't want included in your main applica…
How can it determine dead code for such a dynamic language like JavaScript? Is it limited to obvious stuff like things after a "return;" statement that cannot run? Because I don't see how it could remove unused functions when you can invoke them in such indirect ways: myobj['f'+'oo']();
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 p…
I keep trying to use closure on my projects but it doesn't compile jQuery to working code. I always get errors after concatenating and using it on my sources and this always just brings me back to uglify.
I'm using Visual Studio for the backend, in case it matters.
I keep trying to use closure on my projects but it doesn't compile jQuery to working code. I always get errors after concatenating and using it on my sources and this always just brings me back to uglify.
The title of this submission omits the best part; closure provides static type checking. That is more valuable to me than the dead code removal & minification. I just discovered an amazing and nearly undocumented feature of the Closure Compiler: the --module flag. One of the most inconvenient parts of using closure is having to compile each page separately. That's what the Closure docs say to do: https://developers.g…
In ClojureScript there is a attempted going to make Closure Compiler Modules work with other modules: https://github.com/clojure/clojurescript/wiki/Google-Summer-...