Clojurians Log v2
cherry
I'm having doubts about the Clojure namespace <-> ES6 output. I think it breaks down in what people expect from Clojure REPLs and also when mutating things in other namespaces with set!.
I think cherry could still be useful for writing apps like you would in JavaScript (see examples). As such it could be a good tool to win JS developers over, but I'm having doubts if it can support the REPL experience (which is based on globally mutable vars in normal CLJS, JVM Clojure and (n)bb).
Unless cherry outputs a completely different JavaScript in "dev" mode than it would in "production" mode.
For dynamic vars I think there could be a way out by modelling them as mutable objects instead of just var x = ... , so something like var x = {val: ..} and then the other namespace could do x.val = ... so we could still have binding work properly.
Thought experiment: What if vars were always compiled to globals:
(ns foo)
(def v 1)cherry.namespaces.foo = {}
cherry.naemspaces.foo.v = 1foo.mjs would export { v }
but then the module would just be a one-time snapshot of the true mutable namespaceSomething like this:
global.cherry = {namespaces: {}}
global.cherry.namespaces.x = 1;
let x = cherry.namespaces.x;
export { x }
For what it's worth, I'd definitely expect a totally different format from dev to production and would not care at all about tree shaking and such in dev mode. So I like the idea.
I recommended something similar in the hot reloading issue https://github.com/borkdude/cherry/issues/25#issuecomment-1203238677
I think it would work, but I haven't tried it
That makes sense
I understand very little of JS modules.... But what if namespaces didn't map 1:1 to JS modules? What if there was a defmodule or something like that as well?
So if you wanted some cherry code used by some JS code, you would explicitly do something like:
(defmodule ModuleName
{'default some/var
'other-function some/other-var})