The ability to remove unused code at compile time means you have access to a very large, full-featured library, but only have to include the parts you need. You can do something similar with a custom JQuery or YUI build, but not nearly to the same level, and with the same granularity that the closure compiler does automatically.
Unfortunately, to take full advantage of the compiler you must run with advanced optimizations turned on, which in turn means that your code has to be structured for use with the compiler. You're not going to take an existing codebase and just throw it into the compiler with advanced optimizations and have it work out for you.
But if you start a project with the closure library and the closure compiler, you can get some pretty amazing optimizations. We were seeing relatively full-featured apps at compiled, uncompressed sizes of under 10k. Full sites well under 100k with a lot of javascript is completely doable.
Couple that with the dynamically-loading module system and you've got a crazy fast front end.
To top it all off, the compiler respects and can warn about type mismatching if you annotate your code. It's a great way to both document and check your codebase.
The closure library and closure compiler are warty enough that I don't think they'll see widespread adoption the way that JQuery has, but the closure tools, or something like them, is definitely the way forward.
Twitter does not, I don't know about flow. Most people are using one of the non-closure libraries that only work with closure's "simple" optimizations, and running one of those through the closure compiler on "simple" doesn't get you much that one of the other minifiers could do, and the other minifiers are easier to use.
I'd like to see a library that is more approachable and internally consistent than the Closure Library, I think something like that coupled with plovr, (a build tool that wraps some of the craziness of the closure compiler in a much nicer package) would be a killer next-gen js framework.
I think that's really where we're headed, all this complaining about whether you should use a big library or build a big custom library is really just a symptom of the tools being sort of crap.
Comments
This is why the closure compiler is so essential.
The ability to remove unused code at compile time means you have access to a very large, full-featured library, but only have to include the parts you need. You can do something similar with a custom JQuery or YUI build, but not nearly to the same level, and with the same granularity that the closure compiler does automatically.
Unfortunately, to take full advantage of the compiler you must run with advanced optimizations turned on, which in turn means that your code has to be structured for use with the compiler. You're not going to take an existing codebase and just throw it into the compiler with advanced optimizations and have it work out for you.
But if you start a project with the closure library and the closure compiler, you can get some pretty amazing optimizations. We were seeing relatively full-featured apps at compiled, uncompressed sizes of under 10k. Full sites well under 100k with a lot of javascript is completely doable.
Couple that with the dynamically-loading module system and you've got a crazy fast front end.
To top it all off, the compiler respects and can warn about type mismatching if you annotate your code. It's a great way to both document and check your codebase.
The closure library and closure compiler are warty enough that I don't think they'll see widespread adoption the way that JQuery has, but the closure tools, or something like them, is definitely the way forward.
I'd be curious to know if Flow or Twitter or big webapps take advantage of this.
Twitter does not, I don't know about flow. Most people are using one of the non-closure libraries that only work with closure's "simple" optimizations, and running one of those through the closure compiler on "simple" doesn't get you much that one of the other minifiers could do, and the other minifiers are easier to use.
I'd like to see a library that is more approachable and internally consistent than the Closure Library, I think something like that coupled with plovr, (a build tool that wraps some of the craziness of the closure compiler in a much nicer package) would be a killer next-gen js framework.
I think that's really where we're headed, all this complaining about whether you should use a big library or build a big custom library is really just a symptom of the tools being sort of crap.