Export WASM to folder for self-publishing on personal web site

[akshayka]

Discussed in https://github.com/marimo-team/marimo/discussions/1078

^{Originally posted by **astrowonk** April 5, 2024} marimo.app is very cool and I was excited to see the WASM support. But, WASM apps should be able to just be turned into a folder than can deployed on any web server (nginx, apache, etc.) [Shiny Live](https://github.com/posit-dev/py-shinylive) for example has an easy `shinylive export myapp site` command that turns the app into a folder I can upload to my nginx server. Whereas for now, wasm notebooks seem to require using `marimo.app`. Is there a plan to have an export option someday? Thanks!

[dmadisetti]

So I feel like islands is (are?) pretty close. But there are a few options for completion:

• Would exposing MarimoIslandGenerator.from_file to the CLI count?

Conversely, adapting some of my solutions:

• The quarto plugin I made can export to standalone HTML/ PDF/ whatever. It can also just use raw pandoc. quarto/ pandoc will extract images into a folder and allows general templates. Releasing this under marimo-teams gives export capabilities without the dev overhead of putting in templating/ managing exports. This could be a standalone repo or live in marimo, since it just needs the root folder _extension

• Aside but food for thought: I also have a mkdocs plugin that's a fork of https://jspaezp.github.io/mkquartodocs/ but it's highly personalized atm- only works with the markdown format and uses nix for sandboxed dev environments. Also mkdocs is not a general export

  ---

  There also could be a hybrid solution that leverages quarto, but exposes a cli endpoint: marimo export myapp site / marimo export myapp pdf

[akshayka]

I do know we want this in the CLI, but I don't have a strong opinion on what the right solution is.

Which option do you think our users would be best served by?

[dmadisetti]

I think starting from islands from file export, and then potentially expanding or pivoting based on user feedback.

I haven't seen anyone explicitly calling for quarto or a more advanced export, so starting with base functionality seems like the first best step

[mscolnick]

I wonder if leveraging quarto and other SSG frameworks is better overall.

My hesitation by adding this to the CLI as-is, would lead to more issues and feature-bloat around customizing the title/color-sheme/meta-tags/open-graph tags, etc.

whereas @dmadisetti's quarto plugin opens up a world of possibilities in the quarto ecosystem

[akshayka]

I wonder if leveraging quarto and other SSG frameworks is better overall.

Ok, that would be fine too.

Releasing this under marimo-teams gives export capabilities without the dev overhead of putting in templating/ managing exports. This could be a standalone repo or live in marimo, since it just needs the root folder _extension

I'd be down to release as a standalone repo under marimo-team, maybe that would be easiest?

As far as marimo is concerned then, we could simply add documentation to docs.marimo.io telling users how to use the the quarto plugin.

@dmadisetti, is this something you'd like to do? If so I can create a repo (what should it be called?).

[dmadisetti]

Sorry about that, thought I responded.

Here are the options for export:

1. Make islands export more robust.

• pros: tightly coupled with marimo (slight plus)
• cons: more surface area to cover (big down side)
• implementation: just a cli flag for marimo

---

2. Create a quarto extension

• pros: outsources the formatting specific to widely used platform
• con: form of vendor lock for users. users will be required to use quarto specific export methods
• implementation: just needs a _extension folder in root where the extension code is contained. installation will then be quarto add marimo-team/<repo>. For instance, if marimo root was used then quarto add marimo-team/marimo. Note this doesn't install deps, marimo has to still be installed on top of this. It might be possible to bundle a zip of marimo with this, but it would be coupled to the quarto extension installation and not the same as whatever is installed locally. (although maybe we can add some checks to mitigate any confusion)

---

3. As a pure pandoc solution

• pros: a little bit more flexible than quarto due to quarto due to ubiquity (pandoc is a dep of quarto)
• cons: less user friendly than to directly use with quarto
• implementation: there are libraries like panflute that allow for pure python distribution. pip install marimo-pandoc (or whatever the package is called), would install marimo, and place the pandoc filter files in the pandoc path for usage.

---

4. Integrated with mkdocs

• pros: flexible like quarto, optionally no pandoc dependency
• cons: vendor lock problem again- also, markdown only export
• implementation: I don't have a public implementation of this, but it's pretty straight forward. We can do a mkdocs extension that will produce rendered markdown outputs through mkdocs. distributed via pip install marimo-mkdocs

---

It's possible to create another repo that includes options 2,3, and 4 of the export options. http://github.com/dmadisetti/quarto-marimo couples 2 and 3, minus the panflute distribution. My local implementation of the mkdocs plugin leverages the marimo quarto integration, but it could easily be stripped out.

Going further?

For renderable exports in github, I think a GH action that utilizes the chosen option/s above would be ideal. Options can be to export as markdown or PDF

[akshayka]

@dmadisetti — 2 sounds great to me, since you already have an implementation of it, and since Quarto appears to be loved by the community.

How should we proceed? If you like, you're welcome to transfer quarto-marimo to the marimo-team organization, or I can create a new repo in marimo-team, or you can create a PR that adds the _extension folder to the marimo repo ... You would know best.

[akshayka]

Another option to consider is Myst: https://mystmd.org/guide/quickstart. It recently became part of project Jupyter (https://github.com/jupyter-book/mystmd), and was used for the Scipy 2024 proceedings. I have heard that it is comparable to Quarto.

[dmadisetti]

I've looked at Myst a little before. Their exports look interesting, it's not pandoc based

Their standard is a little different from everyone else and also supports things like inline eval. References might be something that marimo could think about providing greater integration for