A larger, more detailed introduction to this topic is best discussed by Hadley Wickham in his seminal paper "A Layered Grammar of Graphics".<p><a href="https://byrneslab.net/classes/biol607/readings/wickham_layered-grammar.pdf" rel="nofollow">https://byrneslab.net/classes/biol607/readings/wickham_layer...</a><p>Wickham is the Chief Scientist at RStudio and created R packages such as ggplot2 and the tidyverse.
H2O Wave has a similar (probably tinier) Grammar of Graphics API: <a href="https://wave.h2o.ai/docs/plotting" rel="nofollow">https://wave.h2o.ai/docs/plotting</a><p>Leland Wilkinson (GoG inventor) and I designed it together a couple of years back.<p>The function for creating marks (a layer) tries to be as "flat" as possible, in the sense that it should be possible to render most common kinds of plots without having to pass nested/hierarchical options: <a href="https://wave.h2o.ai/docs/api/ui#mark" rel="nofollow">https://wave.h2o.ai/docs/api/ui#mark</a>
I’ve been building data visualizations for web for almost ten years. Most of the time it was some kind of dashboard with custom charts, interactivity and of course brand look.<p>Grammar of graphics always was this North Star for me. It is very helpful to go through papers and books and search for inspiration how to organize your system. But direct implementations are finicky to work with. And in my hubris I attempted to write yet another one implementation of grammar of graphics and it resulted in exactly the same problems!
With complex marks it is ambiguous what is a data point and what is a series. Tuning looks require this configuration objects scattered around chart definition and composition sometimes require to inject something in two different parts of definition.<p>Now I treat grammar of graphics as this collection of patterns and good practices. But surrender to pragmatic solutions when necessary.<p>Anyway I think I owe big part of my career to works of Wickham and Wilkinson.
I'm really curious how Observable will fare in the VC bear market. They seem to be a fantastic team of conceptual thinkers but I'm not sure what the cash flow looks like for this kind of tooling
I've been having fun using Observable Plot to graph various things related to digital signal processing. Here are my notes. Feedback welcome!<p><a href="https://observablehq.com/collection/@skybrian/digital-signal-processing" rel="nofollow">https://observablehq.com/collection/@skybrian/digital-signal...</a>
I am ever increasingly a fan or just manually generated SVG. Creating DSL abstraction layer on top is fine, I guess. But ultimately I know what I want and it’s easier to just make it directly instead of fighting a tool to try and induce it to make the thing I want.<p>That said, I’m weird. My blog is artisinally hand crafted HTML, JS, and CSS for the same reason.
Relevant, the OG Bertin's Matrix Theory of Graphics<p><a href="http://www.geo-informatie.nl/courses/grs60312/visualisation/files/bertin_matrixtheory_2001.pdf" rel="nofollow">http://www.geo-informatie.nl/courses/grs60312/visualisation/...</a>
The thing I hate about all of these GoG approaches is the wastefulness of the translation of data + style into visual representations. For example, if you have a dashboard with 8+ charts visible, the scaffolding of the charting library starts to weigh down the system in both performance and memory usage. VegaLite, especially, seems to make a copy of the data being passed in. Looking at the examples of ObservablePlot, I can see more wasteful processing in the form of dataset.map(d => d.property) sprinkled in several places.
I never quite got the allure of this "grammar of graphics" business. I mean, I think I "get it", but I don't get it.<p>For me GoG is basically "use ggplot2 instead of base R plotting libraries when in R".<p>Which is fine and all, but graphing utilities of matlab/octave are far simpler/flexible.<p>ggplot2 to me seems like it feels it has to add a layer of complexity to achieve the "grammar" part, without a real practical benefit over matlab etc.