Vega: A Visualization Grammar(vega.github.io)
vega.github.io
Vega: A Visualization Grammar
http://vega.github.io
17 comments
I've found Plottable (https://github.com/palantir/plottable) to be pretty good.
Good list. Dimple and DC should also be mentioned at the top of the list. And to provide a more extensive list people can evaluate: XCharts, D3xter, Metrics Graphics, TauCharts, N3, and Dangle.
Full list with links:
Vega: https://trifacta.github.io/vega/
nvd3: http://nvd3.org/
Epoch: https://fastly.github.io/epoch/
D4: https://github.com/heavysixer/d4
C3js: http://c3js.org/
rickshaw: http://code.shutterstock.com/rickshaw/
XCharts: http://tenxer.github.io/xcharts/
D3xter: https://github.com/NathanEpstein/D3xter
Metrics Graphics: https://github.com/mozilla/metrics-graphics
TauCharts: http://www.taucharts.com/
N3: https://github.com/n3-charts
Dangle: http://www.fullscale.co/dangle/
I feel a spreadsheet coming on...
EDIT: Big list here: https://github.com/wbkd/awesome-d3
Vega: https://trifacta.github.io/vega/
nvd3: http://nvd3.org/
Epoch: https://fastly.github.io/epoch/
D4: https://github.com/heavysixer/d4
C3js: http://c3js.org/
rickshaw: http://code.shutterstock.com/rickshaw/
XCharts: http://tenxer.github.io/xcharts/
D3xter: https://github.com/NathanEpstein/D3xter
Metrics Graphics: https://github.com/mozilla/metrics-graphics
TauCharts: http://www.taucharts.com/
N3: https://github.com/n3-charts
Dangle: http://www.fullscale.co/dangle/
I feel a spreadsheet coming on...
EDIT: Big list here: https://github.com/wbkd/awesome-d3
While this looks stellar and having a serializable format is cool too, I am personally not a fan of gigantic configuration files as this.
Being declarative is much better than being imperative and configuration files seem like a natural fit for a declarative system, but they lack expressiveness. They are hard to make generic and lend themselves to repetition and fragility (in my experience).
I'd say that composition wins over configuration. If you provide a domain specific language with a set of useful primitives, users can leverage it to describe what they want with more flexibility and freedom.
For concrete examples within js-land, look at gulp.js[1], connect[2]-style middleware, and JSX[3]. All of them describe their structure with code, in a composable, pluggable, reusable fashion.
That being said, with a robust enough representation like Vega's, I bet you could write code that dynamically builds the final JSON structure.
[1]: http://gulpjs.com/
[2]: https://github.com/senchalabs/connect.
[3]: https://facebook.github.io/jsx/
Being declarative is much better than being imperative and configuration files seem like a natural fit for a declarative system, but they lack expressiveness. They are hard to make generic and lend themselves to repetition and fragility (in my experience).
I'd say that composition wins over configuration. If you provide a domain specific language with a set of useful primitives, users can leverage it to describe what they want with more flexibility and freedom.
For concrete examples within js-land, look at gulp.js[1], connect[2]-style middleware, and JSX[3]. All of them describe their structure with code, in a composable, pluggable, reusable fashion.
That being said, with a robust enough representation like Vega's, I bet you could write code that dynamically builds the final JSON structure.
[1]: http://gulpjs.com/
[2]: https://github.com/senchalabs/connect.
[3]: https://facebook.github.io/jsx/
I'm sorry, I seem to be missing your point.
[configuration files] lack expressiveness.
They are hard to make generic and lend themselves
to repetition and fragility
I'd say that composition wins over configuration
I'd say we're in agreement w.r.t. the first point. While configuration files seem to be declarative in that they describe the properties of something rather than the steps to build it, they fall prey to many of the same issues that make imperative code inelegant.
As to the second point, the prime example I had in mind was the difference between Grunt/WebPack and gulp. Grunt encourages gigantic configuration files while gulp provides a set of primitives which can be programmatically manipulated and composed to produce the desired effect.
As to the second point, the prime example I had in mind was the difference between Grunt/WebPack and gulp. Grunt encourages gigantic configuration files while gulp provides a set of primitives which can be programmatically manipulated and composed to produce the desired effect.
Jeffery Heer gave a great talk at OpenVisConf earlier this year on the whole vega ecosysthem
https://www.youtube.com/watch?v=GdoDLuPe-Wg
https://www.youtube.com/watch?v=GdoDLuPe-Wg
Having worked with many different graph tools and languages (Matlab, Matplotlib, ggplot, gnuplot, Origin, D3, Raphael, Three.js, ...), I strongly believe that declarative languages are the right tool for describing visualizations. This library therefore seems to be a step in the right direction. As some people here already pointed out, pure JSON might not be flexible enough to avoid a lot of repetition for real-world use cases though, but I think it's a good start.
I think what could make this into something really useful would be the addition of special directives. MongoDB is a good example for this, as they have enriched their query language with a special operator syntax (e.g. $in, $all, $or) that allows the user to specify e.g. logical constraints.
Recently I developed a similar descriptive language for describing patterns in source code ASTs, which uses YAML as a default output format and features some regular-expression like operators that make matching of complex patterns containing e.g. repetitions, references and loops possible (for some examples, see http://docs.quantifiedcode.com/patterns/language/index.html).
Personally, I have always preferred YAML over JSON as a serialization language, since it is much more concise, easier to write (after some getting used to) and comes with handy features like anchors/references, which make e.g. self-referencing documents or variable definition much easier.
I think what could make this into something really useful would be the addition of special directives. MongoDB is a good example for this, as they have enriched their query language with a special operator syntax (e.g. $in, $all, $or) that allows the user to specify e.g. logical constraints.
Recently I developed a similar descriptive language for describing patterns in source code ASTs, which uses YAML as a default output format and features some regular-expression like operators that make matching of complex patterns containing e.g. repetitions, references and loops possible (for some examples, see http://docs.quantifiedcode.com/patterns/language/index.html).
Personally, I have always preferred YAML over JSON as a serialization language, since it is much more concise, easier to write (after some getting used to) and comes with handy features like anchors/references, which make e.g. self-referencing documents or variable definition much easier.
This is a very cool project...I haven't yet had a chance to use it in production, but the fact that Winston Chang and Hadley Wickham are using it to render interactive graphics via R...i.e. the ggvis [1] library, i.e. the interactive successor to ggplot2...makes me think that it must be a pretty solid library.
[1] https://github.com/rstudio/ggvis
[1] https://github.com/rstudio/ggvis
I went about looking for at least a draft level spec. All I could find was: https://uwdata.github.io/vega-lite/spec.json
I love the concept, but since this is presented as a "grammar", it would make sense to provide a specification of it, in addition to the examples.
Great work!
I love the concept, but since this is presented as a "grammar", it would make sense to provide a specification of it, in addition to the examples.
Great work!
Hi there, we've posted a number of example static and interactive visualizations here: http://vega.github.io/vega-editor/. A schema for a Vega JSON specification can be found here: http://vega.github.io/vega/vega-schema.json. More information about the Vega toolkit specifically can be found here: http://vega.github.io/vega/.
Vega-lite is currently under development, but some initial examples are available here: https://uwdata.github.io/vega-lite
Vega-lite is currently under development, but some initial examples are available here: https://uwdata.github.io/vega-lite
Great, thanks! If you could link to a human-readable version of this more prominently, it will be great.
Hi there, I'm part of the team behind Vega and happy to answer any questions you may have!
The unfortunate typo (or mistake, whatever) in the title aside, this looks wicked cool. Now to digest it all and understand how this fits in with something like Zeppelin or IPython.
What typo?
Looks like it has been fixed. The title originally had "grammer" instead of "grammar".
Having worked with dc.js and D3 for interactive visualizations, I'm eager to try something else like this that could simplify charting. When recharting via an API, a lot of code needs to be written to handle it. With Vega though, at least from first impressions, it seems that all you need to do is pass a payload and you can immediately re-render. There's no need to run it through reducers or unpack and massage the data to get it to fit. I'm looking forward to trying it.
[deleted](1)
Also worth noting is Vincent (https://vincent.readthedocs.org/en/latest/), a Python API for Vega, which has been my preferred method of Python data visualization for the last while -- it's been de facto deprecated since the author is not planning to rewrite it for Vega 2, but it works great.
I used Vincent for awhile. I find it to be someone dated at this point given the takeoff of Bokeh, Seaborn, Plotly, etc. Was awesome while it lasted though.
[deleted]
[deleted]
You mean grammar. I thought this was something about a "gamer".
incepted(2)
* Vega - Talked about in this thread
* nvd3 - Meant to work in similar style as D3, supports extension. Seems popular
* Epoch - Real-time charts are purpose-built to be performant and low-overhead. Limited number of visualization types
* D4 - Extends D3 instead of wrapping it. Separation of data from view
* C3js - Easier API. extendable.
* rickshaw - Mainly for time series data. Supports extensions. Works in similar style as D3.