Closure Compiler: a tool for making JavaScript download and run faster
developers.google.com
Closure Compiler: a tool for making JavaScript download and run faster
1–10 of 77 posts
Re: Closure Compiler: a tool for making JavaScript download and run faster
#2How 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']();
Re: Closure Compiler: a tool for making JavaScript download and run faster
#3How 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']();
They explain it here: https://developers.google.com/closure/compiler/docs/limitati...
Re: Closure Compiler: a tool for making JavaScript download and run faster
#4The 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.google.com/closure/compiler/docs/api-tuto...
That means if you have 10 pages, you have 10 compile passes, even if 95% of your code is shared. But, it turns out you can run a compile pass and output multiple compiled .js files simultaneously! This has cut my build times by 10x.
So, anyone with long build times due to multiple separate builds, poke around and find out how to use --module!
Re: Closure Compiler: a tool for making JavaScript download and run faster
#5How 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']();
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.
Re: Closure Compiler: a tool for making JavaScript download and run faster
#6How 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']();
This kind of indirection is specifically not supported even with simple optimizations: https://developers.google.com/closure/compiler/docs/limitati...
Re: Closure Compiler: a tool for making JavaScript download and run faster
#7The 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-...
Re: Closure Compiler: a tool for making JavaScript download and run faster
#8The 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 application. David Nolen wrote about this earlier this year when support started landing in ClojureScript http://swannodette.github.io/2015/04/07/in-stillness-movemen...
Edit: wrt Flow, specifically referring to FB's approach to retrofitting type-checking into a largely dynamic language. Thanks to swannodette for pointing out the ambiguity.
Re: Closure Compiler: a tool for making JavaScript download and run faster
#9How 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']();
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.
Re: Closure Compiler: a tool for making JavaScript download and run faster
#10How 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']();
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.