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

1–10 of 51 posts

Re: Google Closure: How not to write JavaScript

#2

Post by ivank »

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/

Re: Google Closure: How not to write JavaScript

#3

Post by kls »

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.

Re: Google Closure: How not to write JavaScript

#4

Post by jrockway »

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

A lot of stressing-out over what ends up being a rounding error.

Re: Google Closure: How not to write JavaScript

#5

Post by pinchyfingers »

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 Closure library, but I guess I'll stick with jQuery.

Re: Google Closure: How not to write JavaScript

#7

Post by _ques »

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…

Gmail is hand coded, not Closure.

Re: Google Closure: How not to write JavaScript

#9

Post by ivank »

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

Gmail is hand coded, not Closure.

The Gmail team uses Closure Library/Templates/Compiler.

Re: Google Closure: How not to write JavaScript

#10

Post by aboodman »

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.
Post reply on HN