Show HN: Marimo – un cuaderno reactivo de código abierto para Python

Artículo original ↗ Discusión en Hacker News ↗

Un proyecto de código abierto llamado Marimo se está posicionando como una alternativa reactiva a los cuadernos de Jupyter basada en Python, con el objetivo de corregir problemas de larga data como el estado oculto, la ejecución no determinista y el pobre control de versiones al almacenar los cuadernos como archivos `.py` normales y rastrear automáticamente las dependencias entre celdas. Los comentaristas están entusiasmados con su capacidad para combinar el trabajo exploratorio con un uso sencillo como app, y aprecian funciones como el grafo de dependencias, el visor de variables y futuras integraciones como WASM, depuración y herramientas de linting/formateo. Al mismo tiempo, señalan concesiones en flexibilidad, soluciones incompletas para entornos totalmente reproducibles y gestión de paquetes, algunos casos límite en el seguimiento del estado y asperezas en la integración con editores que deberán madurar.

Posicionamiento frente a herramientas existentes

  • Se lo ve como una alternativa a Jupyter/Pluto/Observable, con celdas reactivas y un formato de archivo puro .py.
  • Muchos quieren en el sitio un mensaje más claro, de nivel superior, “Jupyter vs Marimo”, no solo en las FAQ.
  • En comparación con Streamlit: Marimo admite primero la exploración clásica al estilo cuaderno y luego la exportación a apps compartibles.
  • Se menciona Quarto como una solución a algunos problemas de reproducibilidad, pero las celdas reactivas sincronizadas de Marimo se destacan como el principal diferenciador.

Reactividad, estado y reproducibilidad

  • El principal atractivo: elimina el estado oculto al ordenar topológicamente las celdas mediante un DAG de dependencias y volver a ejecutar las celdas afectadas cuando hay cambios.
  • A los usuarios les gusta que esto mejore el determinismo y haga que los cuadernos sean más fáciles de razonar y revisar (ya que son Python puro).
  • Algunos encuentran que tiene menos flexibilidad: a veces quieren ajustar una celda sin desencadenar una recomputación descendente.
  • El seguimiento del estado no es perfecto: mutaciones como d.x = "new value" en un dataclass actualmente no hacen que las celdas dependientes se vuelvan a ejecutar.

Empaquetado y entornos

  • Muchos consideran que capturar paquetes/entorno es “la otra mitad” de la reproducibilidad y quieren que los cuadernos incorporen información de dependencias.
  • Marimo tiene “gestión de paquetes para cuadernos reproducibles” en su hoja de ruta, pero todavía no hay un diseño concreto.
  • La discusión sobre flujos de trabajo con pip freeze señala problemas: instalaciones no hechas con pip, variantes específicas de plataforma, dependencias engordadas/obsoletas y mantenimiento manual.
  • Se mencionan alternativas como Poetry, pip-tools y Nix; las opiniones difieren sobre cuán doloroso es realmente el empaquetado en Python.

Despliegue, WASM y apps

  • Hay interés activo en un modo WASM/pyodide estilo JupyterLite para ejecución en el navegador, incrustación en MDX/Nextcloud y apps de “HTML independiente”.
  • El soporte para WASM está explícitamente en la hoja de ruta; la incrustación actual de documentación usa iframes.
  • A los usuarios les gusta que los cuadernos puedan convertirse en apps web simples, aptas para herramientas internas y tutoriales interactivos.

Integración con editores y UX

  • Existe una extensión de VS Code, pero actualmente abre una interfaz completa en el navegador en lugar de usar la interfaz nativa de cuadernos de VS Code; a algunos les resulta confuso el proceso de incorporación.
  • Hay preguntas sobre editar cuadernos .py en un editor externo y ver actualizaciones en vivo; esto se desea, pero aún no está soportado.
  • Los usuarios preguntan por tareas en segundo plano de larga duración que sobrevivan al cerrar la pestaña; el comportamiento actual no está claro.

Plugins, widgets y funciones

  • El sistema interno de widgets usa custom elements; todavía no hay una API pública de plugins, pero se planea una.
  • La herramienta está construida desde cero y no depende de Jupyter ni de IPython; la compatibilidad con Jupyter widgets es solo una idea por ahora.
  • Las funciones existentes incluyen un visor del grafo de dependencias, un visor de variables, integración con Copilot y planes para depuración basada en PDB y una mejor visualización del grafo.
  • Las solicitudes incluyen: diagramas mermaid en markdown, completado consciente del documento al estilo RStudio (se afirma que existe), mejores vistas previas en GitHub, caché a nivel de celda y un ámbito de variables más matizado (por ejemplo, para código de gráficos repetido).