Five Years of Google Closure
derekslager.com
Five Years of Google Closure
1–10 of 37 posts
Re: Five Years of Google Closure
#2Clicked 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.
Re: Five Years of Google Closure
#3> 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.
Re: Five Years of Google Closure
#4> 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…
Has Angular operated in a more open fashion than Closure did?
Re: Five Years of Google Closure
#5> 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.
Re: Five Years of Google Closure
#6> 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…
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.
Re: Five Years of Google Closure
#7> 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…
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
Re: Five Years of Google Closure
#8I 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.
Re: Five Years of Google Closure
#9I'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.
Re: Five Years of Google Closure
#10Earlier quoted context omitted.
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.