I think I'm at my wit's end with shadow-cljs and trying to get it to play nice with modern js tooling. I recall cherry being conceptually exactly what I wanted so maybe it's time to get more serious about it plus tools like Closure really seem to be holding cljs back imo. What's the state of this project? Can it support the following...
β’ Just transforming cljs -> js and letting other tools handle the rest for example (:require ["#img/my-icon.svg" :as MyIcon])
β’ Use of reagent
β’ Capacity to produce files that can be used in node and the browser (depending on my app code of course)
@jayzawrotny I'm using it with web components and the built-in hiccup, you can see it here https://github.com/jakub-stastny/oso/tree/master/src/components The project needs some more work and some documentation, I haven't released it officially yet, but if you wanna have a look, go ahead. There really is no need for Reagent with web components, they are just better in every single way. It's a tad more manual, but not too much.
As in whether it's production ready, depends for what. Personal project, sure. Beyond that, it could work, but you'd have to be prepared to get involved in Cherry's development, because you will find things missing.
Either way if you're able to, it's good to support Cherry by giving it a chance at least and reporting some bugs. Personally this is what I want to be the future of CLJS.
β’ This is possible with cherry (and squint) β’ Reagent isn't supported. Keep in my mind that cherry isn't a full replacement for ClojureScript. Reagent probably still relies on goog.* stuff etc. β’ I don't see how that is specific to CLJS or cherry?
For hiccup you don't need reagent since JSX is built into cherry. For state management you might want to pick a library though, but perhaps the JS ecosystem has already stuff you can use instead
With a little configuration you can make cherry work with reagent btw, e.g. this is done in clerk with cherry viewers, but this is probably not the intended use case you are referring to if you want to completely eliminate CLJS
I feel the same way about CLJS being held back by lack of tool* interop but I donβt know the state of Squint and Cherry @borkdude howβs the development going? Were you able to get the REPL working well with ES6 modules? Can Cherry load and use other CLJS libraries yet? Do you still see this approach as a promising way forward? If so what is left for Cherry and Squint to be more production ready?
I'm not opposed to cljs, I rather like working with immutable data and atoms, just not crazy about the current state of the tooling. But this is great to hear! I should start playing with Cherry π
> Were you able to get the REPL working well with ES6 modules? In squint, somewhat. Not sure if I ported this to cherry but should not be a lot of work. nREPL works with squint, but some things don't work yet (loading other namespaces which are then compiled on demand, basically)
I feel that's mostly the missing thing. I consider them both production ready but somewhat incomplete when it comes to REPL -- squint offers the most value imo, since it's different enough from the prevailing existing option: CLJS
I'm glad both options exist though
e.g. we've compiled the clojure-mode library with squint (it was written for CLJS originally) and published it to NPM to be consumed directly from other JS libraries, without having to bring CLJS tools along
That's awesome!
@borkdude here's the issue https://github.com/squint-cljs/cherry/issues/142 I was initially confused, please read also the comment under the issue, it explains a lot, but I still have no idea how to make it work.
What's WebComponents equivalent to ratom re-renders?
Same question. That's great the hiccup supported by cherry works with web components. I was thinking of writing a reagent-like library for web components but now looks like I don't have to π