Live data from Hacker News

Five Years of Google Closure

derekslager.com

31–37 of 37 posts

Re: Five Years of Google Closure

#31
Reasons I don't care for Closure (currently using it in a production project):

1) Depends on both Java and Python. Ugh 2) It's big, and has to be setup anywhere you are doing builds (i.e. continuous deployment) 3) Hard to setup, understand, compose tasks (none of that is impossible to figure out, just harder than many of the alternatives)

The article made a minor mistake about Angular - Google is using Angular in over 1,400 internal and production apps (I know, the article just mentioned production, but the number should signify how all-in on Angular Google really is). Oh, and fun side point - they are using the master branch version of Angular (1.x) - the Angular team needs to run not only all of their Angular tests, but also all of the tests for all of the projects that use Angular to ensure they didn't cause any regressions.

Overall, Closure is that library you really want to love, but it just rubs you the wrong way over and over again until you decide it isn't for you. (in my experience)

Re: Five Years of Google Closure

#32
post #7

Earlier quoted context omitted.

But in those 5 years industry passed it by and now Google is crippled by legacy technology. Compare to Guava Java, which also powers Google, is open source, and is still best in class today after many years

Well, the same thing happened to many of the more open, hype-laden technologies. JQuery and Angular are both also obsolete, and the new hotness is React, with Google trying to get in on the action again with Polymer but so far uptake seems limited. I also wouldn't say "crippled" - I worked with Closure on both Google Search and Google Plus, and while I certainly wouldn't use it for a startup, it's much better than al…

I would take you to task on the statement that jQuery and Angular are obsolete already. That is an in-the-bubble statement, and nothing to do with what people are really using across our industry.

Re: Five Years of Google Closure

#33
post #3

> If the measure of success for a JavaScript framework is popularity, Google Closure has failed miserably. It's old, unsexy, and has missed its turn on the hype train. Google spends no effort on PR for the library, and seems content with it quietly powering the majority of its flagship applications. And given that, the lack of hype has mattered very little to us, as it's been a very good solution to our problems over…

Has Angular operated in a more open fashion than Closure did?

Angular is entirely open-source, all of the meeting notes are public (maybe the meetings also, not sure). They actively engage and welcome community participation.

Re: Five Years of Google Closure

#34
post #23
post #21

Am I the only one who is seriously annoyed by the naming of this library? I mean if I work at Google and create a C library, should I name it 'Google Pointer'? or a C++ library called 'Google Inheritance'? maybe a Haskell library called 'Google Monad'. Aaaargh!

And imagine the outrage that would result if you had the audacity to commandeer the technical term "chrome" by naming your web browser "Google Chrome". :)

I thought Chrome was the OS.....

Using the same name for two distinct products does not end well. I think we would have all learned from the .NET naming at Microsoft, where suddenly everything was .Net (Office .net etc etc etc)

Re: Five Years of Google Closure

#35

Tangentially, in case someone else is curious, Google's Inbox doesn't use closure, it uses gwt and j2obc [1]. Probably due to the ability to use java code on android, IOS and the web. [1] http://gmailblog.blogspot.ru/2014/11/going-under-hood-of-inb...

Inbox does use Closure. That blog post just talks about the data model using GWT to cross compile to many platforms. There's Closure in there and some other frameworks too.

Think of Closure like the JDK, it's robust and expansive, but not very opinionated and sometimes ugly. So you put frameworks on top that are sugary.

Post reply on HN