[HN Gopher] ClojureScript 1.12.42
___________________________________________________________________
ClojureScript 1.12.42
Author : Borkdude
Score : 61 points
Date : 2025-05-16 20:20 UTC (2 hours ago)
(HTM) web link (clojurescript.org)
(TXT) w3m dump (clojurescript.org)
| Borkdude wrote:
| > 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.
| lukev wrote:
| 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.
| paulddraper wrote:
| EDIT: HN title said Compiler, article says Library.
| Borkdude wrote:
| This is not about maintaining compatibility with a Java
| version. As you can read in the post, Java 21 will be the
| minimum required Java version even. It's about the Google
| Closure Library on which many ClojureScript programs depend.
| moomin wrote:
| They've forked the library, not the compiler. The Java version
| thing they've taken the hit on. (The HN title is incorrect.)
| Borkdude wrote:
| Updated the title
| Borkdude wrote:
| The title didn't say compiler, it just said "Google Closure".
| The article I linked to is very clear that it's about the
| library.
| john2x wrote:
| 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.
| amgreg wrote:
| I think you are conflating the Closure Library with the Closure
| Compiler. They are related but not identical. The Compiler, I
| think, is what makes it difficult to use externs; its "advanced
| optimizations" can and often does break libraries that weren't
| written with the Compiler's quirks in mind. But advanced
| optimizations is an option; if you don't need aggressive
| minification, function body inlining, etc. you can opt out.
|
| Shadow CLJS has made working with external libraries quite easy
| and IIRC it lets you set the compilation options for your
| libraries declaratively.
| john2x wrote:
| Ahh right. Yes I am in fact conflating the two.
|
| But can the compiler be used without the library? Or can the
| library be used without the compiler/would it still be
| beneficial?
| amgreg wrote:
| Yes and yes; in the past, prior to ECMAScript providing
| first-class inheritance, module ex/imports etc, the Library
| supplied methods to achieve these in development, and the
| Compiler would identify these cases and perform the
| appropriate prototype chaining, bundling, etc. See, eg,
| goog.provide
|
| For the most part, I would guess people still use the
| Closure Compiler because of its aggressive minification or
| for legacy reasons. I think both are probably true for
| ClojureScript, as well as the fact that the Compiler is
| Java-based so it has a Java API that (I am guessing here)
| made it easier to bootstrap on top of the JVM Clojure
| tooling / prior art.
| Volundr wrote:
| At this point dropping GCL would be a breaking change. Many,
| many libraries rely on it.
|
| > My surface level understanding is that GCL is a big reason
| why 3rd party libraries are a huge pain to use in
| Clojurescript.
|
| I'm sure what "huge pain" your referring to, but I'm guessing
| it's dealing with name munging when externs aren't readily
| available. That comes from the compiler, not the library, and
| can be annoying. Mainly you have to make sure you reference
| things in ways that won't get mangled by the compiler (get x
| "foo") instead of (get x :foo). If you want to escape that you
| can always turn of advanced optimizations.
| btown wrote:
| 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!)
___________________________________________________________________
(page generated 2025-05-16 23:00 UTC)