Clojurians Log v2

hi, stupid question - what is the advantage of this vs self-hosted cljs [somehow output-modified to be es6 (a)] or is the (a) part so difficult that it motivates the whole project?

I asked the same question re babashka I know, it's the question that helps me grok what's actually going on xD

I'm pretty sure the advantage is mostly "Reducing friction between ClojureScript and JS tooling"

there are a bunch of ways this is achieved and some future goals listed int he readme. I'm sure someone can expand on more concrete differences but that's the gist of it

I understand that but don't understand what the main technical element of achieving that is beyond the self-hosted, whether it's (a) or something else

@zimablue Good questions: cherry is currently more an exploration of ideas than a final working product. It will take some time to see if it's better than what we have or whether it allows new things that were previously not easily feasible.

Thanks, it's not meant as a criticism I'm learning clojurescript and trying to understand, the complication and tooling are still a bit of a black hole to me. Because I'm working on an electron app bundle size is less relevant

Yes, JS is used in a wide variety of use cases. At the same time I'm also exploring #squint (with the help of some amazing people in that channel) which compiles more directly to JS without any of the CLJS "baggage" which can e.g. be used for ultra-small bundle sizes for cost savings on AWS or cloudflare, etc. It's about adding more use cases for Clojure(-ish) instead of "being better" than existing tools but what exactly those use cases are remains to be seen as these products aren't yet production-ready.

So macros in cherry don't actually expand before emitting JS code, is that it?

They do expand before emit

But they only run in the JS hosted compiler

Right, do you think this is a problem? I always felt that Clojurescript macros are really weird...