ClojureScript 1.12.42 | Hacker News Reader

ClojureScript 1.12.42

clojurescript.org

195 pointsBorkdude42 comments

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

From the outside (I haven't tried it), committing to ClojureScript for an application looks very similar to committing to a framework - it's a heavy influence in how you will write code.

I daresay ClojureScript typically has a significant influence, but it's more social than technical. Many of the examples and tutorials are going to favor a certain style, and people who choose ClojureScript mostly do so because they like Clojure.

But if you want to do tons of JavaScript interop, you can. If you want to adopt some syntax, you can (through macros). If you want to use jQuery directly, you can. If you want to use a React wrapper, you can. There's not really technical limits pushing you toward a style or architecture, although you still have the underlying limits of JavaScript and the runtime environment.

I'm curious as to how you think this is different from say, committing to JavaScript/BundlerX/NPM or TypeScript/BundlerX/NPM? Surely those have an equally heavy influence on how you write code?

In what way? Can you elaborate on how your choice of package manager or bundler affects how you write code, except maybe for something like import.meta.env vs process.env?

Committing to a bundler in JavaScript is a lot easier than dealing with clojurescript. JS bundlers are mostly standardized with minor differences; a complex application running on yarn can almost always be swapped out for pnpm with no or few configuration changes. On the other hand for clojurescript you have to understand the clojurescript runtime, the the JS runtime, various clojurescript and JS idiosyncrasies (clojurescript specifically blurs the line between compile time and runtime, and something as simple as reading a file into a global variable at runtime would require a lot of hacks to get working reliably) if you want to truly make the setup work for you.

Neither yarn nor pnpm are bundlers. The buy in for bundlers is a lot higher than for package managers

You wrote bundlers/package managers. I assumed you are conflating the two to be the same. Anyways most new bundlers have a (mostly) Webpack compatible (or are working towards it) API so it's a moot point.

Is that not true for any programming language?

At work, we use what is required as fashionable framework of the day.

On side projects, I don't see the issue with keeping using jQuery for as little JavaScript as possible, especially since it is still much more ergonomic to use than the browser APIs that got added later.

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.

The entire Clojure ecosystem is obsessed with stability. And I love it: it might sound boring, and you often see people complain that a library is "dead" or "abandoned" because it didn't receive updates for the last 2-3 years, but it is certainly great for business.

I run a solo-founder business and this approach means that I don't get the cost of constant churn that many other ecosystems suffer from. This is a really important factor.

That is why Valhala is on a decade now, sadly.

The core design goal is how to add value type semantics, including existing classes like Optional, while not breaking existing libraries, those JARs should work as much as possible on values aware JVM.

This is how do we add Perl 6 like features to Perl 5, without requiring people to migrate to Roku, as example.

I like how they try hard not to say just "structs". another one is "codes like a class, works like an int". as if they were ashamed of the word struct. value type semantics is just that, plus few extra rules for some reasons (forced immutability is one of them iirc).

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

Is it being maintained? From the README:

> Closure Library has been archived. We no longer see it as meeting the needs of modern JavaScript development, and we recommend that users look for alternative solutions.

Edit: ah I see that the Clojure folks are going to take that up. I missed that!

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

Have you tried Cherry or Squintjs?

I did. But for Cherry the first introductory line says - "this is experimental" and has been the same state for 2 years (IIRC). Squint is also "under development" and is more "mutable" by nature. Also, both of them are maintained (largely) by the same person (who is really good btw) but I am also confused why there are 2 experimental projects of the same nature by the same devs. Anyways, all this does not fill me with confidence where I can say that "hey lets try to build something serious with this tech stack".

I agree, these are highly experimental projects, more like POC's and not something to actually use for important work. I don't know why people are so often recommending all these myriad different Clojure/Script runtimes/interpreters, many of which are not fully baked.

There are babashka and GraalVM as alternative backends for Clojure, who aim to be much lighter than JVM.

But they don't support the full Clojure language, they're more like alternative dialects.

? Babashka is just Clojure, language wise. It lacks the ability to import arbitrary Java libs due to Graal, similarly no runtime type creation (deftype), and does not support the core async library’s go macro (maps it to thread).

I have not heard it called a dialect though. It’s not 100% vanilla jvm clojure but the omitted capabilities are just precisely those things you’d expect from using Graal. https://github.com/babashka/babashka?tab=readme-ov-file#diff...

Indeed, I was under the impression that Clojurescript was self-hosted (no Java dep) some time ago. Was this reversed?

Also, it's easy to say in retrospect leaning on the benevolence of Google would a bad idea. But the Clojure community are smart people, and I trust Closure was the least bad solution available at the time.

It's optionally self-hosted, without support for Closure's full suite of optimizations (https://clojurescript.org/guides/self-hosting).

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.

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.

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?

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.

I've been doing frontend development for over 10 years, and obviously it's anecdotal but I never heard anyone use the Closure Compiler outside of ClojureScript, and I imagine that in practice most people doing frontend development are using Webpack, Vite, Parcel, etc. The idea of really small bundles sounds nice, but in practice because the advanced optimizations require manual tweaking in many cases to get it to work (externs) it's something few people would want to deal with and the small bundle size improvement isn't worth it compared to the standard tools like UglifyJS/Terser.

There may be other reasons, but I assume the main reason that the Closure Compiler was chosen for ClojureScript was because it's Java based, so it was straightforward to get working. Moving away from it now would be a huge breaking change, so it's unlikely to happen in the official compiler anytime soon or ever. I think the only way it would actually happen is if an alternative like Cherry got enough traction and people moved to using mainly the alternative.

Yeah nowadays I think non-ClojureScript people use it mostly for legacy reasons or the aggressive minification. Back in the day, aside from the pre-ES5 conveniences I mentioned surrounding inheritance and module bundling, it was also a way for developers to do some basic type enforcement (via JSDoc annotations that the Compiler would check). TypeScript essentially rendered that obsolete.

See: https://effectivetypescript.com/2023/09/27/closure-compiler/

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.

> My surface level understanding is that GCL is a big reason why 3rd party libraries are a huge pain to use in Clojurescript.

This isn't true.

What you might have heard is that the Google Closure Compiler with :advanced optimizations makes external libraries harder to use. This also isn't true if you use good tooling (shadow-cljs makes using npm libraries transparent and totally painless).

It is worth observing that :advanced optimizations result in a significant speed increase, but are considered too difficult to use in the JavaScript world. ClojureScript was designed from the start to be compiled in :advanced mode, so you get the benefits of an impressive whole-program optimizing compiler for free.

what kind of difficulties come up in practice in :advanced mode for JS? I would have assumed that by now code is pretty good about not using "weird" effects

Externs are the main user-facing hurdle, and there's plenty of JS that doesn't bother declaring its shape ahead of time or uses dynamic access patterns.

Clojurescript furthers its sunk cost over google closure compiler. Good reason to stay away

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.

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.

They’ve forked the library, not the compiler. The Java version thing they’ve taken the hit on. (The HN title is incorrect.)

Updated the title

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.

Reply on news.ycombinator.com