ObservableHQ notebooks for JavaScript demos and prototypes

ObservableHQ is a platform being built by Mike Bostock (creator of the D3 visualisation library), Jeremy Ashkenas (“Made CoffeeScript, Backbone.js, Underscore and other ragbag” from his Twitter bio) and Tom MacWright (creator of the big presentation framework, simple-statistics and documentation.js as well as D3 contributor amongst other things).

Observable is not just another JavaScript sandbox. It introduces the notebook paradigm to JavaScript projects, those of you familiar with Jupyter notebooks, this is the equivalent with JavaScript instead of Python. It turns out JavaScript is very well-suited to this type of paradigm.

What’s more, JavaScript developers already have some sort of familiarity with reactivity since most frontend frameworks and view libraries build on it. It’s a different kind of reactivity, in that the library only re-renders or re-computes the section of the application that needs it (cf. Vue, Angular, React).

You can read original post from Bostock detailing what is now ObservableHQ (then called d3.express), “A better way to code” on Medium. In that post, the state of the art of why and how of data visualisation is explained. A “better way” is described, the “integrated discovery environment”, or more simply “notebook”-s.

That inception post is a 20 minute read, but here’s the tl;dr:

1. visualisations are usually one-offs - “The purpose of visualization is insight, not pictures.”
2. reactivity is great for building visualisations and discovering insights from data
3. visual outputs help massively especially in the exploration phase
4. a well-designed notebook system has the benefit of making chunks of code reusable without much effort (or re-packaging as a library)
5. web-based notebooks are accessible from anywhere by anyone (if that’s wanted behaviour)

I especially like points 4 and 5, since they’re not a selling point for notebooks in general but for ObservableHQ’s take on the problem. What you end up with is a well-designed web-based reactive notebook environment that’s suited to prototyping.

Table of contents:

Features

Cells and reactivity

The evaluation model for ObservableHQ is based around cells that react to each other (you can read more about notebooks and cells here)

A cell can be pretty much anything. For example, a cell might contain a few paragraphs of text, like this one. Or a cell might contain images, videos, charts, or other graphical and interactive elements. A cell can also contain data structures, like numbers, strings, arrays and objects. Functions, too.

Here’s what Bostock says about reactivity (find the full post here):

A cell that references other cells is re-evaluated automatically whenever the referenced values change.

So two things happen:

1. You can stuff anything in cells
2. Your cells have an obvious dependency graph according to which they will re-evaluate

That means you can be sure that for example, if you do a fetch it will only run once unless you manually get it to re-evaluate or something that the fetch is dependent on changes. This is in stark contrast to what happens when you’re hacking in JavaScript where each run of the code will cause a fetch.

This kind of reactivity means we don’t have to use precious brain capacity to keep track of what state is in a part of the program. The state is there, spelled out for us in the other cells. So we get faster trial and error (more formally “iteration”) cycles.

What we also don’t need to worry about is pending vs resolved Promises, Observable vs emitted values or what ObservableHQ calls generators. ObservableHQ deals with all these the same way: it gives you the data, not the underlying abstraction, how refreshing not to have to do .then(console.log) as a sanity check.

Display arbitrary data in arbitrary ways

Speaking of console.log, outputting and observing data doesn’t involve console.log or debugger, due to the programming model, tracking data and changes is straightforward.

Rendering data and text is as simple as using JavaScript string interpolation with a special template literal tag (namely html, md). That means you can write inline SVGs based on your data much like you would write JSX (granted, there’s a bit more syntactic noise):

html`<svg>
  ${
    someData.map(
      (el, i) => `<text x=0 y={i * 20}>${el}</text>`
    )
  }
</svg>`

Get input of data in arbitrary ways

User input

viewof value = html`<input type="text" value="default-value">`

Network resources

fetch('my-url').then(res => res.json())

File upload

viewof file = html`<input type="file">`
// use the file as audio or something
fileDataUri = URL.createObjectURL(file)

(see audio waveform example later on)

It feels like working with a view library

Due to the reactivity and how it handles data, using ObservableHQ feels great, a lot like React/Vue with hot-reloading, except you don’t have dev environment that breaks

Import of other notebooks/modules

I haven’t used this much (probably because I didn’t build any interesting visualisations), from what I can understand you can import parts of notebooks into another.

Sample projects

Run a simple Emoji search

https://beta.observablehq.com/@hugodf/search-and-download-emoji-from-github

Write straight SVG visualisations

https://beta.observablehq.com/@hugodf/reddit-contributions-per-week-graph

Do interesting things with web APIs

https://beta.observablehq.com/@hugodf/audio-waveforms

Pure JavaScript demos

https://beta.observablehq.com/@hugodf/recursion-to-wrap-http-requests https://beta.observablehq.com/@hugodf/count-something-in-something-else

CSS demos

https://beta.observablehq.com/@hugodf/bonus-everyday-situations-you-can-solve-without-javascrip

An exciting roadmap

There are more features that will make ObservableHQ even better like notebook embeds.

You can find out more on the ObservableHQ forum and in the changelog.

Headway