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

Google Closure: How not to write JavaScript

blogs.sitepoint.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: Google Closure: How not to write JavaScript

#31

Post by axod »

gruseom wrote: post #21

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…

http://axod.net/arraytest.html

  After 20 iterations:

  Browser               Pre-alloc    No pre-alloc
  Firefox 3.6.13 OSX       824ms         829ms
  Safari 5.0.3 OSX         812ms         948ms
  Chrome 9.0.597.16 OSX    1317ms        992ms
I'm pretty sure that in modern browsers new Array(length) doesn't allocate anything, it just sets the length property. The results I'm seeing would agree with Google really.

Perhaps you were seeing GC events slowing down the test?

The other thing about for(var i=0;i

  for (var i=0;i

Re: Google Closure: How not to write JavaScript

#32

Post by axod »

> "...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.

Re: Google Closure: How not to write JavaScript

#33

Post by mnemonik »

gruseom wrote: post #21

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…

It is times like this that jsperf.com comes in handy. We can see the aggregated results of everyone who runs the test, browser by browser.

http://jsperf.com/allocating-array-length

Re: Google Closure: How not to write JavaScript

#34

Post by Seth_Kriticos »

gruseom wrote: post #21

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…

Agree, the author is detailing a lot of arcane specifics of JS that are probably valid in a very small subset of browsers, let's see what he writes:

"Perhaps the most important thing these libraries do is make sophisticated vector graphics possible in Internet Explorer, where JavaScript performance is relatively poor."

Well, yes. Sure, suit yourself, but I think that most modern browsers come with something called a JS code profiler/optimizer and JIT code (FF new JS engine and Chrome surely do, others probably too).

Not to mention that Closure comes with it's own code optimizer that does this for the border cases.

For sanities sake, please don't start to preach that we should do the work of a compiler and bend the code in that direction. Humans are bad at that, and it makes the code unmaintainable.

There are some valid points in the article though, I admit, some pitfalls that might screw up when multiple JS frameworks are running (namespace issues) mostly.

Re: Google Closure: How not to write JavaScript

#35

Post by mileszs »

wladimir wrote: post #26
araneae wrote: post #17

Earlier quoted context omitted.

True, but as someone who has a java background and is working on js, it's nice to know that switches suck in js :)

Reading the article, it seems hard to find anything that does not suck (or at least, is not counter-intuitive) in JS. So many trivialities have to be taken into account. - You have to store the array length in advance before a loop? wtf? - "for in" loops are inherently dangerous. wtf? Every language has pitfalls but javascript seems king above even C++...

> - "for in" loops are inherently dangerous. wtf?

No. "for-in" loops that iterate through the properties of an object, and do something with them, without checking to ensure that the property is specific to that object, as opposed to something another library added to the Object.prototype, are dangerous.

The article did a poor job in that section of pointing out _what_ exactly is dangerous. It's not _every_ for-in loop. It's that one in particular, really.

Re: Google Closure: How not to write JavaScript

#36

Post by nswanberg »

julius wrote: post #27

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 c…

At what point do you decide something is too big for jQuery? Lines of code? Number of developers? Certain features needed?

Does it make sense to begin with jQuery and switch at a certain time?

Re: Google Closure: How not to write JavaScript

#37

Post by brunoc »

axod wrote: post #32

> "...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 jque…

These improvements have occurred over time, as browsers gain new features and new techniques are discovered. They (the jQuery contributors) focus on the features and optimize what can be optimized when there is a need.

The optimized solution is often much uglier than the simple but less efficient one.

Re: Google Closure: How not to write JavaScript

#38

Post by brunoc »

mileszs wrote: post #35
wladimir wrote: post #26

Earlier quoted context omitted.

Reading the article, it seems hard to find anything that does not suck (or at least, is not counter-intuitive) in JS. So many trivialities have to be taken into account. - You have to store the array length in advance before a loop? wtf? - "for in" loops are inherently dangerous. wtf? Every language has pitfalls but javascript seems king above even C++...

> - "for in" loops are inherently dangerous. wtf? No. "for-in" loops that iterate through the properties of an object, and do something with them, without checking to ensure that the property is specific to that object, as opposed to something another library added to the Object.prototype, are dangerous. The article did a poor job in that section of pointing out _what_ exactly is dangerous. It's not _every_ for-in lo…

Most people using for..in in Javascript as beginners really want to use Array.forEach

Re: Google Closure: How not to write JavaScript

#39

Post by bajsejohannes »

jrockway wrote: post #4

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 That took, on average, 0.93001866 seconds. Trial two: for( var i = 0; i That took, on average, 0.809920 se…

> My feeling is that even the compilers written in CS101 will optimize this.

Then it might be harder than you think. You can't know that array.length won't change during the course of the loop. Even in your simple example, I would say it takes a fair bit of analysis (not for a human, of course), to be certain that "array[i]++" won't add elements to the list.

Re: Google Closure: How not to write JavaScript

#40

Post by jws »

Example 1: Slow Loop

The author claims writing:

  for (var i = fromIndex; i
…is slow and can be much faster as…

  for (var i = fromIndex, ii = arr.length; 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.

Post reply on HN