This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # atom-editor (6)
- # babashka (31)
- # beginners (34)
- # calva (1)
- # cider (21)
- # clj-kondo (5)
- # cljsrn (2)
- # clojars (6)
- # clojure (35)
- # clojure-europe (3)
- # clojure-norway (2)
- # clojurescript (4)
- # conjure (10)
- # cursive (8)
- # data-science (78)
- # fulcro (23)
- # graphql (10)
- # helix (2)
- # luminus (1)
- # off-topic (50)
- # other-languages (1)
- # pathom (8)
- # re-frame (9)
- # reagent (9)
- # reitit (1)
- # rewrite-clj (6)
- # shadow-cljs (134)
- # tools-deps (53)
- # vscode (1)
- # xtdb (4)
Hi @smith.adriane! I'd highly recommend Oz, but as the author, am highly biased 🙂
Quil is really cool, and you have a lot of fine grained control with it if you want to do something wild.
And manually creating SVGs can also be a good way to go if you want something really custom, though may not scale if you have a lot of data.
Oz uses Vega-Lite & Vega for visualization, and there are a number of other tools in the ecosystem that are going that way now (Saite, Hanami, Gorilla, Pink-Gorilla, darkstar, etc). So you can't go wrong with VL & V specifically.
VL & V have very "data-driven" declarative approaches to specifying a data visualization as a mapping from data to visual aesthetics (like ggplot, Grammar of Graphics, etc), which I think fits really well with the Clojure model of programming (philosophically).
how much does oz know about the vega data viz model? how crazy of an idea would it be to implement a graphics backend for the vega descriptions in clojure?
The other thing you get from Vega / Vega-Lite is a grammar of interaction which allows you to build interactivity into your graphs in a very simple but powerful way
As far as Oz itself, it goes beyond just data visualization and is really a complete scientific document processing toolkit
So if you want to render markdown or hiccup with embedded vega to html or (soon) pdf, you can do that too
And doing that with clj files even tries to be smart about how it evaluates forms, so you can use it as a notebook-like environment from the comfort of your
Stepping away now, but feel free to ask more questions, and I'll circle back around if other folks haven't answered already
my other side project is a platform agnostic graphics and ui library (linux, mac, and webgl support and experimental support for html, terminal, java2d). ideally, I'd like a library that helps with the data analytics side and if there's a model for visualizations that's already well designed, then I can just start implementing the parts of the data viz model that I care about.
I'll not that there is a webgl vega renderer already: https://github.com/vega/vega-webgl-renderer
Generally plots are represented by nested maps consisting data, scales, aesthetics, configuration + some functions (this means that these are not pure data). Based on above you render chart on canvas as a separate step.
kind of, but rather generated and not simple to write by hand. I'm going to change it though.
what I would be looking for is some sort of data model that does a good job describing different charts. it doesn't really matter if the descriptions are meant to be produced by hand.
eg. • here's all the type charts • here's the data they can expect • here's all the different ways to customize them • maybe some specs for the chart descriptions and the acceptable input data
It matters less to me if there are actually implementations of drawing all of the charts. I've been working on this graphics library for a while, https://github.com/phronmophobic/membrane and would love to just implement the graphics for a given chart spec library
There was discussion to introduce vega/vega-lite spec to cljplot, but first I need to make rendering backend closer to this (if it's possible, I don't know)
vega* requires a whole ecosystem of non jvm stuff and it's unclear how extensible it is from clojure land
but vega contains well defined specification which can be adopted to other backends
I focused mostly on rendering at the beginning and stopped there since I hit the dead end with data manipulation and data dimensionality representation (called aesthetics in ggplot2 or enconding in vega*)
Vega advertises itself as a grammar or language, the rendering engine comes at the end of the desctiption
yea, it definitely seems like a good starting point, but I am wary of large specifications that only have one implementation. it makes it very easy for the spec and the implementation to start to bleed into one another
personally I prefer
ggplot2 approach but nothing stops one to build another, grammar level on the top of rendering library to store/exchange/reuse chart description
The key thing for Vega and Vega-Lite is these things are interactive - they are not simple static things lke ggplot2. If all you want is ggplot2 like stuff, then a good way now may be to just use ggplot2 via Clojisr
what's the support like for adding interactivity to a vega-lite plot via clojure?
It doesn't cover all aspects - for example, various external controls that depend on recomputing the input data are not typically covered
if you want to see reimplementation of vega-lite or lattice (R) examples in
cljplot- take a look here https://github.com/generateme/cljplot/tree/master/sketches - I made it to test my concepts (even with kind of interactivity through java2d)
That sort of 'interactive' control requires some form of reactive components coupled to the data streams TBH, it is really difficult to 'compete' with what the IDL folks are doing. They have a lot of resources and a boatload of talent
that's true, but I feel like I would also be giving up a lot of control. Like I don't think it would have been difficult (not impossible) to make this project using vega-lite, https://blog.phronemophobic.com/treemap/treemaps-are-awesome.html
Any time you opt for some form of 'declarative' coding, you give up control. Vega sits on top of D3 as its primary backend, It gives up the total control you have in D3, but you get back a great deal in the form of consistency simplicity (I know - Vega does not seem simple, but compared to D3? yeah)
Vega-Lite also give up some control as it is layered on top of Vega and targets simplifying a lot of the nuts and bolts of generating a simple chart (kind of like ggplot2 in that regard)
I think you can do what looks like declarative coding in clojure that is really just manipulating data. my experience is that you get a lot of the benefits of declarative coding, but you still retain the flexibility
I don't think tree maps are available in Vega-Lite (yet), but they are definitely in Vega: https://vega.github.io/vega/examples/treemap/
the treemap project wasn't about drawing a traditional treemap, it was about augmenting the treemaps in different ways, including interactivity
Functional stuff often looks declarative but it really isn't. There is still an explicit flow
we might be talking about different things with respective to writing declarative code in clojure. what I'm referring to is when you're working with just data. data has no explicit flow and hopefully, the what is decoupled from how
With respect to "platform agnostic graphics and ui" you may also want to take a look at Saite https://github.com/jsa-aerial/saite which is a "turnkey" data exploration and visualization system. Just need Java8 and it works on linux, mac, and windows. But it is Vega/Vega-Lite based. A new release featuring Shiny like dash construction (with R if you like as well) is coming. I am giving a demo of this new stuff at the upcoming SclCloj virtual meeting: https://twitter.com/scicloj/status/1291845872884625408
One last thing to know about would be hanami https://github.com/jsa-aerial/hanami (and bare bones example: https://github.com/jsa-aerial/bbhanami) which is 'just' a library - does not provide complete document like capabilities that Saite and Oz do. It is agnostic on that and only provides a the 'kit' components and capabilities for you to build your own vis apps.