
Five Years of Google Closure - derek
http://derekslager.com/blog/posts/2015/06/five-years-of-google-closure.ashx
======
taylorhughes
I worked with Closure for a couple of years. It's great, but it has none of
the characteristics that tend to make a library popular. It does almost
nothing sexy. It's hard to set it up. Feature-for-feature comparisons to more
accessible libraries (jQuery+plugins) are unconvincing. It's also verbose and
kinda ugly, which folks tend to get hung up on. The various libraries are also
very thorough, well-tested, etc., and the build system is amazing -- but
that's not stuff that sells.

~~~
libria
> Feature-for-feature comparisons to more accessible libraries
> (jQuery+plugins) are unconvincing.

The attractive part of Closure was that it had extremely robust, unit-tested
counterparts to jQuery's plugins and the reliability of it was never in
question. For a while, their URL parser was superior to anything in the jQuery
ecosystem. By contrast, jQuery plugins have many different authors with widely
variant degrees of quality.

Part of the verbosity is due to its type system, but it was one of the few
client-side tools I used where my code had a high chance of running well once
I satisfied the compiler. I notice React's Flow and TypeScript are realizing
the benefits of better type checking which Closure has had for ages.

------
jfaucett
The closure compiler itself is amazing, I feel like if that and the whole
compile/build process had been the only focus of the google closure tools
project it would have been a much larger success than it was/is.

I read through parts of the source and used bits and pieces of ideas at
various points, even built toy apps with the toolchain, but for me, when using
the libraries I always felt like I was programming in java, which might be
endearing to some, but I didn't find it such an enjoyable experience and just
went on my way after a while using only the compiler. IMHO javascript is all
about its functional nature its where all the elegance, simplicity, and
modularity comes from, I found it kind of placed on a backburner in the
closure libs, but could just be me...

------
fnordsensei
Truly an vastly underated piece of software. In using ClojureScript, I
thankfully don't have to understand it very well in order to get the benefits
of using it.

------
LocalPCGuy
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)

------
euroclydon
My team used this library extensively for years. I thought the best part was
the dependency resolution through goog.require and goog.provide, but by far
the worst part was the type annotations!! They made me think about my types,
which was great, but having to write them is just old-school. Every code
review was littered with type annotation corrections. The tooling, starting
with the Python scripts was painful, though plovr did make it better.

Then there's Advance Compilation, a potentially great feature, but if you
don't enable it from day one, you'll have a hell of a time ever enabling it
later, especially under pressure to deliver.

Once other teams started using TypeScript, we had to hack the plovr server to
make it serve up map and ts files.

Our whole project failed, so we got to start over with TypeScript.

My advice: don't use it! If you want type safety and dependency management for
large teams, use TypeScript.

------
EdSharkey
I'm just starting a greenfield application development, and I tried and failed
to bend my mind around Google Closure Compiler so that I could incorporate it
into my build. Instead, I am using UglifyJS2 for my minification. UglifyJS is
very good, but the function inlining that Closure Compiler can perform is what
I am really after. (Closure Compiler is a real optimizing compiler!) I'd use
lodash everywhere without guilt!

For my builds, I am using Webpack, (but the same goes for Browserify), Closure
Compiler was not designed to play nice with other bundlers - it wants to be
its own complete ecosystem that is focused on Google internal needs/wants.

I want to write my code as CommonJS modules, and I want plugins that can
attach at different stages of my build system. For example, I want to be able
to traceur --> lint --> closure compile --> karma test w/ coverage report -->
bundle+source maps. Plugins and Loaders in Webpack can be scripted to do this
kind of build and that's what makes large-scale JavaScript development
possible. Closure Compiler currently has some half-baked CommonJS support.
Even so, it does not seem possible to plug it into a bundler build system,
given what command line options it has available.

If there was magically a closure-compiler-webpack-plugin package tomorrow that
I could install into Webpack, I would be first in line to build with Closure
Compiler and with Advanced Optimizations always turned on.

Closure Compiler might be 5 years old, but make no mistake, it is unique and
awesome compiler tech! I just wish it was a priority for Google to see it
widely used in contemporary JS development outside of Google and apart from
the Closure library.

If I have caught the interest of any Googlers reading this, I'd also ask that
Closure Compiler support JSDoc3 annotations. Not that I am bitterly opposed
Closure Compiler JSDoc annotations, I'd just like to see standardization on
the JSDoc3 set of annotations which I think are pretty expressive and
understandable and grokked by many other tools out there.

------
stringham
We use Google Closure at Lucid Software for Lucidchart and Lucidpress. It has
been a great tool for us, especially for sharing code across a huge javascript
codebase. Compile time type checking and dead code removal have also been
great.

It is unfortunate that it isn't used more widely.

It's nice that you can see some of Google's open source projects built using
closure

------
oinksoft
The Closure Library definitely has its bright spots, and it was my library of
choice for many years. For all its warts, I particularly like the design of
goog.ui. goog.editor is a wonderful part of the library too. I still run
##closure-tools on Freenode[1] but nowadays we might get a question or two a
month, at most, which is definitely a sign of the times ... there was brief
uptick in activity when ClojureScript first became popular.

When developing software for evergreen browsers, or not needing to target old
IE in general, the cross-browser reliability and performance the library
provides is less important. I was lucky to get to pick a prominent Closure
Library developer's brain about this last year, and he expressed a similar
opinion. I agree with the author of this post in that ClojureScript has
breathed new life into the Closure Tools, and gave a presentation last year
that touched on this with some code examples showing the brevity CLJS
allows[2], but it seems that Closure Library's ship has mostly sailed.

