Clojurians Log v2
cljs-dev 2026-02-24
anyone familiar with the https://oxc.rs/docs/contribute/minifier? Seems like it's aiming to be a Closure compiler alternative? if it becomes a thing, would it make sense to have a CLJS compiler that only emits ESMs (now that they're the standard) and let users specify an output type (e.g. vanilla JS like Cherry, Closure-ingestable JS like current CLJS, oxc-ingestable JS potentially)? Or if the only difference would be optimizer-specific annotations, just the same JS with different annotations?
i think #cherry is in that space
> if it becomes a thing, would it make sense to have a CLJS compiler that only emits ESMs Note that ESM has limitations. E.g. you cannot change a var from another ES module so you have to introduce workarounds that probably hinder optimization (unless there is an agreed upon namespace system, e.g. goog modules, that support mutating vars from other places).
This hinders (set! foo/bar 3) and (binding [foo/*dude* 4]) to work properly
In cherry/squint I've worked around this by introducing a special REPL mode but this format isn't optimisable by esbuild for example.
I assume the "support mutating vars from other places" workaround is to export getters and setters so another ESM can import them and use the setter to mutate the value
e.g.
ack. I guess there's some precedence for these exported getters and setters at least since that seems to be how many of the "stores" in frontend frameworks operate
I guess that's how I could implement binding in squint/cherry, to emit getters/setters for dynamic vars that can be used in binding
as a slight tangent, I wonder if atoms could sit on top of the WIP native JS signals
You can just implement the IAtom protocol for those
or whatever it's called in CLJS
ah like what reagent does with its RAtom
yeah
https://swc.rs/docs/configuration/compilation#jsctransformoptimizer that seems to do more than unused import removal (a.k.a. tree shaking) but not much