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

41–50 of 51 posts

Re: Google Closure: How not to write JavaScript

#41

Post by RyanDScott »

nswanberg wrote: post #36
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?

Reasons you might consider using Closure instead of something like jQuery, plain-old-js:

1. Your javascript file is getting huge and you want to break things out into manageable pieces.

2. You find yourself needing namespaces that are easy to implement.

3. You want to learn how to build structured javascript (Closure is great at encouraging well documented, "object-oriented" coding)

4. You've got too many js files (2+) and you want to only have one in production for faster page loading (use closure compiler)

5. You're building an application with a team of developers; closure helps create modular, well documented code

6. You want to build a snappy, client-side heavy application

Before I ever used Closure, I used javascript more like frosting on a cake. Javascript can be frosting, but it can also do some amazing things. My biggest complaint with javascript in the past has been it's unwieldy nature in medium to large projects. I stuck to using javascript/jQuery to decorate html pages and had the page generation, business logic, templating, etc., on the server side (Python). Then I wrote a medium sized application in closure, and it worked, and it's maintainable, and it didn't require a lot of server side code, and it was fast.

I couldn't be happier.

My only complaint is it seems Closure development doesn't have the velocity that other projects like GWT have. Google, it seems, is putting it's money more on GWT than something like closure; or so it seems based on the amount of announcements for GWT, the quality of the tools and libraries being produced, the number of updates to closure compared to GWT. While GWT is a powerful tool, it's more complex (thanks to Java), harder to setup, harder to get started. In some ways I wish they would take the tools and frameworks they have for GWT and build them for Closure.

Re: Google Closure: How not to write JavaScript

#42

Post by amattie »

nickik wrote: post #30
pinchyfingers wrote: post #5

Earlier quoted context omitted.

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.

http://closuretools.blogspot.com/2010/06/closure-library-tec...

Re: Google Closure: How not to write JavaScript

#43

Post by gruseom »

axod wrote: post #31
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 t…

Perhaps you were seeing GC events slowing down the test?

Perhaps. Or perhaps it varies by array size?

Re: Google Closure: How not to write JavaScript

#44

Post by bluekeybox »

axod wrote: post #31
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 t…

Then do not write code like this.

Re: Google Closure: How not to write JavaScript

#45

Post by bluekeybox »

aboodman wrote: post #10

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

> Time in web applications is not used looking up array lengths - it's used in IO, layout, and DOM manipulation.

Unless you're implementing a cross-browser stable sorting algorithm for manipulating tables 50,000 rows long or longer (that was exactly my most recent project). Don't say "it should be done on the server" because that statement is true only as long as everybody keeps writing bad Javascript.

Re: Google Closure: How not to write JavaScript

#46

Post by btipling »

shazow wrote: post #12
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…

A rounding error that causes a fast-paced Javascript game to crawl to a laggy stutter when repeated all over the place. Regardless, the Closure Compiler (that the Closure Library is made to be used for) fixes this common case. Another example where it's more than a rounding error: http://stackoverflow.com/questions/2573212/why-is-setting-ht...

That stackoverflow article points to http://www.onaluf.org/en/entry/13

which explains the issue is a lot more complicated then just a property lookup.

Re: Google Closure: How not to write JavaScript

#47

Post by kwamenum86 »

jrockway wrote: post #19
kwamenum86 wrote: post #15

Earlier quoted context omitted.

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

How many 50 million element arrays do you have? My guess is that this makes no difference in real life. Should you write clean code that performs well? Yes. But should you be fixated on a tiny bug in Google's library? Nope. Send patch, get .0000000001 seconds per element back, and move on.

It's not about a single 50mil element array. It's about sub-optimal code running in a bunch of places and it adds up. But in any case this probably won't be the bottleneck.

Still I am a fan of running the most optimal code possible on the server. Absolutely no reason not to.

Client-side js is different. Often times algorithmic optimizations have no impact (unless we are talking about animation.)

I would not trust people who do not respect optimizations like these to run code on my server.

Re: Google Closure: How not to write JavaScript

#48

Post by kwamenum86 »

ivank wrote: post #18
kwamenum86 wrote: post #13

"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 lea…

> A memory leak is the inability of a program to free memory it has allocated. Unexpected memoization/caching also counts as a memory leak. There are (unfortunately) a few places in Closure Library where unexpected memoization might cause a memory leak. > 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 us…

Are you saying that the memory allocated by the memoizer is not recoverable e.g. won't be released until the browser is killed? If not then it is not a memory leak.

Re: Google Closure: How not to write JavaScript

#50

Post by ivank »

kwamenum86 wrote: post #48
ivank wrote: post #18

Earlier quoted context omitted.

> A memory leak is the inability of a program to free memory it has allocated. Unexpected memoization/caching also counts as a memory leak. There are (unfortunately) a few places in Closure Library where unexpected memoization might cause a memory leak. > 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 us…

Are you saying that the memory allocated by the memoizer is not recoverable e.g. won't be released until the browser is killed? If not then it is not a memory leak.

It's potentially recoverable, but stuck in some "private" object your JavaScript application will never bother to look at. It's still a memory leak.
Post reply on HN