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.
> 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.
This kind of reminds me of dojo (minus the good build system). It is very much a jack of all trades, master of none. There are too many good libraries out there to tie yourself down to one monolithic framework. Have fun building your dojo project in browserify, webpack, r.js, or any other build system. You miss out on good promise libraries, good UI libraries like React, Polymer, etc. Instead you get a promise library that is not A+ compliant, and the shit that is dijit._Widget. Don't forget you are now tied down to dojo declare's class system (which they are abandoning in dojo2).
Try building Google Speadsheets with jQuery... Closure is serious software for building complex apps like Google Docs: for example it allows to download and import external modules on demand (e.g. on user interaction).
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...
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.
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)
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.
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.
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
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.
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.
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
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'.
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". :)
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)
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.
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.
> 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.
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.
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 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.
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.
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.
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.
> 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.
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.
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.
