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.
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
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.
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?
So this is just the usual "Google kills projects lol" comment and not something based in any information about Closure Compiler specifically. Understood.
All of Google's JavaScript and TypeScript is compiled with Closure compiler. It's not going anywhere.
You're only relating the two because they share a name from being kind of sort of part of the same project 20 years ago. Closure library hasn't been used internally for a new code for a very long time.
I have a causeway (going with something different for variety) to sell you because you don’t take into account that the ClojureScript project can just fork because they have sufficient access to expertise (most projects don’t, but they do, partly because they’re big enough and partly because they’re very strong with computer science). You raise a good point but don’t allow for solutions to be presented and assume it’s a distaster scenario.
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.
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.
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!
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
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.
> 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.
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.
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.
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.
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.
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.
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’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:
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.
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 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)
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.
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:
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
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.
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.
[0] https://github.com/google/closure-library/issues/1214
[1] https://clojurescript.org/news/2024-01-24-release