tophtucker

Hah, I just pared down that “More from Observable creators” section the other day to make it less obtrusive, and inadvertently made it more confusingly blend into the notebook contents. This is good feedback; we’ll refine it!

From the Observable Framework point of view, you’re very welcome to use Apache ECharts or any other library instead of Observable Plot, since you can import whatever you like and it’s all just JavaScript.

Since there was a lot of interest in this thread, Mike added a page to the docs with an ECharts example: https://observablehq.com/framework/lib/echarts

There are two pieces of that example code specific to Framework: the html`` tagged template literal creates a DOM element (see https://github.com/observablehq/htl, also usable outside Framework), and the display function inserts it into the document above the code block (see https://observablehq.com/framework/javascript/display). Note that, whereas Observable Plot takes an options object and returns a DOM element, ECharts instead takes a DOM element and mutates it — but in general they should be equally easy to use in Framework.

Like Plot (and Vega-Lite, another great option), ECharts is also now one of Framework’s built-in “recommended libraries” (see https://observablehq.com/framework/javascript/imports#implic...), meaning that if you reference `echarts` Framework will lazy-load it for you. Adding that was a two-line diff: https://github.com/observablehq/framework/pull/811/files#dif.... But I wanna emphasize that Framework doesn’t have to explicitly “support” a given library for you to use it. “Supporting” in this case just means the convenience of saving you a one-line import statement. But don’t wait for our blessing!! Use whatever.

Haha yeah, that’s well put — “latest” depends on time, and something that depends on time is not deterministic, so those principles conflict. Currently a Framework project has the opposite priorities as Go and always gets the latest version of the data.

When I first started working at Observable I explained reactivity to my now-wife as “when one thing changes, other things that depend on it update automatically.” She was at an asset management job at the time working in Excel all day, which of course is also reactive in that sense. But she interpreted my statement differently; she said “Oh that’s terrible! If a number changes I want to know.” E.g. if the estimated budget for a project had ballooned, she wanted to hear about it so she could check why, ask other people about it, try to contain the damage, warn others, make other decisions differently, etc. “Automatic” would be harmful, like in your Go example. She was also thinking about coarser-grained data than I was — a single very impactful number, not a stream of mousemoves or pageloads or ad clicks or whatever.

Good questions.

1. It’s just JavaScript so you can fetch stuff dynamically too (see https://observablehq.com/framework/lib/duckdb). But yeah, only client-side. (Though see https://github.com/observablehq/framework/issues/234.)

2. Sure, it’s all open source, I bet you could make that work. Or `yarn deploy` to Observable and configure sharing there (though it wouldn’t let you charge others).

3. Yup. Which is part of the appeal of model of running data loaders at build time: you can query some private data and viewers would only be able to see the final result set. (The lack of something like this has always been a huge problem for Observable notebooks. You’d make some great query-driven charts and then couldn’t make it public without some awkward manual dance of downloading and re-uploading a file to a fork of the notebook.)

4. I wish I knew! It’s being tracked here https://github.com/observablehq/plot/issues/1711. Lately there’s been a lot more work on Framework naturally but now that that’s out…

5. Another good question. We’re definitely interested in tailoring it more to this sort of use case but lots is TBD!

Yeah there are some open issues about more granular rebuilds and chaining data loaders. https://github.com/observablehq/framework/issues/638, https://github.com/observablehq/framework/issues/332

It’s kinda cool to think about the shearing layers of reactivity. Reactivity is what originally drew me to Observable. But the way notebooks have to be recomputed live for every viewer every time makes them feel silly for, like, a BI dashboard that changes daily at most. Like they only have one pace layer. Like they’re trying so hard to be _live_ that they can’t be _fast_! Idk. I guess even a chalkboard is reactive on the timescale of “someone noticing some information and telling it to someone who writes it down” lol.

We’ve talked about and shared your “File over app” manifesto so many times internally over the last few months. It’s one of those tweets that gets immortalized as the perfect crystallization of an ethos that we might otherwise have only been able to gesture at vaguely. It gives the ethos weight and clarity and credibility, and it’s such a relief to be able to point to it! I’m very grateful. —an Observable employee

Yeah data loaders are like a UNIX pipe to a reactive notebook cell (?). There needn’t be any question of “do the data loaders support this or that”; it doesn’t even have a concept of “supporting” beyond supporting stdout… Still thinking through how to understand it myself!!

I’d never heard of Airnow; do you know if that’s where Apple and Google Maps get their AQI data too? I like seeing some points spill over to Canada… nice hint of the international cooperation… https://www.airnow.gov/partners/canadian-partners/

asciidoc-diagram & Kroki look cool, hadn’t seen them. I don’t think Plot’s very good at (or built for) that sort of diagramming, though you can do it if you want: https://observablehq.com/@observablehq/plot-finite-state-mac....

What I personally like most about Plot is that it’s purely JavaScript (/ TypeScript); it doesn’t try to be serializable as JSON and portable to Python etc. So whereas Vega-Lite has to have its own expression language (https://vega.github.io/vega/docs/expressions/):

  "transform": {
    "calculate": [{"field": "b2","expr": "2*datum.b"}],
    "filter": "datum.b2 > 60"
  },

…in Plot you’d use plain JavaScript:

  y: d => 2 * d.b,
  filter: d => d.b2 > 60

…which I find easier and more powerful. (But I don’t need VL’s portability; others may.)

There’s no animation built-in currently. But it’s fast enough that you can often just throw away and re-render the Plot (i.e. handle the animation externally).

Mike Freeman made a helper function that adds that sort of animation (data gradually coming in) using D3 atop Plot: https://observablehq.com/@mkfreeman/plot-animation

You could upvote this incremental rendering issue: https://github.com/observablehq/plot/issues/328

Or this one for adding a “time channel” to do data-driven animation (for which there’s an old draft PR): https://github.com/observablehq/plot/issues/166

Out of curiosity I’d love to see any examples where you think Plotly is especially strong for scientific plotting. I’ve used Plot lots and Plotly none, but I’d guess the big Plotly advantages right now are

- rich tooltips (coming soon in Plot)

- interactive pan & zoom

- multiple panels with shared scales? (like for marginal distributions; you can combine with HTML of course, but it’s not easy/built-in in Plot)

It’s not easy to do radial stuff right now; you can upvote this issue: https://github.com/observablehq/plot/issues/133

One bizarre workaround right now is to abuse the geographic projections: https://observablehq.com/@observablehq/pie-to-donut-chart

In general, you can do a lot of customization, including plugins (though that’s not well-documented yet), so you could make it work… see https://observablehq.com/@fil/radial-transform, https://observablehq.com/@observablehq/plot-radial-line for other approaches to hacking radial stuff into Plot.

You can do Cartesian tree diagrams in Plot, e.g. https://observablehq.com/@observablehq/plot-tree-flare, https://observablehq.com/@observablehq/plot-custom-tree-layo...

If you want to make a chord diagram like that “Müsli Ingredient Network” example, you could try one of these D3 examples: https://observablehq.com/@d3/chord-diagram, https://observablehq.com/@d3/hierarchical-edge-bundling/2

Fil (one of the Plot developers) made https://github.com/Fil/plot-cli, and Michael Keller has https://github.com/mhkeller/plot/, which supports Plot (and Vega-Lite and Plotly). Could probably be more robust; feel free to make feature requests, I know a few other people have asked me about this.

Re 1), I like Mike's talk from the 10th anniversary of D3. It came while working on Plot but before it was officially released; a few of the points relate to the high/low-level thing and anticipate Plot:

Video: https://www.youtube.com/watch?v=Sqeymt1mqAw Essay: https://observablehq.com/@mbostock/10-years-of-open-source-v...

Re 2), Plot returns a regular DOM node, so you can select any part of it and do anything you’d otherwise do with D3. Plots also expose their scales: assuming the DOM node of a generated Plot is named myPlot, you can call myPlot.scale("x"), and then feed that domain and range into a D3 scale. I can find some examples later if you’re interested.

Oops yup shared!

I gave a presentation once on why I kinda like pie charts but it was based on zero research so I'd be interested to see that. I mean I think if you're just showing one whole they're as intuitive as any visualization can get. It's a populist cause.

>What cyclic modular spatial visual encoding can you find to encode your proportions other than angle? I get that it’s sorta hard to compare across pie charts. But if you see a stacked bar chart, nothing about it signals that it’s out of 100%! No Cartesian encoding is a non-arbitrary 100%! Whereas pie charts need no axis! Everywhere in the universe, 360º ≅ 0º. Pie charts carry their axis with them throughout the universe! That’s very special!

— from https://medium.com/@tophtucker/doing-enterprise-financial-da...

Maps are the big new thing but note that projections mean you can also now do pie and donut charts lol: https://observablehq.com/@observablehq/pie-to-donut-chart

Yeah, we at Observable love Vega-Lite (and Arquero etc). My coworker Ian wrote a great summary of how Plot relates to Vega-Lite here: https://observablehq.com/@observablehq/plot-vega-lite. Like you said, his first point is that Plot uses plain JavaScript functions instead of Vega Expressions.

Another difference is that Plot does more type inference, e.g. using d3.scaleUtc if the values are dates and d3.scaleLinear if not.

I wrote a similar notebook about Plot and D3, though the differences there may be more obvious: https://observablehq.com/@observablehq/plot-for-d3-users

Yup. There’s some discussion of this in this issue https://github.com/observablehq/plot/issues/359, which notes that the ~100 test plots in https://github.com/observablehq/plot/tree/main/test/plots are rendered by Node with JSDOM by https://github.com/observablehq/plot/blob/main/test/plot.js.

Not currently, but we’ve talked about it. We’ve been using a lot more TS internally lately so there’s a growing case and it’s good to hear your vote.

nice. great clear thorough code snippets on homepage. i should try it. why "tamber"?

I like "insider information" as a lazy excuse for the hinting/info-leakage problem. :) It's a metaphor!!

-the developer

Did notice, didn't know what to do about it. I think it's the main problem with the game. There are plenty of options that don't leak and maybe I was just too enamored of the visceral feel of the y-domain following simplified+smoothed price line. Scale is also sensitive to variance over time, also smoothed, also leaks.

-the developer

Hi I made the game. Really glad you brought up #1 — I think it's the main problem with the game. The y-domain follows a simplified and smoothed version of the price line, which, yes, leaks information about the future. Not sure what to do about it. Because viscerally I like the movement.

#2, yes, that too. We talked about that issue but maybe not enough. I wonder if you even need to know what the timescale is. Stock movements are pretty fractal and scale-invariant, after all, right? Kinda? Hm.

You're right, lines 104 & 140 in http://www.bloomberg.com/graphics/2015-ketamine-depression-t.... Considered the gpu thing but was reading mixed advice (http://stackoverflow.com/questions/10814178/css-performance-...) and ran out of time.

critique me! #showhn http://bloomberg.com/graphics/2015-ketamine-depression-treat...

that's no image

I love this. Thank you.

- Are there general principles you'd emphasize for mapping continuous control domains to discrete content ranges? (Like input rasterization.)

- If you could redesign the user control/input space (keyboards, mice, etc.), what might it look like?