Automatically bundling data into WASM notebooks

Description

I really like Marimo's static HTML exports, since it generates standalone and persistent webpages. However, this loses some capabilities, such as having interactive elements.

This is what WASM notebooks are for, but I feel they also have drawbacks. Suppose one wants to generate data from their project code and then visualize it:

1. The project code is not bundled into the notebook. Their project likely has many dependencies that are not supported by Pyodide. The "data generation" code may be very computationally expensive, so they may only want to run this once.
2. The solution is to use a script to generate the data (ready for visualization) and put this data in "public/". Then the Marimo notebook (and consequent WASM HTML export) should exclusively read this data and visualize it.

I think this does work for generating a standalone / persistent WASM HTML export. But now we have 2 scripts (the data generation script and the Marimo notebook) and multiple export files (the public/ folder and the HTML notebook). I think it's not great that the data generation and visualization components must be decoupled. This is also now more cumbersome than the static export variant (scripts: 1 notebook file; exports: 1 HTML file).

Suggested solution

Instead, what if we could toggle certain cells (e.g. invoking the data generation code and external dependencies) such that they are only run when running marimo ... commands from inside the project. In particular, when running marimo export html-wasm, these cells' variables (WASM-compatible data types) should be serialized and bundled into the resulting HTML file. When the WASM HTML file is opened and executed, it should directly deserialize these variables (instead of recomputing those cells; basically like a persistent cache).

(1) I imagine the toggle can be an @app.cell decorator. (2) I recommend dill for persistent serialization, supporting many more types than pickle and more shelf-stable or cross-platform than cloudpickle.

I think this is a simple enough solution and helps make WASM exports more expressive! Please let me know what you think. Would be amazing, thank you!

Are you willing to submit a PR?

• Yes

Alternatives

I also thought about whether it would be possible to support interactive mo.ui elements in the static export. But I think marimo export would need to load all combinations of these element states (or some user specified subset) and render the notebook for each. This generally seems more complicated, compared to using WASM and bundling in the data.

One could also just do marimo run and serve the app. However, this forces the codebase to be immutable or to always provide backwards compatibility for the notebook, in order for the notebook to be a persistent record. I think having a standalone export is really valuable for this reason. It's also generally easier to serve static files than apps.

Additional context

No response