
Vega: A Visualization Grammar - hemapani
http://vega.github.io
======
colordrops
What are the best for D3-based visualization/charting libraries when it comes
to being high customizable, styleable, and performant? There are dozens of
them, but with some research the most interesting ones seem to be:

* 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.

~~~
heliodor
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.

~~~
andybak
Full list with links:

Vega: [https://trifacta.github.io/vega/](https://trifacta.github.io/vega/)

nvd3: [http://nvd3.org/](http://nvd3.org/)

Epoch: [https://fastly.github.io/epoch/](https://fastly.github.io/epoch/)

D4: [https://github.com/heavysixer/d4](https://github.com/heavysixer/d4)

C3js: [http://c3js.org/](http://c3js.org/)

rickshaw:
[http://code.shutterstock.com/rickshaw/](http://code.shutterstock.com/rickshaw/)

XCharts: [http://tenxer.github.io/xcharts/](http://tenxer.github.io/xcharts/)

D3xter:
[https://github.com/NathanEpstein/D3xter](https://github.com/NathanEpstein/D3xter)

Metrics Graphics: [https://github.com/mozilla/metrics-
graphics](https://github.com/mozilla/metrics-graphics)

TauCharts: [http://www.taucharts.com/](http://www.taucharts.com/)

N3: [https://github.com/n3-charts](https://github.com/n3-charts)

Dangle: [http://www.fullscale.co/dangle/](http://www.fullscale.co/dangle/)

I feel a spreadsheet coming on...

EDIT: Big list here:
[https://github.com/wbkd/awesome-d3](https://github.com/wbkd/awesome-d3)

------
cjhveal
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/](http://gulpjs.com/)

[2]:
[https://github.com/senchalabs/connect](https://github.com/senchalabs/connect).

[3]: [https://facebook.github.io/jsx/](https://facebook.github.io/jsx/)

~~~
hliyan
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
    

That's exactly what I would say about an imperative scheme, also from
experience.

    
    
       I'd say that composition wins over configuration
    

That too, makes not sense to me.

~~~
cjhveal
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.

------
1wheel
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)

------
ThePhysicist
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](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.

------
danso
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](https://github.com/rstudio/ggvis)

------
hliyan
I went about looking for at least a draft level spec. All I could find was:
[https://uwdata.github.io/vega-lite/spec.json](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!

~~~
arvindsatya1
Hi there, we've posted a number of example static and interactive
visualizations here: [http://vega.github.io/vega-
editor/](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](http://vega.github.io/vega/vega-schema.json). More information
about the Vega toolkit specifically can be found here:
[http://vega.github.io/vega/](http://vega.github.io/vega/).

Vega-lite is currently under development, but some initial examples are
available here: [https://uwdata.github.io/vega-
lite](https://uwdata.github.io/vega-lite)

~~~
hliyan
Great, thanks! If you could link to a human-readable version of this more
prominently, it will be great.

------
arvindsatya1
Hi there, I'm part of the team behind Vega and happy to answer any questions
you may have!

------
mindcrime
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.

~~~
ClashTheBunny
What typo?

~~~
mindcrime
Looks like it has been fixed. The title originally had "grammer" instead of
"grammar".

------
sudo_bang_bang
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.

------
jmduke
Also worth noting is Vincent
([https://vincent.readthedocs.org/en/latest/](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.

~~~
jbrambleDC
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.

------
fiatjaf
You mean grammar. I thought this was something about a "gamer".

------
nexact
[https://subgraph.com/vega/](https://subgraph.com/vega/)

