Description
Pyodide / other WASM language plugins typically take a few seconds + a performance hit when loaded, which is fine for exploration. But if I generate a report and share it with someone, they'll also take on that same performance hit just to spin up pyodide and get their matplotlib graphs. This could present a serious usability issue, since the consumer of a report likely doesn't really care that much about how the report is generated (pdf, google doc, whatever) for a large class of data science applications, and python-based data scientists might not necessarily want to port over their presentations to JS (which does not suffer this performance hit) to side-step that. It'd be trading one friction for another, and is likely to keep python-heavy users from using iodide more seriously.
Opening this issue as a proposal. I'm not sure what the solution is, but there were a few proposed during the meeting:
- capture the DOM and use the cached DOM if we're opening in presentation mode and the user explicitly somehow declares that the presentation view itself should be cached. Capture all the matplotlib canvas elements as pngs w/ a data string so we can embed all the plots easily. This removes the pyodide stack initialization penalty. Clicking "explore" requires a full re-hydration, which means "run all cells" will be triggered. But at least this penalty is less likely to be paid by a product manager who just wants to see the output.
- maybe we could use screenshots or something similar to capture the state similarly.