cherry

2024-10-21T08:14:26.610549Z

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?

borkdude 2024-10-22T08:49:32.414439Z

Well yeah, inevitably when running a CLJS library with cherry you will either run into goog.* or cljs.analyzer.api stuff at some point

borkdude 2024-10-22T08:50:00.357609Z

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

borkdude 2024-10-22T08:51:15.334989Z

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

borkdude 2024-10-22T08:51:36.433709Z

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

borkdude 2024-10-21T08:20:09.348029Z

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

borkdude 2024-10-21T08:21:06.766329Z

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

👍 1
Max 2024-10-21T12:58:46.778889Z

> 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.

john 2024-10-22T02:38:56.331259Z

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

Max 2024-10-22T04:59:18.532299Z

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

Chris McCormick 2024-10-27T10:47:26.250859Z

> 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?

borkdude 2024-10-27T10:49:24.176069Z

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

Chris McCormick 2024-10-27T10:51:33.897459Z

Ah ok interesting, thanks.