[1] [http://oinksoft.com/closure-tools/irc/](http://oinksoft.com/closure-
tools/irc/)

[2] [http://oinksoft.com/closure-tools/sgdg-
jul14/](http://oinksoft.com/closure-tools/sgdg-jul14/)

------
MCRed
Somehow I had never heard of Google Closure. This reminds me a lot of Apple's
WebObjects. When I used it, in the late 1990s and early 2000s, it was by far
the best web platform out there... and I think in a lot of ways it still is.
(If it had remained Objective-C based and gone open sourced I would still be
using it today.)

I think there is a bit of a problem in "engineer culture" where there is a
tendency to fixate on a particular technology even when it's not the most
appropriate for particular use cases. There are certainly use cases where
MongoDB and Node.js are the best choices, but those cases are much narrower
(particularly in the case of Mongo) then I think the community recognizes and
they start being adopted as general purpose tools appropriate for all use
cases.

I'd like to see a broader level of coverage and a change in our culture so we
embrace more choices.

While WebObjects is powering iTunes and the AppStore still today... and
Apple's even gone further and built javascript based platforms (Sproutcore was
largely an Apple product) they no longer are putting the effort in they did
with webobjects.

For isntance, with web objects you had interface builder- that allowed you to
build web pages/sites much the way you build iOS apps using it now, and it was
just as powerful, resulting in rapid development without the WYSIWYG issues of
other tools. The lack of adoption by the community, though, means Apple only
does this work in house for its in house users now. It just wasn't popular
enough to support the work on Xcode and IB that was required.

------
milos_cohagen
Would love to see Google Closure compiler features combined with Webpack
features. I want to easily:

\- write ES2015 \- compile with dead code elimination, static type checking
etc, but super fast like webpack \- include npm modules easily \- include
assets using something as simple as webpack's loader

------
fizixer
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!

~~~
kibwen
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". :)

~~~
72deluxe
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)

------
kristianp
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...](http://gmailblog.blogspot.ru/2014/11/going-under-hood-of-inbox.html)

~~~
esprehn
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.

------
foxwoods
The most complete example of a project using Closure library I can find is the
end-to-end project[1].

[1] [https://github.com/google/end-to-
end/tree/master/src/javascr...](https://github.com/google/end-to-
end/tree/master/src/javascript/crypto/e2e)

------
72deluxe
I thought this was about taking 5 years to recover from working at Google and
getting "closure".

Must be me misreading the title as some American expression.

The article was quite different!

------
mcherm
> 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 the past five years.

>

> That's not to say that adoption doesn't matter. The absence of a rich
> community around Google Closure has been disappointing. Only a single book
> on Google Closure has been published, and the surrounding tools have been
> slow to evolve. Contrast this with Angular, which has achieved off-the-
> charts hype and has developed a massive community despite minimal usage in
> production Google applications. Many books and countless blog posts have
> been authored explaining various patterns and concepts, making it much
> easier to get started.

And that is the cost of operating in a secretive, closed fashion as Google
does.

~~~
nostrademons
Sometimes that's exactly what you want, though. If you're deriving a
competitive advantage from a tool, it's often to your advantage for as few
people to know about it as possible. That's why Google kept it secret and
internal-only for the first 5 years of its existence, and only open-sourced it
once the hype train had moved on to other technologies.

~~~
reagency
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

~~~
nostrademons
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 all of JQuery/Angular/React for
a 50+ person team.

Guava is in a much different position. As a fundamental class library, it's
much more deeply embedded in your code than a front-end framework, and so
switching costs are much higher. You could also argue that Java as a whole is
"crippling legacy technology", with newer apps being written in Go, Node.js,
Ruby, Python, and hopefully soon Rust.

~~~
OmarIsmail
Can you give some more information on why Closure is better than React for
large teams and why Closure wouldn't be good for a startup?

~~~
nostrademons
Closure is much more tightly typed and namespaced, it has a larger library of
pre-built components, it bans (via compiler warnings) practices that are hard
to maintain, and it errs toward verboseness. All of these improve the
readability of code at the expense of its writability. In a large established
organization, you read code much more than you write it. In a startup, you
write it much more frequently than you read it.

~~~
hokkos
The react world has flow that does the same type checking, for the bundling
webpack is now superior, and warning is handled by eslint, and with babel for
ES6, and PostCSS for css next I don't think there is a lot of reasons to use
the closure tools apart for the components.

~~~
pbowyer
> flow that does the same type checking, for the bundling webpack is now
> superior, and warning is handled by eslint, and with babel for ES6, and
> PostCSS for css next > I don't think there is a lot of reasons to use the
> closure tools apart for the components.

The fact that your list is that long is a good reason. Using best-of-class
libraries is brilliant (and I'd like to all the time), but using good-enough
libraries that are well tested with each other and unlikely with new releases
to change behaviour in ways that will create edge-cases or interop problems:
that is pragmatic.

Plus the reduction in developer-rabbit-holes when every developer tries to
include its own favourite (Webpack! Browserify!), the consistent
documentation, and the ease of setup.

Not to say you're wrong, but I feel people overlook the benefit brought by
well-developed monolithic frameworks.

------
rilita
Clicked on this article hoping for closure on Google issues that lasted for 5
wholes years.

Thought to myself "Now that is something I can related to. Having issues with
Google for years on end and wanting closure. Maybe I can get some closure too
by reading this article."

Was severely disappointed. Google, the type of closure you provide is not the
type I need.

