Google Closure Library has been archived | Hacker News Reader

Google Closure Library has been archived

github.com

178 pointsbenatkin81 comments

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

it does affect clojurescript, if they don’t have a plan to remove it they will get in big trouble later

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?

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...

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.

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"?

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

It is indeed, and the reason is because Google is switching to wasm.

Not exactly. Google is using wasm where it makes sense to do so.

Google is heavily invested in TypeScript and JavaScript. Closure Compiler is far from half dead but the need to support current language features is mitigated by translating front ends (like TypeScript).

It will support these features eventually. Public field support is mostly there, just not on by default.

Countdown to "Hey what is this Closure Compiler project? Why are we paying to maintain this again?"

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.

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.

> 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.

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.

What does “life size” mean here?

The same size as a live Trogdor, of course.

Of course, how silly of me!

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

For anyone else also interested in knowing what this Trogdor the Burninator is

https://www.youtube.com/watch?v=90X5NJleYJQ (Strong Bad Email #58)

You can still use the goog.editor, even if the repo is archived, you can still fork it.

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...

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.

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

Notably not the Closure Compiler

https://github.com/google/closure-compiler

Whew thanks - was worried there for a second!

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.

CL wasn't the only powerful library in that era - there were already: Dojo Toolkit, Ext JS, YUI, qooxdoo and jQuery.

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.

They still use it in all those services.

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.

While folks don't really use Closure Components anymore, the library is huge and both Wiz and JsLayout (and Fava) are built on Closure.

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?

They archived the open source parts , but it's the same stack internally.

So they just stopped sharing it publicly? That's kinda odd.

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...

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/16/converting-600k-lines-t....

It would not at all surprise me if google internally has better tooling than what they have open sourced though.

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

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.

You should consider terser over uglifyJS, it’s far better maintained and will get you the same if not better results

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.

Oh wow soundslice has been around for 10 years already?

What an amazing project, well done!

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.

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/

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.

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).

This is more or less what I've done as well when I've used Closure Compiler for personal projects in the past... and I was one of the Closure Library maintainers! This cognitive dissonance was just one of many indicators that the library was ready to move on.

Oh, GCL and GCC, not the other GCL and GCC

Even more confusing: inside Google they call the compiler JSC, unrelated to the JS engine in WebKit.

Naming is hard.

> GCL existed at a time when JavaScript had no notion of a module system whatsoever (not even CommonJS).

By 2007, Dojo Toolkit already had a working module system: https://web.archive.org/web/20071120165657/http://dojotoolki...

Closure. What a fitting name.

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)

Not to mention “Go” …

Ah, and the +1 button (instead of Like) in Google+ was appropriated from message board chats

At least the Go people were smart enough to refer to it as "golang" right from the start.

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.

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.

> 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.

Visual Studio 6 had all that - c1998

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

It was announced a few months ago: https://github.com/google/closure-library/issues/1214

In the early 2010s we had closure, closure, clozure and clojure.

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.

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

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?

It's a merge of Wiz and Angular: https://blog.angular.dev/angular-and-wiz-are-better-together...

At least they have not deleted it...

Wow, crazy this still existed. Hasn't been modern for a LONG time.

by definition?

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.

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.

Which is...exactly what they did.

I don't understand how what I said can be downvoted while also people are shaming it as "another project in the Google graveyard". To me it's a matter of framing---sort of what my point is here---it was framed as a kind of death.

Reply on news.ycombinator.com