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

21–30 of 51 posts

Re: Google Closure: How not to write JavaScript

#21

Post by gruseom »

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
On my machine, noPreallocate is 4% faster in FF, but it's 15% slower in IE8 and a whopping 70% slower in Chrome.

Re: Google Closure: How not to write JavaScript

#22

Post by mfukar »

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.

Re: Google Closure: How not to write JavaScript

#24

Post by matt2224 »

kwamenum86 wrote: post #15
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…

For js running in a browser this does not matter but on a server this will make a huge difference.

Bahahhaaa, because we all use our servers to process 50 million element arrays.

Re: Google Closure: How not to write JavaScript

#25

Post by kls »

pinchyfingers wrote: post #5
kls wrote: post #3

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

There is a TechTalk about Closure where the speaker makes a big deal out of the whole project being done by many different developers in their twenty percent time, so yeah, they might get cut some slack and hopefully they'll be good about accepting patches to get some of these things fixed. Gmail works pretty well, so the library can't be too horrible. I'm glad I read this, I was thinking of doing a project using the…

I was thinking of doing a project using the Closure library, but I guess I'll stick with jQuery

Might I suggest taking a look at Dojo as well, depending on your requirements, Dojo is really good at it's target. Which is large browser based apps. I use jQuery extensively for the smaller problem sets, but their is no substitute for Dojo when you start getting into large browser apps. Dojo provides the full stack for browser app developers and would be similar to Closure in the segment that it targets. It's worth s look to see if you like it, further it can be used in conjunction with jQuery they are not incompatible and play very well together.

Re: Google Closure: How not to write JavaScript

#26

Post by wladimir »

araneae wrote: post #17
_ques wrote: post #8

This article is over a year old.

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

Re: Google Closure: How not to write JavaScript

#27

Post by julius »

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

Re: Google Closure: How not to write JavaScript

#28

Post by rbanffy »

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

Closure comes with a compiler/optimizer/minifier that will do all sorts of optimizations to your code. I am not sure if this is one of them, but I would not be surprised if the library code is optimized for readability and they let the compiler do its tricks to optimize it for speed.

Re: Google Closure: How not to write JavaScript

#29

Post by rbanffy »

gruseom wrote: post #20
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 :)

I would be very careful (i.e. run my own tests, in multiple browsers) before believing that.

Or, like my college teachers told me, "measure, don't guess".

I am a bit ashamed to confess I do a lot of guessing in my work...

Re: Google Closure: How not to write JavaScript

#30

Post by nickik »

pinchyfingers wrote: post #5
kls wrote: post #3

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

There is a TechTalk about Closure where the speaker makes a big deal out of the whole project being done by many different developers in their twenty percent time, so yeah, they might get cut some slack and hopefully they'll be good about accepting patches to get some of these things fixed. Gmail works pretty well, so the library can't be too horrible. I'm glad I read this, I was thinking of doing a project using the…

Can you post the link to that TechTalk? I cant find it.
Post reply on HN