Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Closure Compiler: a tool for making JavaScript download and run faster

developers.google.com

Post reply on HN
Print view View original

61–70 of 77 posts

Re: Closure Compiler: a tool for making JavaScript download and run faster

#61

Post by cromwellian »

thomasfoster96 wrote: post #55
cromwellian wrote: post #47

Earlier quoted context omitted.

I don't see why the language the tool is written in matters. Lots of NPM modules have native C dependencies and it works fine. Closure advanced mode will do a lot better than 5% compared with Uglify.

It shouldn't matter - but it does. Native dependencies are pretty important so a lot of effort has gone into solving that issue - but I don't think making Java and Node.js work together well is a high priority for anyone. That said, closure being in JavaScript has more to do with choosing rhino than anything else. If you were starting a project like closure today you wouldn't use Java. Re: advanced mode, totally depe…

Actually if it was started at Google today, it probably would use Java or Go. Very few development tools are written in JS at Google. Angular and Polymer (and maybe Traceur) build tools being the exception. Our internal tooling works far better with statically typed languages.

It should be rather trivial to have a gulp/grunt task that installs Java and runs CC. CC could even be packaged as a EXE if desired.

Re: Closure Compiler: a tool for making JavaScript download and run faster

#62

Post by dang »

dahart wrote: post #4

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…

> The title of this submission omits the best part

We reverted the submitted title ("Closure Compiler parses JavaScript, removes dead code, minimizes what's left"). Submitters: please don't use the titles of HN stories to editorialize. If you want to say what you think is important about an article, please do so in the thread, where all commenters are equal.

Re: Closure Compiler: a tool for making JavaScript download and run faster

#63

Post by Kiro »

abritinthebay wrote: post #53
cromwellian wrote: post #50

Earlier quoted context omitted.

100k lines? You think that's a large project? The closure library itself has 500kloc. 10-20% is a huge difference. On an 1M JS app, that would be an extra 100-200k of JS downloaded. That will seriously increase latency, especially for those in developing countries.

No, I don't. That was my point. I wish I had only 100kloc to deal with. I have 3.6 million to deal with. Different scale entirely.

May I ask what kind of project you work on?

Re: Closure Compiler: a tool for making JavaScript download and run faster

#64

Post by swannodette »

abritinthebay wrote: post #38

Having used both this an Uglify... I can't recommend this. It's slow. Like... really slow to build. Uglify takes ~10seconds on my code whereas CC took around 10 minutes. Plus the performance benefits - while real - provides very little useful speedup that the V8/whoever JIT won't do anyhow. Even in tight loops. It's VERY cool, but will add minutes to your deploy/compile time for very little practical benefit. If you'…

I'm very curious how you're coming up with your Uglify performance claims on this thread for a near 4MLOC JS codebase. I just tried Uglify on 6mb of ClojureScript generated JavaScript (it's nowhere near 4MLOC) and it takes nearly ~34 seconds on 3.5ghz iMac. That's 3 times slower then your 10 second claim for your own code base which sounds orders of magnitude larger!

3-4X slower than Uglify I could believe, but saying Closure is 60X slower and claiming compression performance I cannot even reproduce with a code base that's 40-50X smaller. What???

Re: Closure Compiler: a tool for making JavaScript download and run faster

#65

Post by hokkos »

cromwellian wrote: post #47
thomasfoster96 wrote: post #37

Earlier quoted context omitted.

Well all those build tools are usually npm packages, and are easily managed as dependencies using package.json (hence why there are so many being used). Adding Java and and a secondary set of dependencies isn't really worth the 5% decrease in minified file size that closure might give you. I did try to use closure instead of uglify in a project recently - closure was a real pain to deal with compared to tools with eq…

I don't see why the language the tool is written in matters. Lots of NPM modules have native C dependencies and it works fine. Closure advanced mode will do a lot better than 5% compared with Uglify.

It works fine because node take care of compiling it and lot of packages in npm need it so you are practically forced to install a C / C++ compiler, but java here is almost alone, so the requirement is more painfull.

Re: Closure Compiler: a tool for making JavaScript download and run faster

#66

Post by masklinn »

chrisoakman wrote: post #45
masklinn wrote: post #33

Earlier quoted context omitted.

Because really taking advantage of it (enabling advanced compilation options) requires using a fairly specific subset of the language otherwise it will DCE half the project. Integration with "regular" javascript libraries can also be annoying. ClojureScript uses Closure as an optimisation backend, since the primary cljs compiler is already in java.

FYI - I'm fairly certain that CLJS does not use Google Closure because it is "already in java", but rather because of it's maturity and awesome features like DCE. https://github.com/clojure/clojurescript/wiki/Rationale#goog...

This and that are not exclusive. There are good reasons to use closure, but would integrating closure and the tooling it requires even have been considered had the cljs compiler been in anything but java?

How many alt.js languages implemented in !java use closure?

Re: Closure Compiler: a tool for making JavaScript download and run faster

#67

Post by fixermark »

abritinthebay wrote: post #59
fixermark wrote: post #57

Earlier quoted context omitted.

> If you're doing a ton of data processing on the client (WHY??)... ... because that's the future. https://cloud.google.com/solutions/angularjs-cloud-endpoints...

er... that's not in the client. That's in the cloud. ie - on servers. That's just a fancy way of distributing data across services. It's not client-side processing of the data: it's server side.

Read it more closely; the document I linked is specifically about pushing functionality into the client.

"MVC frameworks, such as AngularJS, have been developed that enable client-side developers to build powerful and compelling UIs."

"This paper provides best practices and guidance to web developers who are interested in AngularJS or other client-side MVC technologies and want to optimize their server backend for these technologies."

"The growing popularity of client-side MVC frameworks such as Backbone.js and AngularJS is representative of this shift to the client. These frameworks help reduce complexity and increase reuse in even the simplest of applications... As the UI moves to the client, the server becomes simpler."

Re: Closure Compiler: a tool for making JavaScript download and run faster

#68

Post by sanderjd »

tomjen3 wrote: post #39
sanderjd wrote: post #25

Earlier quoted context omitted.

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.

Re: Closure Compiler: a tool for making JavaScript download and run faster

#69

Post by abritinthebay »

Kiro wrote: post #63
abritinthebay wrote: post #53

Earlier quoted context omitted.

No, I don't. That was my point. I wish I had only 100kloc to deal with. I have 3.6 million to deal with. Different scale entirely.

May I ask what kind of project you work on?

A large media organization.

Re: Closure Compiler: a tool for making JavaScript download and run faster

#70

Post by abritinthebay »

fixermark wrote: post #67
abritinthebay wrote: post #59

Earlier quoted context omitted.

er... that's not in the client. That's in the cloud. ie - on servers. That's just a fancy way of distributing data across services. It's not client-side processing of the data: it's server side.

Read it more closely; the document I linked is specifically about pushing functionality into the client. "MVC frameworks, such as AngularJS, have been developed that enable client-side developers to build powerful and compelling UIs." "This paper provides best practices and guidance to web developers who are interested in AngularJS or other client-side MVC technologies and want to optimize their server backend for th…

Yes, I'm quite aware of what Angular, Backbone, etc do. I'm also quite aware of what MVC is thankyouverymuch.

But I was specifically referring to data processing on the client and while those frameworks obviously can do that the page you linked describes where they farm it out to other cloud services.

This is obviously faster than doing it on the client.. and is exactly what I was talking about.

The future you linked to is the exact opposite of doing data processing on the client. So why you'd call client-side data processing the future with that link as evidence I don't know.

... unless you don't actually understand what "client side" means I guess. Client Initiated Processing !== Clint Side Processing.

Post reply on HN