from Hacker News

Google Closure: How not to write JavaScript

by rams on 12/13/10, 4:56 AM with 47 comments

by gruseom on 12/13/10, 6:50 AM

The article says:

  Although it is necessary in Java, it is entirely pointless to
  specify the length of an array ahead of time in JavaScript. [...]
  Rather, you can just set up an empty array and allow it to grow as
  you fill it in. Not only is the code shorter, but it runs faster too.

Faster? That ought to raise suspicion. JS's dynamic hash-arrays are neat, but now they're supposed to be immune from the laws that govern memory allocation in any other language?

As it happens, I had occasion to test this a few months ago.

  function preallocate(len) {
      var arr = new Array(len);
      for (var n = 0; n < len; n += 1) {
          arr[n] = n;
      };
      return arr;
  }

  function noPreallocate(len) {
      var arr = [];
      for (var n = 0; n < len; n += 1) {
          arr[n] = n;
      };
      return arr;
  }

On my machine, noPreallocate is 4% faster in FF, but it's 15% slower in IE8 and a whopping 70% slower in Chrome.

by jrockway on 12/13/10, 5:32 AM
My feeling is that even the compilers written in CS101 will optimize this. I'm guessing that Google tested their code with V8, performance was fine, and they thought nothing of it.
I just did a benchmark with node.js. I made a 50000000 element array, and timed how long each way took.
Trial one:
```
    for( var i = 0; i < array.length; i++ ) { array[i]++ }
```
That took, on average, 0.93001866 seconds.
Trial two:
```
    for( var i = 0; i < len; i++ ) { array[i]++ }
```
That took, on average, 0.809920 seconds.
A lot of stressing-out over what ends up being a rounding error.
by aboodman on 12/13/10, 5:56 AM
Time in web applications is not used looking up array lengths - it's used in IO, layout, and DOM manipulation. If iterating through arrays was found to ever be a noticeable issue in practice, the Closure compiler could just be modified to emit more efficient code. That's one of the advantages of having the compiler - you don't have to make a convenience/readability trade.
Closure was not thrown together by novices new to the language. It was started by Erik Arvidsson and Dan Pupius, two JS hackers that have been doing this kind of work longer than just about anyone else. Its differences from other libraries aren't the result of ignorance, they're mostly the result of conscious tradeoffs to make compilation more effective.
Edit: Oh, and the string thing... If you ever do
```
  new String("foo")
```
in JavaScript, you're doing it wrong.
by axod on 12/13/10, 10:26 AM
> "...was that people would switch from truly excellent JavaScript libraries like jQuery to Closure on the strength of the Google name."
This is ridiculous. Does not the mere fact that jquery keep announcing 4000% speedups with every new release not tell you something about the efficiency of jquery?
Unbelievably biased. If you looked at the jquery code you'd find the same sort of things, and some far worse.
From jquery release notes:
```
  ... coming in almost 30x faster than our previous solution
  ... coming in about 49% faster than our previous engine
  ... much, much faster (about 6x faster overall)
  ... Seeing an almost 3x jump in performance
  ... improved the performance of jQuery about 2x compared
     to jQuery 1.4.1 and about 3x compared to jQuery 1.3.2
  ... Event Handling is 103% Faster
  ... jQuery.map() method is now 866% faster
  ... .css() is 25% faster
```
Maybe it's just me, but when someone says they've speeded up their code so it runs 30 times as fast, you have to really wonder just how badly it was written to start with, and how badly it's still written.
by ivank on 12/13/10, 5:15 AM
Previously http://news.ycombinator.com/item?id=937175
If you're building a large JavaScript application, Closure might be your best option given that Closure Compiler (in ADVANCED mode) produces small obfuscated output files that contain only the functions your program uses. ADVANCED mode restricts how you write your JavaScript (but not onerously), but that's where Closure Library comes in: a 1 million LOC "standard library" already annotated for Compiler.
I've found working with Closure Library/Compiler enjoyable, typically more than Python, because the Compiler's type system finds plenty of bugs as I work. It has even caught bugs in my Python code (after I ported it to JavaScript, of course).
There's also good book out there for Closure: http://www.amazon.com/dp/1449381871/
by julius on 12/13/10, 9:09 AM
Closure is one of the most intuitive libraries I have used, ever.
I use Closure for everything, which is too big for jQuery. Compared to its next best competitor YUI, it's a joy (eg. first really good cross-browser richtext editor).
I have not found many features, not already included in the library.
Code can be easily scaled, and is fast enough. Especially on the production system, where you, thanks to the Closure compiler, can have a compiled version (I also prefer the compiler over YUI's).
Have I told you about the excellent testing framework...
Have I told you about the excellent documentation...
Have I told you about its very readable code...
When it was released, and I had read some of its code, I knew I wanted to use this at my work as soon as possible. But exactly this Blogpost had a super high google rank for the query "Google Closure".
If you, too, run into the problem of your co-workers reading that post, just link to the HN-Comments. Worked for me. Here is the older HN-Link: http://news.ycombinator.com/item?id=937175
by jws on 12/13/10, 3:44 PM
Example 1: Slow Loop
The author claims writing:
```
  for (var i = fromIndex; i < arr.length; i++) {
```
…is slow and can be much faster as…
```
  for (var i = fromIndex, ii = arr.length; i < ii; i++) {
```
Speed aside, this introduces a bug if the length of the array changes in the body of the loop, but ignoring this booby trap I ran benchmarks on the original clear version and the slightly more complicated fragile version.
```
                        clear     fragile
  empty loop body         5ms         1ms
  single number add       7ms         6ms
  single DOM lookup      82ms        81ms
```
That is for an array of a million elements on an iMac running Safari. (Apparently Safari is particularly good at doing nothing, but otherwise this "optimization" is lost in the loop body's time.)
Edit: I checked Chrome on Linux as well. It was also unimpressive.
by kls on 12/13/10, 5:17 AM
You know while raw speed is an important piece of a library, it is not the only thing, there are other factors that carry just as much weight when it comes to importance. 3rd party library ecosystem, community support, integration with other technologies, ease of use and a host of other are all just as important factors when I evaluate a library.
As well, IIRC Closure was an internal project that was built to build apps like Gmail, if that is the case then it, is reasonable to think that it has some cruft in their given that the state of the art in Javascript libraries came after Gmail, Oulook on the web, and other Browser based apps showed what was possible.
It was programmer transitioning from other languages to JavaScript that built these first toolkits and they brought over a good deal of their language constructs that they where familiar with as time went on other programmer from other disciplines joined in and some of the frameworks started to morph.
I remember when Dojo threw away their entire toolkit because of this and I commend them for doing so. They came to realize that their was a better way than just reimplementing Java or C# in the browser.
Closure on the other hand remained an internal project outside those learning. That being said, I do think their are much better frameworks available than Closure, Dojo and jQuery being two prime examples, but I do cut them some slack based on the fact that they would possible qualify as one of the oldest frameworks and that they did not benefit from the learning the communities went through as the state of the art evolved.
by oomkiller on 12/13/10, 5:59 AM
Note, this was written over a year ago, so stuff may have changed since then. It would probably be worth taking a look to see how things have improved.
by mfukar on 12/13/10, 6:54 AM
Why are we (and by we, I mean the article author) getting worked up about what should be a single, or maybe more, bug reports?
It'd be a lot more interesting if you could use those conclusions to find out who wrote those parts of the code.
by _ques on 12/13/10, 5:45 AM
This article is over a year old.
by abraham on 12/14/10, 6:01 AM
I wish the code snippets were linked to the loc. http://code.google.com/p/closure-library/source/browse/trunk...
by kwamenum86 on 12/13/10, 6:26 AM
"I’m not sure what this pattern is called in Java, but in JavaScript it’s called a ‘memory leak’."
The comment is in regards to goog.memoize but is terribly backwards. The complaint about goog.memoize is that it will grow uncontrollably because it does not cap the size of the caching object. A memory leak is the inability of a program to free memory it has allocated.
Since js is garbage collected causing a memory leak involves creating a circular reference fooling the garbage collector into thinking that an object is still in use.