4 ms·
An enormous amount of the shavings and inlining that the Closure compiler is capable of assumes that you write your code according to rules that reduce ambiguit
by straws 10y ago
An enormous amount of the shavings and inlining that the Closure compiler is capable of assumes that you write your code according to rules that reduce ambiguity and dynamic features in your code. Variable names get mangled, so things like using string names for properties is out the window, which means invoking methods by string names is out as well. It uses objects for namespaces so things like `Shape.Quad.Square` get renamed to `Shape$Quad$Square` before getting minified to some one-letter variable, so don't use `this` outside of constructors or prototype methods.
There's a larger list of restrictions at https://developers.google.com/closure/compiler/docs/limitations https://developers.google.com/closure/compiler/docs/limitati...
If you do write code obeying these rules (check out the closure library), or you use something like ClojureScript that generates straightforward, monomorphic, closure-compiler-compatible js, the payoff in both file size and parse/execution performance is pretty great.
- lobster_johnson 10y agoClosure Compiler was indeed written to target Google's very specific rules on how to structure code and name stuff. However, Closure still does a better job than Uglify and other minifiers even if you don't do this. Its basic set of optimizations are generic and won't break code (unless you enable the advanced mode, which has been historically iffy). The only downside is that it's slow. Like really slow. It takes about a minute to minify our app. Edit: Looks like Uglify has gotten better lately. I'll submit a separate top-level comment.
- draw_down 10y agoSeems like a lot of gotchas... you could end up shaving a couple K off your bundle in exchange for bugs that are very hard to track down. I mean, sure, if you write your code ground-up to follow a set of rules it's probably great.