Question:
Is Cherry intended as the new standard way of ClojureScript runtime eval in the browser?
Explanation:
We have by now some amazing choices:
- at first there was self hosted Cljs (shown by @Yehonathan_Sharvit 2016 with Klipse)
- then came the more lightweight SCI for browser (thank you @borkdude )
2a) especially in the form of Scittle (e.g. yours truly’s 2021 Guestbook app)
2b) and recently, by the inventor, as cljs-showcase - now Cherry provides the synthesis 1)+2) (which leads to the question above)
Is Cherry intended as the new standard way of ClojureScript runtime eval in the browser?
This is what cherry.embed intends to be yes. I think a think like scittle could be built with cherry as well and then we could have better performance than scittle as well.
Thank you for clarification. I learn also that Cherry is of course much more than cherry.embed alone.
One nice feature that SCI has, is that one can evaluate user code form by form with a try/catch
(defn sci-eval [code-str new-env-atom errs-vector-atom]
(try (sci/eval-string code-str {:env new-env-atom})
(catch js/Error e (swap! errs-vector-atom conj e))))
and kind of collect the (very readable) SCI error messages without corrupting the environment for the “good” forms. That might still be a use case for SCI I think.
SCI isn’t going anywhere and will still be maintained and improved. It powers babashka, nbb, joyride, clerk among other things and the JS support will remain useful.
In clerk, cherry will likely be an additional CLJS evaluator alongside SCI:
Question:
@borkdude Will a plugin system be necessary (or, if not, at least sensible) for a possible future Cherry-Scittle?
Explanation:
With every new Scittle release, libraries (like Reagent) are specifically built and shipped with the release bundle as a plugin. Old plugins cease to work. Users need to ship their own Scittle version if they want to provide some strange feature.
It would be a huge improvement if users could build own Cherry-Scittle libraries on top of the official ones.
Like scittle, cherry can evaluate from source but can also have precompiled (with closure) libraries. So you could write libraries just by including the sources in the script tags.
@borkdude Thank you for the advise. I need some time to understand. E.g. why 2 years ago I shipped my own Scittle versions (like here to include Qlkit). I know I get something wrong, but in the meantime I like this feeling that cherry.embed is a HUGE thing that will make everything beautiful 
I managed to add the application/x-cherry script tag to Scittle and with it call a ClojureScript library that is not a Scittle plugin. I now believe cherry.embed is HUGE, but do not know if I am only misusing an implementation detail.
In any case, I forked Scittle, adding the cherry-on-top branch.
The branch adds the new Cherry script tag to the Scittle build (sporting only cherry.embed/eval-string).
Moreover the branch has a SEPARATE build exposing the Emmy Algebra System (sporting only cherry.embed/preserve-ns). In contrast to Promesa or Reagent, Emmy here is not part of the Scittle bundle.
Although Emmy is not a Scittle plugin, I can call Emmy from Cherry. This is shown in the included emmy-extra.html and also described in the README.md.
I did all this with competence but without comprehension (a.k.a. try and error). Thus I have a burning question: Am I a) using an implementation detail of Cherry here (that might change), or b) using Cherry according to best practice.
@borkdude maybe when you find some time, could you please provide your degrees of believe concerning a) and b).
When using cherry.embed you can’t mix two different builds and use Closure advanced since the CLJS functions will be optimized differently. Maybe I’m misunderstanding what you’re trying to do, but I think you want to have one single build here.
You will see what I mean when you’re passing a CLJS data structure compiled by cherry into a function to a scittle plugin or emmy.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.