Clojurians Log v2

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.

Yes sure but that's not how CLJS works normally / so far

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