If I understand the code correctly, this is is lisp code that ultimately generates a json to be fed to the plotly javascript library [1].
That's sort of interesting. I sometimes work on specialized plotting tools for computational mathematics, and I see now that I expect plotting libraries to ultimately boil down to some c backend like libcairo or libpng, or to directly output a format like an svg or ps or pbm or something --- or alternately to be entirely js from start to end.
But upon further reflection, I don't see any reason to keep the worlds of online and offline plotting so completely disjoint.
> I don't see any reason to keep the worlds of online and offline plotting so completely disjoint
I would guess it's less about "online and offline" than "in a web browser and out of one". The web offers several powerful standards for rendering 2D visuals - SVG, canvas, WebGL - all of which are much easier to bootstrap and to use directly than anything that's ever made it to the native desktop, and all of which come with first-class support for interactivity.
Even today, just creating a desktop window that you can draw to using OpenGL is a significant hurdle for someone who isn't used to that sort of thing. Now, do want that GUI code to also work on multiple systems? What about your graphics code? macOS has deprecated OpenGL. Do you want to interact with it using your mouse? What about rendering text, which is a whole other hurdle? Heaven forbid you want a higher-level vocabulary or dev tools with live inspection. I suppose writing to a PNG is easy enough- but then you lose any chance at interactivity.
The web is simply the most straightforward option if a plot is to be embedded in any kind of interactive app.
This pattern of a having code in one language generate a static JSON 'spec' for a figure for rendering in Javascript is very widespread actually... We have Plotly wrappers in Python, R, and Julia and the community has made many others e.g. Scala, F#, Rust, .NET, C++ I believe even!
This is the same approach used by non-Plotly systems like Bokeh
in Python (and at one time in R?), Highcharter in R (targets the Highcharts Javascript library) and Altair in Python (targets the Vega-Lite Javascript library).
One of the major advantages of this approach is that it makes it easy to move from visualizing data locally to embedding these same visualizations into a web application, which is what Plotly's Dash library is for: https://dash.plotly.com/
That's sort of interesting. I sometimes work on specialized plotting tools for computational mathematics, and I see now that I expect plotting libraries to ultimately boil down to some c backend like libcairo or libpng, or to directly output a format like an svg or ps or pbm or something --- or alternately to be entirely js from start to end.
But upon further reflection, I don't see any reason to keep the worlds of online and offline plotting so completely disjoint.
[1]: https://plotly.com/javascript/