[HN Gopher] Google Closure Library has been archived
___________________________________________________________________
Google Closure Library has been archived
Author : benatkin
Score : 169 points
Date : 2024-08-29 22:22 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| seanw444 wrote:
| An older version of their README says:
|
| > Closure Library is a powerful, low-level JavaScript library
| designed for building complex and scalable web applications. It
| is used by many Google web applications, such as Google Search,
| Gmail, Google Docs, Google+, Google Maps, and others.
|
| I wonder if they still use it in all those services, or if they
| migrated to something else.
| dullcrisp wrote:
| They still use it in all those services.
| spankalee wrote:
| Not really. Those projects now use JsLayout, Wiz, and a
| couple of other more modern libraries.
|
| There may be some Closure widgets on very old, barely
| maintained, pages, but they'll be fine. Closure library is
| still in the Google monorepo, it's just not going to be
| copied to GitHub anymore.
| esprehn wrote:
| While folks don't really use Closure Components anymore,
| the library is huge and both Wiz and JsLayout (and Fava)
| are built on Closure.
| nateglims wrote:
| Notably not the Closure Compiler
|
| https://github.com/google/closure-compiler
| threemux wrote:
| Whew thanks - was worried there for a second!
| dannyobrien wrote:
| Note that this doesn't include the Closure Compiler[0], and
| doesn't affect Clojurescript[1], which has traditionally used the
| compiler and related bits of the Google Closure library.
|
| [0] https://github.com/google/closure-library/issues/1214
|
| [1] https://clojurescript.org/news/2024-01-24-release
| sabbaticaldev wrote:
| it does affect clojurescript, if they don't have a plan to
| remove it they will get in big trouble later
| lolinder wrote:
| Can you clarify what you mean for someone unfamiliar? If
| Closure Compiler is sticking around (and the linked issue is
| very clear that it will), what is it that ClojureScript needs
| to have a plan to remove?
| zeroclicks wrote:
| Are you sure about that? The clojurescript implementation is
| built on top of the google closure library. Here's an example:
| https://github.com/clojure/clojurescript/blob/master/src/mai...
| swannodette wrote:
| The implementation really is not built on top of GCL, the
| bulk of the standard library is persistent datastructure
| implementation and functional apis. The few cases here and
| there like `goog.string` can be removed over time. But really
| what's the rush? Large portions of GCL have worked unchanged
| for nearly two decades. Does Google archiving GCL make
| perfectly good code stop working?
|
| When we eventually remove the direct GCL dependency it will
| sadly be more for optics than anything else.
| zeroclicks wrote:
| Right. Some of that "goog" code looks decent enough. I
| wouldn't remove it either simply because it was "archived".
| Maybe vendor the useful stuff back into the implementation
| and remove all the "goog"?
| rty32 wrote:
| Closure Compiler is half dead anyway, doesn't even support
| public/private class fields etc from ES2022. I wouldn't be
| surprised if its gets abandoned within 1-2 years
| ComputerGuru wrote:
| It is indeed, and the reason is because Google is switching
| to wasm.
| BaculumMeumEst wrote:
| Countdown to "Hey what is this Closure Compiler project? Why
| are we paying to maintain this again?"
| corentin88 wrote:
| It was announced a few months ago:
| https://github.com/google/closure-library/issues/1214
| jdminhbg wrote:
| Closure is two separate projects, the Compiler and the Library,
| and this is the Library that's being archived. Might be good to
| note that in title, if @dang or another mod is around.
| benatkin wrote:
| I'm here and I made the update. I think it will have an effect
| on both and I considered putting library in the title but
| decided to have a shorter title, however by popular demand I
| changed it.
|
| Edit: looked at the closure compiler repo and maybe it's good,
| though I always thought of it as partly depending on the
| library...
|
| Edit 2: This explains the situation. Sounds like Closure
| Compiler has a bright future! I could see ClojureScript
| eventually taking over maintenance though.
| https://news.ycombinator.com/item?id=41396522
| notfed wrote:
| I don't even know what this library is (quite an ungooglable
| name), but I don't get it. It's open source licensed. Why not
| just, like, not "close" it? Just keep the code and the docs up.
| jdminhbg wrote:
| Archiving it is exactly what you're asking for. The code and
| docs stick around, and there's a big banner at the top noting
| that it's not being maintained anymore.
| paxys wrote:
| Which is...exactly what they did.
| xiaodai wrote:
| Closure. What a fitting name.
| ssttoo wrote:
| I remember disliking google's project names of that era. Too
| generic and borrow-y. Closure was a concept in JavaScript.
| Chrome is what Firefox was calling the parts around the
| rendered page (UI buttons, etc)
| kagevf wrote:
| Not to mention "Go" ...
| ssttoo wrote:
| Ah, and the +1 button (instead of Like) in Google+ was
| appropriated from message board chats
| jdougan wrote:
| At least the Go people were smart enough to refer to it as
| "golang" right from the start.
| croes wrote:
| You mean like MS does?
|
| Windows, Teams etc.
|
| Not to mention the teams in Teams.
|
| Or Musk's rebranding of Twitter to X.
|
| Seems after flattening the logos they flat names too.
|
| Generic and hard to distinguish.
| immibis wrote:
| At least Microsoft's names are more descriptive than
| average. Microsoft Windows is an OS all about Windows;
| Microsoft Teams is a collaboration thing. And the whole
| company is called "microcomputer software". Microsoft
| Visual Studio is where you paint and sketch...
|
| But yes, we've had flat names and flat icons for ages. It
| seems there's more supply of entrepreneurship than demand,
| so you can't call your thing what it does, because five
| other people already did that and you want _your_ product
| to stand out. Hacker News is called Hacker News, but now
| that name 's taken, so the next news for hackers will be
| called something like Newshack if you're lucky, or
| something like Marigold or Kallipo if you're not.
| (Actually, Slashdot was named before Hacker News).
| Recognizable companies may have an advantage, because they
| can call the product by their company name + what it does.
| oersted wrote:
| > Microsoft Visual Studio is where you paint and sketch
|
| It's a code IDE, there's very little visual about it.
| It's a legacy name relating to Visual Basic, I believe it
| started as a code editor tightly integrated with a visual
| native UI editor.
| djbusby wrote:
| Visual Studio 6 had all that - c1998
| koito17 wrote:
| GCL, the _Google Closure Library_ was sunset and this was
| announced almost a year ago on the mailing lists. The archiving
| was scheduled for 2024-08-01.
|
| GCC, the _Google Closure Compiler_ , is still used by Google
| internally and they are shifting towards supporting the compiler
| for tools that emit "ClosureJS" (remember goog.define and
| goog.provide?). ClojureScript is one of several tools that target
| "ClosureJS" and there is not much to fear.
|
| ClojureScript has always distributed GCC and GCL as date-
| versioned JARs since there is no formal release process of either
| component outside of Google. The GCL code "just works" for the
| most part and is frozen in time. GCL became unnecessary for two
| reasons. 1. GCL existed at a time when JavaScript
| had no notion of a module system whatsoever (not even CommonJS).
| It was very tedious to import third-party code. So GCL was
| designed as a kitchensink that'd work across browsers.
| 2. Many parts of the GCL kitchensink became unnecessary as the
| JavaScript standard library gained equivalent functionality and
| browsers standardized.
|
| For instance, goog.net.BrowserChannel predates WebSockets and has
| lots of hacks so it works reliably on various versions of
| Internet Explorer. There has realistically been no need to use
| goog.net.BrowserChannel over WebSocket for almost a decade now.
|
| Another example: goog.crypt methods (base64,
| encodeStringToByteArray, etc.) are now provided by the JavaScript
| standard library
|
| Yet another example: all of the functionality in the goog.async
| package (besides Debouncer) is provided by the JavaScript
| standard library through Promise.
|
| Then there's other things that existed purely for browser
| compatibility, like goog.net.XhrIo (an XHR wrapper that isn't
| needed unless you care about IE5 quirks). Almost everybody, even
| in ClojureScript, uses fetch nowadays.
|
| There's more examples, but look around for yourself and you will
| see that almost everything in the library can be served by modern
| JavaScript and a few NPM packages.
| https://google.github.io/closure-library/api/
| benatkin wrote:
| I updated the title but perhaps you could summarize the
| situation and submit closure compiler to HN and that story
| could take off and paint a more accurate picture of the
| situation? Maybe there's a blog post that explains it more
| fully? It sounds quite promising, actually.
| dietrichepp wrote:
| I've used the Google Closure Compiler for some JS13K projects,
| since it is so effective at producing small JavaScript code. At
| the time (a few years ago), there were some rough edges trying
| to use the Closure Compiler without the Closure Library, but
| they weren't major problems--in fact, there was only one thing
| I added to my project as a workaround: const
| goog = { define(name, value) { return value; } };
|
| That was it. I used it to select between development and
| release versions of the project, because the release version
| had to fit in 13 KB (compressed).
| lupire wrote:
| Oh, GCL and GCC, not the other GCL and GCC
| esprehn wrote:
| Even more confusing: inside Google they call the compiler
| JSC, unrelated to the JS engine in WebKit.
| outside1234 wrote:
| Wow, crazy this still existed. Hasn't been modern for a LONG
| time.
| FelipeCortez wrote:
| by definition?
| nicksantos wrote:
| Closure Library was originally designed based on the lessons
| learned from building Gmail in 2004/2005-ish. When it was
| archived, one of its founders wrote a great thread about how much
| the JavaScript ecosystem has changed in the last 20 years. It's
| been a wild ride!
|
| https://www.threads.net/@dpup/post/C2QsW5QsSPW/?xmt=AQGzV4jb...
| MisterKent wrote:
| Has anyone outside of Google had any luck using the closure
| compiler with a modern-ish stack with the advanced optimizations?
|
| Tsickle and the like seem to be archived as well, so it's unclear
| to me. Google must internally have some tooling to go from ts to
| closureJS?
| esprehn wrote:
| They archived the open source parts , but it's the same stack
| internally.
| MisterKent wrote:
| So they just stopped sharing it publicly? That's kinda odd.
| cpcallen wrote:
| Doing open source releases takes engineering time, and the
| internal tooling teams are amongst those that have been hit
| by layoffs[1], so keeping GitHub up to date is probably not
| a big priority for them.
|
| [1]: https://techcrunch.com/2024/05/01/google-lays-off-
| staff-from...
| thayne wrote:
| tsickle doesn't look archived to me:
| https://github.com/angular/tsickle
|
| Lucid Software migrated their code from closure compiler JS to
| typescript, and continue to use the closure compiler with
| advanced optimizations. See https://lucid.co/techblog/2017/11/1
| 6/converting-600k-lines-t....
|
| It would not at all surprise me if google internally has better
| tooling than what they have open sourced though.
| MisterKent wrote:
| Did you not see the readme in that repo? It's no longer being
| maintained, with the last commit being years ago.
|
| I imagine it's lacking a lot of typescripts newer features
| etc. seems hard to justify using it
| AshleysBrain wrote:
| We relied on Closure Compiler for years, but we're now moving
| off it to ESBuild + UglifyJS. Closure has the most advanced
| minification, but these days it's not well maintained - it's
| lacking support for modern JavaScript features like dynamic
| imports and private fields, it's not clear when or if any of
| that will be supported, releases have reduced to every ~6
| months, and all too often if you file a bug the response is
| "this doesn't affect Google, tough luck". So unfortunately
| despite having the best minification I can't recommend it any
| more - it's basically a Google-internal project that happens to
| be on GitHub. UglifyJS looks like a better option these days.
| no_wizard wrote:
| You should consider terser over uglifyJS, it's far better
| maintained and will get you the same if not better results
| adrianh wrote:
| Yes, I've used Closure Compiler with advanced optimizations for
| the Soundslice JS codebase, for around 10 years.
|
| It is so, so good!
|
| You have to take care to write code in a certain way, but once
| you understand the constrants it's not a big deal. The advanced
| optimizations are better than anything else I've seen in the JS
| world, and it's not even close. It's just insanely good.
| kccqzy wrote:
| A long time ago when I was a full-stack developer, my opinion
| was that the Closure compiler with its advanced optimizations
| was so worthwhile that I was willing to change my code style to
| make it work. That includes not using new JS features not
| supported by the compiler.
|
| But then again my introduction to JS was Douglas Crockford's
| _JavaScript: The Good Parts_ and I write a lot of C++ so I 'm
| always content with the idea of using only a subset of the
| language.
| btown wrote:
| It's a shame this is being abandoned, because if you want a rich
| text editor that truly _is_ Gmail 's compose editor as it has
| existed for the past decade - that emits the same structures that
| Gmail would, handles copy-pasted rich text the same way Gmail
| does, has the same behavior in typing inside links etc... which
| is especially useful if you're building an email client that
| Gmail users need to feel familiar on every keystroke... then
| following https://github.com/google/closure-
| library/blob/master/closur... line-for-line is still the gold
| standard, because it grew from the same codebase as Gmail.
|
| I've had great success at a previous startup referencing a
| prebuilt Closure Library from a modern ES6+ codebase and creating
| a React-friendly wrapper around the editor component, and using
| this to power an email templating experience. Ironically, I'm
| within weeks of needing to do it again, thanks to Zawinski's Law
| https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law -
| "Every program attempts to expand until it can read mail. Those
| programs which cannot so expand are replaced by ones which can."
| I'll give you one guess what I'll be reaching for, archived or
| not.
|
| Others have more context on the history and have written more
| detailed obituaries - but it's a true testament to the engineers
| that worked on it, that a library can be so ahead of its time
| that it's still an industry-leading experience 14 years after its
| initial release.
| esprehn wrote:
| Fun fact: the code name for the editor was TrogEdit, with
| Trogdor the Burninator as their mascot. I believe they even had
| a life size cardboard Trogdor by their desks.
|
| It's one of the oldest, most stable, and never rewritten parts
| of the Gmail codebase.
| dataflow wrote:
| > It's one of the oldest, most stable, and never rewritten
| parts of the Gmail codebase.
|
| Sorry to be negative, but I guess the lack of maintenance
| explains why the undo/redo is so atrocious, both in speed and
| in correctness.
| jmathai wrote:
| Sometimes, simple feedback like this leads to a complete
| refactoring which addresses the main point of the refactor
| but misses the mark on so much more...for all of eternity.
| dmd wrote:
| What does "life size" mean here?
| srockets wrote:
| Another fun fact: this isn't the only software named after
| Trogdor: Apache Kafka's test framework is also called
| Trogdor[0].
|
| --
|
| [0] https://github.com/apache/kafka/tree/trunk/trogdor
| 1659447091 wrote:
| For anyone else also interested in knowing what this Trogdor
| the Burninator is
|
| https://www.youtube.com/watch?v=90X5NJleYJQ (Strong Bad Email
| #58)
| esprehn wrote:
| I have very fond memories of joining Google and discovering the
| Closure library. It had _everything_ and in an era before npm, JS
| modules, and ES6... it made writing JS feel magical. Impossibly
| large projects felt possible, and complex systems felt
| maintainable.
|
| These days it feels a bit like boost is to modern C++. A monument
| to amazing engineering of the past, but something to keep in the
| archive.
| DataDaemon wrote:
| At least they have not deleted it...
| StrauXX wrote:
| This brings back memories. A few years ago there was a CTF
| challenge at Google CTF for a XSS using Closure. There was an
| unintemeed solution by exploiting a reflective XSS in the
| documentation that is served with the closure library on
| installation. The docs page with reflective XSS could be included
| in an iFrame to get arbitrary JS with access to the root document
| (since they ran on the sam origin). No idea if this vuln is still
| around.
| dmead wrote:
| In the early 2010s we had closure, closure, clozure and clojure.
| finalfantasia wrote:
| For those who are interested, here is the official statement from
| the ClojureScript team regarding Google Closure Library going
| into "maintenance mode" and its impact on ClojureScript:
|
| https://clojurescript.org/news/2024-01-24-release
| weitzj wrote:
| This helped me great in an earlier job. Steve Jobs did not want
| Flash on the iPad. HTML5 was just getting started. And here I was
| checking how to provide a lean JavaScript Magazine App for the
| iPad.
|
| Closure library and the advanced closure compiler to the rescue
| thecleaner wrote:
| Whats the goog.framework.of.choice these days ? For those who
| haven't written closure code - whats the framework of choice at
| google these days?
___________________________________________________________________
(page generated 2024-08-30 23:01 UTC)