|
|
|
|
|
by iLemming
205 days ago
|
|
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. |
|
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