ClojureScript 1.12.42 • Hacker News Board

Re: ClojureScript 1.12.42

#41

Post by amgreg » Sat, May 17, 2025, 6:13 PM UTC

yladiz wrote: post #40

amgreg wrote: post #15

Earlier quoted context omitted.

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

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/

Re: ClojureScript 1.12.42

#42

Post by Onavo » Sat, May 17, 2025, 6:17 PM UTC

YuukiRey wrote: post #31

Onavo wrote: post #27

Earlier quoted context omitted.

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

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.

Re: ClojureScript 1.12.42

#43

Post by jaccarmac » Sat, May 17, 2025, 7:49 PM UTC

jgalt212 wrote: post #35

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.

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

Re: ClojureScript 1.12.42

#44

Post by jaccarmac » Sat, May 17, 2025, 7:55 PM UTC

rtpg wrote: post #24

jwr wrote: post #23

Earlier quoted context omitted.

> 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

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.

Re: ClojureScript 1.12.42

#45

Post by nbittich » Sun, May 18, 2025, 1:18 PM UTC

pjmlp wrote: post #28

lukev wrote: 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.

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