Immutability as a cultural value, not just a data structure.
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.
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.
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.
Shadow CLJS has made working with external libraries quite easy and IIRC it lets you set the compilation options for your libraries declaratively.
But can the compiler be used without the library? Or can the library be used without the compiler/would it still be beneficial?
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.
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.
See: https://effectivetypescript.com/2023/09/27/closure-compiler/
> 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.
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.
> 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!)
> 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!
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.
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...
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.
Borkdude•6mo 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.
bbkane•6mo ago
actuallyalys•6mo ago
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.
swannodette•6mo ago
IceDane•6mo ago
Onavo•6mo ago
YuukiRey•6mo ago
Onavo•6mo ago
dorian-graph•6mo ago
pjmlp•6mo ago
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.