Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ClojureScript 1.12.42

clojurescript.org

Post reply on HN
Print view View original

31–40 of 45 posts

Re: ClojureScript 1.12.42

#31

Post by YuukiRey »

Onavo wrote: post #27
swannodette wrote: post #20

Earlier quoted context omitted.

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

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

Re: ClojureScript 1.12.42

#32

Post by dorian-graph »

bbkane wrote: post #18
Borkdude wrote: 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…

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.

Is that not true for any programming language?

Re: ClojureScript 1.12.42

#33

Post by krowek »

rockyj wrote: post #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).

Have you tried Cherry or Squintjs?

Re: ClojureScript 1.12.42

#34

Post by Kratacoa »

rockyj wrote: post #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).

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

Re: ClojureScript 1.12.42

#35

Post by jgalt212 »

rockyj wrote: post #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).

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.

Re: ClojureScript 1.12.42

#36

Post by rockyj »

krowek wrote: post #33
rockyj wrote: post #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).

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

Re: ClojureScript 1.12.42

#37

Post by joshlemer »

Kratacoa wrote: post #34
rockyj wrote: post #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).

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.

Re: ClojureScript 1.12.42

#38

Post by joshlemer »

rockyj wrote: post #36
krowek wrote: post #33

Earlier quoted context omitted.

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

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.

Re: ClojureScript 1.12.42

#39

Post by eduction »

joshlemer wrote: post #37
Kratacoa wrote: post #34

Earlier quoted context omitted.

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

Re: ClojureScript 1.12.42

#40

Post by yladiz »

amgreg wrote: post #15
john2x wrote: post #13

Earlier quoted context omitted.

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

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.

Post reply on HN