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.
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...
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)
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.
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.
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
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.
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.
- 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
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!
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)
[1] http://gmailblog.blogspot.ru/2014/11/going-under-hood-of-inb...
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.
[1] https://github.com/google/end-to-end/tree/master/src/javascr...
Must be me misreading the title as some American expression.
The article was quite different!
>
> 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.
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.
