Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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


[flagged]


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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: