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.
> 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?
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.
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.
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?
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.
I've never used ClojureScript, but if I'm reading this correctly the big difference between it and Squint is the representation of data structures where ClojureScript uses something clever and Squint uses basic JavaScript structures.
How are you finding the implications of that decision? Thoughtful data structures choice seems to be one of Clojure's biggest advantages so I'm assuming there is a lot to dig through here.
Also, thanks for being a star. I nearly started this post with "Wow, what a neat beginner project, welcome to the Clojure community" but my grin threatened to hurt my face so I gave up on that idea.
