Live data from Hacker News

ClojureScript 1.12.42

clojurescript.org

21–30 of 45 posts

Re: ClojureScript 1.12.42

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

Re: ClojureScript 1.12.42

#22
post #3

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.

Re: ClojureScript 1.12.42

#23
post #9

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.

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

Re: ClojureScript 1.12.42

#24
post #23
post #9

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.

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

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

Re: ClojureScript 1.12.42

#25
post #18

Earlier quoted context omitted.

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

Re: ClojureScript 1.12.42

#26
post #2

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

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.

Re: ClojureScript 1.12.42

#27
post #18

Earlier quoted context omitted.

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

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.

Re: ClojureScript 1.12.42

#28
post #3

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.

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.

Re: ClojureScript 1.12.42

#30
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).
Post reply on HN