Microsoft SandDance: unit visualizations for exploring and presenting data

What SandDance is for, and who ends up using it

SandDance addresses a specific problem: aggregate charts hide the rows they were computed from. A bar chart of average order value tells you nothing about the distribution behind that average, and switching to a scatter plot usually discards the sense of which marks correspond to which records. SandDance takes the opposite approach. The README describes unit visualizations, which it defines as a one-to-one mapping between rows in your database and marks on the screen. Every dot you see is a row. When you change the view, the marks move rather than being redrawn from scratch, so you keep track of individual records across views.

The intended audience is not only data scientists. The README lists use cases that read like analyst work: finding insights, telling stories supported by data, building cases from evidence, testing hypotheses, supporting purchasing decisions, and relating data to a wider context. In practice the project reaches people through three Microsoft surfaces before it reaches them as a library. There is a web app at microsoft.github.io/SandDance/app, a Power BI custom visual, an Azure Data Studio extension and a VS Code extension. Someone who wants a chart in a report and someone who wants to embed a canvas in a React application arrive through different doors but land on the same rendering core.

The component architecture and how the packages stack

The repository is a monorepo with several JavaScript components, and the layering matters more than the package count. At the bottom is sanddance, described as the core SandDance visualization canvas. Above that, sanddance-specs provides Vega specifications for unit visualizations, which is the project's way of expressing chart layout: the README states that SandDance uses Vega for chart layout. Vega is a declarative grammar, so a view is described rather than drawn imperatively.

For React applications there are two further layers. sanddance-react is the core canvas wrapped for React, and sanddance-explorer adds UI on top of that canvas so users can explore data without you building controls. sanddance-embed sits beside them as the lowest-effort path: the README calls it the easiest way to embed SandDance Explorer in your applications, via an iframe tag. That is a real architectural statement. If you only need the explorer on a page, you do not need the React packages at all.

The rendering history is visible in the changelog. A July 2022 entry records a major version bump to v4 and a switch to MorphCharts. Earlier entries record v3 moving to Deck.gl@8 in June 2020, v2 moving to Vega@5 in December 2019, and the initial GitHub release in April 2019. Those are dependency migrations large enough to force major version bumps, which tells you the rendering layer has not been stable across the project's life. The GitHub releases list only goes up to v3 in August 2022, while the changelog describes v4 in July 2022, so the published releases and the changelog do not line up cleanly. Verify which version a package actually resolves to before you pin it.

Installing SandDance and getting a first canvas on screen

The root package.json is private and describes itself as the SandDance development monorepo, so you do not install the root. You install one of the published workspace packages. Note that the root postinstall script copies inuitcss and then runs npm install inside packages/powerbi, which means a full clone install does more than pull dependencies.

For a React application, the explorer package is the one that gives you both the canvas and the exploration UI. The repository layout places it at packages/sanddance-explorer, and its own README is where the import path and props are documented.

If you would rather not write any JavaScript, the repository contains an extensions directory and the README points at a VS Code extension on the marketplace, which is the shortest path from a CSV to a SandDance view.

To work on the project itself rather than consume it, the root package.json defines the development loop. The start script runs watch-typescript, watch-css and serve-app in parallel, which is what the README's Development section points at through dev.md:

npm start

The build is not a single command either. It is chained as build:01 through build:09, each delegated to the workspaces, and the root build script runs all nine in sequence:

npm run build

That sequential chain is worth knowing before you file a bug about a stale artifact: a partial build leaves earlier workspace outputs untouched.

WebGL2, animation, and where SandDance breaks

The README's Known issues section has exactly one entry, and it is a hard constraint: animations require a WebGL2 enabled browser. Since animated transitions between views are the mechanism that preserves context, a browser without WebGL2 does not degrade gracefully into a static chart tool. It removes the feature that distinguishes SandDance from a scatter plot library. Headless environments, server-side rendering and locked-down enterprise browser configurations are therefore the wrong place to run this.

The roadmap is candid about what is unfinished. Code examples and tutorials are listed without a strikethrough, while the Power BI visual, additional views such as stacks, and faceting for all chart types are all marked done. Better date handling is also listed as outstanding. If your dataset's temporal dimension is central to the question you are asking, that is a known weak point rather than a hidden one.

The project welcomes contributions but requires a Contributor License Agreement; the README states that most contributions require agreeing to a CLA and that a CLA-bot comments on pull requests. That is normal for Microsoft repositories, but it does slow down drive-by patches compared with a project that accepts pull requests without paperwork.

SandDance compared with Vega-Lite and deck.gl

The closest comparison is Vega-Lite, and the difference is philosophical rather than technical. Vega-Lite asks you to declare an encoding: mark type, channels, aggregation. The output is a chart. SandDance asks you to declare a unit visualization, and the output is a population of marks that can be re-encoded interactively while individual marks persist. If your goal is a reproducible, version-controllable chart specification for a report, Vega-Lite is the better fit and SandDance is the wrong tool. If your goal is a person moving between views to notice that one cluster behaves differently, the one-to-one mapping is the whole point.

The second comparison is deck.gl, which appears in the repository topics alongside vega. deck.gl is a rendering framework for large-scale layers on maps and in 3D; SandDance is an application-level toolkit built around a specific visualization grammar. SandDance's changelog records that v3 moved to Deck.gl@8, so the relationship is closer to dependency than to alternative. Choosing deck.gl means writing your own layer logic and interaction model; choosing SandDance means accepting its views and its explorer UI.

The publication trail explains why the design is unusual. The README cites Atom: A Grammar for Unit Visualizations from IEEE TVCG in December 2018, and A Unifying Framework for Animated and Interactive Unit Visualizations from 2015. SandDance is an implementation of a research result, not a chart library that grew features over time. That is the source of both its distinctive behaviour and its narrower scope.

Licence, maintenance and upgrade cost

SandDance is MIT licensed, and the repository carries a LICENSE file at the top level. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and permission notice be preserved. For a project that bundles SandDance into a shipped application, that means keeping the licence text in your distribution. This is a description of the licence, not legal advice; if your organisation has a policy on third-party notices, run it through that process.

The last push to the repository was on 2026-09-17, and the repository is not archived. The most recent GitHub release listed is v3 from 2022-08-03, while the changelog describes a v4 bump in July 2022. That gap between release tags and the changelog is the practical upgrade risk: if you depend on a published version, you may be consuming a rendering stack older than what the repository describes.

The upgrade cost is dominated by the rendering dependencies. The changelog shows three major version bumps tied to dependency swaps: Vega@5, Deck.gl@8, and MorphCharts. Each one changed the rendering layer, which is exactly the layer an embedder's custom styles and interaction handlers attach to. Budget for a real migration if you pin an old major and later want a newer one, and check the individual package READMEs rather than the root README when you do.

Editorial conclusion

SandDance fits analysts and developers who want one row mapped to one mark and want that canvas embedded in a React app, a Power BI report or a VS Code window. It is a poor fit for anyone who needs server-side rendering, a stable documented API surface, or a chart library with a large gallery of conventional chart types. Before adopting it, check that your target browsers have WebGL2 enabled, since the README lists animations as requiring it, and read the README of the specific package you plan to import rather than the root README.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/SandDance on GitHub
3. Project website
4. README
5. Releases