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.
Five Years of Google Closure
11–20 of 37 posts
Re: Five Years of Google Closure
#12The 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.
Re: Five Years of Google Closure
#13Heh - I initially thought from the title it would be about Google's constant shuttering of their services once people had discovered them and started using them...
Re: Five Years of Google Closure
#14Somehow 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.
Re: Five Years of Google Closure
#15The 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...
Re: Five Years of Google Closure
#16> 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…
Angular is also a Google library.
[deleted]
Re: Five Years of Google Closure
#17I 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…
> 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.
Re: Five Years of Google Closure
#18We 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
Re: Five Years of Google Closure
#19My 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.
Re: Five Years of Google Closure
#20Tangentially, 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...