Saving HTML charts with offline rendereing and interactivity by inlining external resources

[joelostblom]

I just noticed that this was a functionality of Altair saver as mentioned here https://stackoverflow.com/a/63103365/2166823. Is this something that would fit into vl-convert as well? I'ts more like a small convenience, but curious if this would be an option. Some of this functionality might already exist here https://github.com/altair-viz/altair_viewer

[jonmmease]

I'd like to limit vl-convert's scope to include only the functionality where we need to interact with the Deno runtime using Rust. It sound to me like the functionality of generating standalone HTML files is mostly a matter of html string manipulation (not requiring a JavaScript runtime) that would be fine to do in Python.

Does Altair saver rely on the browser for doing this? If not, I'd personally recommend we move that functionality directly into Altair.

[joelostblom]

Good point, it looks like you are correct regarding string manipulation being the only thing needed so I opened https://github.com/altair-viz/altair/issues/2765 to explore if it makes sense to move this functionality into Altair core. Closing this for now at least

[jonmmease]

Thinking about this some more, and I do think this is in scope for VlConvert. It already bundles the Vega/Vega-Lite javascript libraries, so it would be great to be able to take advantage of this for generating HTML files that render charts.

An approach that I think is promising is to use the deno_emit Rust crate. In particular, the bundle function. We could bundle a small script that imports vega-embed and then renders the chart to a div on the page. One caveat is that it doesn't look like deno_emit does whitespace minification.

Then we could add vega_to_html/vegalite_to_html functions that include an option of whether to embed the JS dependencies inline or load them from a CDN.

[joelostblom]

I like this direction! I'm curious if this means that vl-convert would be able to also replace altair_viewer and allow for rendering of charts offline from an active Python environment? It sounds like we could maybe use the same mechanism with bundling/embedding the JS dependencies and it would even have the advantage of not needing an active Python kernel (like altair viewer currently does)? It would save us from keeping altair_viewer up to date as a separate package, which is currently an issue both in terms of release rights and timeliness https://github.com/altair-viz/altair_viewer/issues/59 (but only if it does not increase the maintenance burden significantly in vl-convert of course).

And maybe there is even something from the altair_viewer side of things that could be borrowed and help the implementation in vl-convert? I remember you said there is about 1 MB of relevant code/bundles in altair_viewer. Also related to https://github.com/altair-viz/altair/pull/2807 and https://github.com/altair-viz/altair/issues/2797.

[jonmmease]

I'm curious if this means that vl-convert would be able to also replace altair_viewer and allow for rendering of charts offline from an active Python environment?

After looking some at altair_viewer, it looks like one of the main things it does is provide an altair renderer that pushes displayed charts through a websocket connection to a browser. This limits you to only viewing a single chart at a time, so it's not a workflow that resonates with me personally. I'd be interested to hear feedback from folks who would like to use Altair outside of a notebook context on what kind of workflow they would like. As an alternative, for plotly, we added a "browser" renderer that opens a chart in a new browser tab each time a chart is rendered.

Once we decide on the workflow, I think vl-convert could probably help with the implementation.

[joelostblom]

This limits you to only viewing a single chart at a time, so it's not a workflow that resonates with me personally.

I agree with that.

I'd be interested to hear feedback from folks who would like to use Altair outside of a notebook context on what kind of workflow they would like.

I'm unsure how common this workflow is and where we can find these people =)

Once we decide on the workflow, I think vl-convert could probably help with the implementation.

Maybe there will be two workflows to support: 1. Offline inline inside a notebook. 2. Offline in a separate browser tab/window (with a preference for being able to render more than a single chart at a time, unless that is notably more complex to implement).

Maybe this is a good discussion to have during our call as well?