[no_wizard]

Depends on your target. Clojure targets the JVM by default and that has very different constraints than say, compiling to JavaScript for the browser or node.

Compiling to a JS engine this would be great because immutability has a runtime cost

[iLemming]

Clojurescript supports transients https://clojureverse.org/t/transients-in-clojurescript/9102/...

Runtime cost of using Clojurescipt is undeniably there but for most applications is pretty negligible price to pay for the big wins. In practice, Clojurescript apps can often perform faster than similar apps built traditionally - especially for things like render optimization - immutable data enables cheap equality checks for memoization, it prevents unnecessary re-renders; data transform pipelines - transducers give you lazy evaluation, it's great for filtering/mapping through large datasets; caching - immutable data is safe to cache indefinitely, you don't have to worry about stale data;

You guys keep worrying about some theoretical "costs" - in practice, I have yet to encounter a problem that genuinely makes it so impossibly slow that Clojuresript just outright can't be used. Situations where it incurs a practical cost to pay are outliers, not a general rule.

[no_wizard]

> but for most applications is pretty negligible

Not all, and it is always preferable for it not to have a cost.

> I have yet to encounter a problem that genuinely makes it so impossibly slow that Clojuresript just outright can't be used

There’s a big swath of work that could benefit from the development streamlining that something like clojurescript or similar projects can give but any performance hit is deadly, like e-commerce.

There is also the fact that it doesn’t have 100% bindings to the raw JS and DOM APIs if I recall correctly, it’s often wrapped around React or assumed to be

[iLemming]

> it is always preferable not to have a cost.

Of course. That's why every programmer today is fluent in assembly.

> like e-commerce.

You're misinformed. I don't know where you're getting all this, but I have done enough front-end work and have built ecommerce solutions - clojurescript works better than many different things I've used, and believe me - I've tried more than just a few things over the years - livescript, gorillascript, coffeescript, icedcoffescript, typescript, haste, fay, ghcjs; I've considered elm, purescript and reasonml. The only thing I have not built with it for web is games. That's the only domain where theoretically I may have hit limitations, but because I've never done that in practice, I can't even say what those limitations could be, but I know, people have done that with great success.

Pitch.com have built their platform for presentations in clojurescript, Whimsical - their chart drawing boards, and you don't even have to imagine - that shit would need to squeeze out every drop of a cycle for canvas/WebGL and DOM updates. Most web app bottlenecks are architectural - bad algorithms, inefficient data structures, unnecessary re-renders, and Clojurescript is just amazing to deal with these kinds of problems.

> bindings to the raw JS and DOM APIs

You're saying nonsense. Clojurescript directly can call any javascript function and whatever APIs. Please at least google, or ask an LLM before blurting out nonsense like this. I don't know what emotional level of insecurities you're dealing with, but I advise you to try out things instead of prematurely reaching the level of "I hate this" without even understanding what you're actually hating. It's not that hard. These days you don't even have to learn all the intricacies of compiling it, you can use Squint - the light-weight dialect of Clojurescript. It's as easy as using a regular script tag.

https://github.com/squint-cljs/squint

Or don't use it, who cares? Stay in your mental FUD castle, letting theoretical constraints become real ones by never testing their boundaries. I have used Clojurescript, I liked it and will use it again - I have seen with my own eyes how it actually works much better than any other alternatives I have tried so far - in practical web apps that I shipped to production. I'm not married to it - it simply makes sense. For many practical reasons it does. Whenever it stops making sense and I find a better alternative, I will switch without hesitation. For now, it just works for me.