You just declare what you want drawn and you get back an svg tree which you can either modify further or transform to xml to get an actual .svg format string
It's very unopinionated and can be easily inserted in both Clojure and Clojurescript applications. You can render with the browser, webview, batik, svgsalamander or I even quickly wrote a converter to Javafx bc I have the svg tree I can directly traverse
> that still needs to call JS though... It's not like they rewrote the renderer in Clojure
But why exactly is that an issue...? Some people also think the JVM is icky so they won't touch Clojure. I don't really care much myself what underlying technology is used, I just like to get things done.
> A simpler and easy to grok alternative with minimal dependencies is thing-geom
Thanks for reminding me of thi.ng. I am both in awe at how prolific he is, while at the same time frustrated with the non-standard org-mode-driven development style.
> You just declare what you want drawn and you get back an svg tree which you can either modify further or transform to xml to get an actual .svg format string
Probably worth mentioning that Vega can also give you an SVG.
> I even quickly wrote a converter to Javafx bc I have the svg tree I can directly traverse
Can you link your code? I would like to explore this some more.
It's not an issue as such, it's just that you are doing extra work to avoid Javascript by having a fully declarative system (there's no Javascript in the Vega specs - it even has a custom language for expressions).
That's great if you intend to rewrite the renderer in Clojure. But if you don't do that - if you just call into Javascript anyway then what's the point?
It's very future-looking, but feels quite YAGNI at the moment.
And every language is equivalent to machine code which is represented as electricity in a circuit. Who cares what's further down the layers? It's about what abstractions your work with, not what libraries your code calls into.
Apparently org-mode no longer drives it, from what I read in the link above!
> Originally developed in a Literate Programming style using Emacs & Org-mode, it has recently (May 1) decided to revert to a traditional Clojure project setup to encourage more contributions from other interested parties. The original ORG source files are kept for reference in the ./org/ directory until further notice.
Well the core "issue" is they Vega ,as far as I understand it, isn't a format in the same sense as SVG is
So you're creating a hard dependency on having to embed a JS run time. There is no other rendering backend. If you have your problem space all speced out then maybe that's alright, but that generally leaves me a bit uncomfortable. The dependency graph is huge vs geom.
With geom I started my project with using batik, then moved to svgslamander when I needed to draw updates a bit faster and then when I had a bit more time to write my own renderer I changed to cljfx/javafx.
If I'm not happy with the vega renderer then I'm kinda stuck - while geom is all a digestible size
If you think that the JVM is icky, GraalVM may satisfy some of your concerns.
Just getting access to Clojure on Windows through a single graal executable saved me some heartache this week, and I can't wait to start packaging apps with it.
A simpler and easy to grok alternative with minimal dependencies is thing-geom
https://github.com/thi-ng/geom/blob/master/geom-viz/src/core...
You just declare what you want drawn and you get back an svg tree which you can either modify further or transform to xml to get an actual .svg format string
It's very unopinionated and can be easily inserted in both Clojure and Clojurescript applications. You can render with the browser, webview, batik, svgsalamander or I even quickly wrote a converter to Javafx bc I have the svg tree I can directly traverse