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.
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.<p>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):<p>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)<p>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.<p>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.<p>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.<p>Once other teams started using TypeScript, we had to hack the plovr server to make it serve up map and ts files.<p>Our whole project failed, so we got to start over with TypeScript.<p>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!<p>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.<p>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.<p>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.<p>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.<p>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.<p>It is unfortunate that it isn't used more widely.<p>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.<p>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.<p>[1] <a href="http://oinksoft.com/closure-tools/irc/" rel="nofollow">http://oinksoft.com/closure-tools/irc/</a><p>[2] <a href="http://oinksoft.com/closure-tools/sgdg-jul14/" rel="nofollow">http://oinksoft.com/closure-tools/sgdg-jul14/</a>
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.)<p>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.<p>I'd like to see a broader level of coverage and a change in our culture so we embrace more choices.<p>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.<p>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:<p>- 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?<p>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'.<p>Aaaargh!
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.<p>[1] <a href="http://gmailblog.blogspot.ru/2014/11/going-under-hood-of-inbox.html" rel="nofollow">http://gmailblog.blogspot.ru/2014/11/going-under-hood-of-inb...</a>
The most complete example of a project using Closure library I can find is the end-to-end project[1].<p>[1] <a href="https://github.com/google/end-to-end/tree/master/src/javascript/crypto/e2e" rel="nofollow">https://github.com/google/end-to-end/tree/master/src/javascr...</a>
I thought this was about taking 5 years to recover from working at Google and getting "closure".<p>Must be me misreading the title as some American expression.<p>The article was quite different!
> 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.<p>><p>> 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.<p>And that is the cost of operating in a secretive, closed fashion as Google does.
Clicked on this article hoping for closure on Google issues that lasted for 5 wholes years.<p>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."<p>Was severely disappointed. Google, the type of closure you provide is not the type I need.