Quickjs, Okab (altair saver)

[k-groenbroek]

Hey all, thanks for working on this! Just to let you know, there is similar development effort going on at okab. It started as a way to provide a better altair-saver method I think. I've asked the author if he's interested in somehow joining forces, see this thread.

The thread started with my idea of using QuickJs javascript engine, which might also be relevant here. See also quickjs-rs. QuickJS does run the minified vega and vega-lite code.

What are your thoughts?

[jonmmease]

Hi @k-groenbroek, thanks for reaching out and for digging into quickjs/quickjs-rs. I haven't played with it, but your thread over in daylinmorgan/okab#3 is certainly interesting and helpful.

I'm honestly pretty happy with Deno. It integrates well with Rust and has a growing community (and company) backing it. Here are a few considerations that come to mind:

• Support for data URLs is important. based on the that thread it looked like Quickjs may not support the required fetch function (which totally makes sense because this is no small task and requires things like SSL integration).
• My intuition is that Deno's performance for rendering large figures is going to be better than Quickjs since Deno uses v8 which has advanced JIT compilation built-in.
• Down the road, I'm interested in using the Vega WebGPU renderer to accelerate PNG export of charts with lots and lots of marks (e.g. scatter plots with a million points). Deno has initial support for WebGPU, which is something that even Node.js doesn't have yet.

Is your main motivation for investigating Quickjs to reduce the size of the Python wheel? The current vl-convert-python wheels come it an around 20MB. This isn't small by any means, but it's also not unreasonable. That's about 2x the size of pandas and 1/10th the size of tensorflow.

It would be great to join forces! But I just want to be up front that, for my current and future priorities, I'm pretty set on sticking with the Deno in Rust architecture.

[daylinmorgan]

For what its worth I also find the rust+deno approach preferable for consistent performance, plus community (and corporate) backing, though rust and javascript are slightly outside my general area of expertise.

[domoritz]

CC @lsh who works on the WebGPU renderer.

[k-groenbroek]

Awesome! My motivations were:

• smaller package size
• from python package perspective: add dependency on javascript engine instead of bundling it. To prevent ending up with multiple js engines inside one python environment.

But I agree with all above comments to prefer the current Deno setup. I'll close this issue. Thanks!