I’ve been looking at Cherry a bit as I’ve found it far easier to work with ESM modules then in shadow-cljs. I have a question though, is it on your roadmap to allow usage of ClojureScript deps somehow? Is there a path that would eventually lead here? Eg. in a few of my shadow-cljs projects I’m using eg. core.async. Would those ever be usable in Cherry?
Well yeah, inevitably when running a CLJS library with cherry you will either run into goog.* or cljs.analyzer.api stuff at some point
REPL is still a TODO, but I have plans for that (first in squint, then in cherry) and isn't too far out of reach
right now you could also just workaround the "deps from git and mvn" limitation by making an uberjar with bb and unzipping that to a "vendor" directory, at least with squint. This is what #nbb basically does too, without having to build mvn stuff in JavaScript
The workflow I have is to first make stuff work in #squint and then port it to #cherry and share as much code as possible
core.async won't be usable in cherry because it's a terribly complicated library. if you look at the output of the go macro you'll be glad you can just replace it with js-await in cherry
currently CLJS deps aren't usable in cherry unless you compile them to JS first, publish them to npm and then use them as a JS library Perhaps there will be more CLJS compatibility in the future, but I never intended cherry to be a full CLJS replacement
> I never intended cherry to be a full CLJS replacement I know this is probably a big can of worms, but why not? The original CLJS implementation is showing its age in pretty serious ways, what with depending on the deprecated Google Closure Library and essentially forking the modern js build toolchain. Cherry seems well-positioned to be a modern replacement that interacts more harmoniously with its host ecosystem.
It can do that without full compatibility. Cherry would have to replicate all of goog-closure bits to bring full compatibility, right? Seems like a lot
I think this a question of what “replacement” means. I interpreted the statement as “a viable alternative for” not as “a drop-in replacement for”. So the stuff that’s missing is dev features, like a repl and a way to use cljc dependencies, not necessarily goog-closure shims
> CLJS deps aren't usable in cherry unless you compile them to JS first, publish them to npm and then use them as a JS library Is this how Scittle is able to use a pre-compiled version of Reagent? Or is there something different going on there?
That's not what I meant here, but how it's done in scittle can also be done using cherry when using cherry as an embedded compiler: https://github.com/squint-cljs/cherry/blob/main/doc/embed.md This is e.g. available in clerk where you can use reagent with cherry at runtime
Ah ok interesting, thanks.