> We are working on restoring that original stability. With this release, you’ll find that quite a few old ClojureScript libraries work again today as well as they did 14 years ago.
> ClojureScript is and never was only just for rich web applications. Even in the post React-world, a large portion of the web is (sensibly) still using jQuery. If you need robust DOM manipulation, internationalization, date/time handling, color value manipulation, mathematics, programmatic animation, browser history management, accessibility support, graphics, and much more, all without committing to a framework and without bloating your final JavaScript artifact - ClojureScript is a one stop shop.
show comments
lukev
One of my favorite things about the JVM ecosystem is how stable it is. A 5-year-old library will almost certainly Just Work. And Clojure very much follows the same spirit. There's a lot of great, useful libraries that haven't been updated in years... not because they've been abandoned but because they're _done_ and just don't require active maintenance.
Immutability as a cultural value, not just a data structure.
> 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 [15] years after its initial release.
I'm happy to see that it's being maintained! (And that project where I was planning to use it again got delayed, but it might be on deck soon!)
show comments
rockyj
I would have rather seen "Closure" being dumped, ClojureScript is supposed to run on the web (or Node.js) so why is there a need for Java 21 and an ancient library in 2025. In fact, Closure / Java / Maven keeps me away from ClojureScript, if there was no dependency on JVM stuff I would move to it (at-least for hobby projects / quick scripts).
show comments
john2x
While the level of commitment to backwards compatibility is commendable, I had hoped this would trigger dropping GCL instead of forking it.
My surface level understanding is that GCL is a big reason why 3rd party libraries are a huge pain to use in Clojurescript.
Of course this would have went completely against the project’s goals, so it was never going to happen.
show comments
TacticalCoder
That Clojure, the language, ended relying on Google's Closure (with a 's'), for its ClojureScript variant is one of the most WTF naming oddities of all times.
Clojure/Closure: I mean, seriously... Common. And it's somehow an accident: Clojure predates ClojureScript and Google Closure was not used by Clojure.
It's both weird and cool and highly confusing.
paulddraper
EDIT: HN title said Compiler, article says Library.
show comments
aiiizzz
Clojurescript furthers its sunk cost over google closure compiler. Good reason to stay away
> We are working on restoring that original stability. With this release, you’ll find that quite a few old ClojureScript libraries work again today as well as they did 14 years ago.
> ClojureScript is and never was only just for rich web applications. Even in the post React-world, a large portion of the web is (sensibly) still using jQuery. If you need robust DOM manipulation, internationalization, date/time handling, color value manipulation, mathematics, programmatic animation, browser history management, accessibility support, graphics, and much more, all without committing to a framework and without bloating your final JavaScript artifact - ClojureScript is a one stop shop.
One of my favorite things about the JVM ecosystem is how stable it is. A 5-year-old library will almost certainly Just Work. And Clojure very much follows the same spirit. There's a lot of great, useful libraries that haven't been updated in years... not because they've been abandoned but because they're _done_ and just don't require active maintenance.
Immutability as a cultural value, not just a data structure.
I wrote about one under-appreciated and still-relevant use case for Google Closure Library a while back here: https://news.ycombinator.com/item?id=41397235 - reposting it here!
> 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 [15] years after its initial release.
I'm happy to see that it's being maintained! (And that project where I was planning to use it again got delayed, but it might be on deck soon!)
I would have rather seen "Closure" being dumped, ClojureScript is supposed to run on the web (or Node.js) so why is there a need for Java 21 and an ancient library in 2025. In fact, Closure / Java / Maven keeps me away from ClojureScript, if there was no dependency on JVM stuff I would move to it (at-least for hobby projects / quick scripts).
While the level of commitment to backwards compatibility is commendable, I had hoped this would trigger dropping GCL instead of forking it.
My surface level understanding is that GCL is a big reason why 3rd party libraries are a huge pain to use in Clojurescript.
Of course this would have went completely against the project’s goals, so it was never going to happen.
That Clojure, the language, ended relying on Google's Closure (with a 's'), for its ClojureScript variant is one of the most WTF naming oddities of all times.
Clojure/Closure: I mean, seriously... Common. And it's somehow an accident: Clojure predates ClojureScript and Google Closure was not used by Clojure.
It's both weird and cool and highly confusing.
EDIT: HN title said Compiler, article says Library.
Clojurescript furthers its sunk cost over google closure compiler. Good reason to stay away