21–30 of 37 posts
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!
Earlier quoted context omitted.
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 al…
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'. Aaaargh!
Earlier quoted context omitted.
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 al…
Can you give some more information on why Closure is better than React for large teams and why Closure wouldn't be good for a startup?
- 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 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…
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. [1] http://gmailblog.blogspot.ru/2014/11/going-under-hood-of-inb...
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…
Earlier quoted context omitted.
Can you give some more information on why Closure is better than React for large teams and why Closure wouldn't be good for a startup?
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 re…
Earlier quoted context omitted.
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 re…
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.
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.