Roadmap to V1

[mscolnick]

We're building a unified toolchain for working with data. On the road to marimo version 1.0, we'll focus on enabling the following goals:

1. Rapid data manipulation with Python and SQL
2. Excellent developer experience in the marimo editor
3. Excellent developer experience working with notebook files
4. Seamless embedding of notebooks in web pages and sharing notebooks as applications
5. Working with data and compute at any scale
6. Enterprise-readiness

Here's a breakdown of our roadmap, organized into these categories.

Rapid data manipulation

• Reactively respond to non-python file changes (e.g. parquet, csv, json)
• More comprehensive parsing of the SQL dataflow graph More comprehensive parsing of the SQL dataflow graph #3103
• Support multiple SQL dialects Support multiple SQL dialects #3201
• Easily connect to or import data from databases, open tables, and blob storage
• Interactive domain-specific elements for machine learning and data science, such as an array viewer
• High-performance interactive dataframe viewer - dataframe viewer's column chart are aggregated on the backend Dataframe viewer's column chart are aggregated on the backend #3104
• High-performance datasource panel - datasource panel's column chart is aggregated on the backend Datasource panel's column chart is aggregated on the backend #3105

Developer experience in the marimo editor

We'll be working on improving our code intelligence, including more robust code completion and the addition of type-checking and linting; on adding real-time collaboration to the editor; building out more AI assistance features; and improving usability across the board.

Code Intelligence

• Language Server Protocol support
  • Add pyright type-checking #1163
  • provide some way to show all fields with tab completion based on runtime info, ignoring type annotation #1963
• Improved go-to-definition
  • go to declaration does not work within def #1430
• Variable renaming
• Built-in LSP servers: ruff, pyright

Multiplayer

• Real-time collaboration
• Local network sharing Export marimo on the local network, and print to the console #3106

AI integration

• Chat sidebar panel Chat sidebar panel #3084
• AI inline edits Highlight text for AI inline edits #3085
• Custom models for AI autocompletion
• RAG marimo docs and common libraries

General Usability

• Improved error messages in the UI Improved error messages in the UI with clear call-to-action when there are errors #3110
• Improved error messages in the terminal Improved error messages in the terminal #3111
• Auto-fix for common errors
• Migrate to react-aria-components for better ARIA/accessibility.
• Multi-column notebooks Multi-column notebooks #3112 experimental: multi-column notebooks #2531
• Helper panel for previous cell runs (times, success/failure) Display cell run history #2898
• Easier installation of optional dependencies that enable SQL support (duckdb), AI features (openai/anthropic), Charting (altair), Charting performance (vega-fusion) Easier installation of optional dependencies for the marimo editor #3113
• Improved UX when auto-instantiate (no autorun on startup)
  • Redesign initial page when auto-instantiate is off #3083
  • Add app-level configuration for autorun on startup #2885
  • Register cells with graph when autorun on startup is disabled #2983
  • Serialize outputs in separate file so app can be viewable when auto-instantiate is off #3082

Developer experience working with notebook files

Working with the marimo notebook file

• Direct editing of notebook files in your text editor of choice, with side-by-side rendering of notebook outputs Direct editing of notebook files in your text editor of choice, with side-by-side rendering of notebook outputs #3114 Reload the notebook when the file changes on disk #2675 Live refresh of marimo based on watching the filesystem #1511
• Top-level functions in notebook files app.function: top-level functions in notebook files #2293
• Making the notebook file work better with type checkers and linters
  • Make generated Python files mypy error-free #2325
• Making it possible to declare arguments, with autogenerated CLI help, for notebooks that are run as scripts
• VSCode plugin

Package management

• Full implementation of PEP 723-style metadata, tightly integrated with the uv package manager Respect python version declared in inline-scripts (PEP 723) when running with --sandbox #3115

Configuration

• pyproject.toml support for [tool.marimo] Support configuration overrides in a pyproject.toml #3069
• App-level configuration overrides / partial configuration Add app-level configuration for autorun on startup #2885

Publishing notebooks and sharing data apps

Sharing notebooks on GitHub

• GitHub viewer
  • marimo export ipynb should include outputs, cell order, and other metadata #2960
  • auto-download for marimo ipynb #2961
• GitHub pages
  • marimo export html-wasm --mode=read|edit marimo export html-wasm --mode=(read|edit) #3116

Static-site generation

• Export to ipynb for compatibility with existing tools
• Export to markdown with --include-outputs

Building and deploying data apps from marimo notebooks

• Improvements to deploying marimo notebooks as apps via FastAPI
  • create_asgi_app: Marimo server mounted to non-root fails to fetch resources #2938
  • improvement: add asgi middleware to create_asgi_app #3095

Working with data at any scale

Execution

• Remote execution (bring-your-own-backend)
• Improve WebAssembly cold starts
• [exploratory] Async/concurrent execution
• [exploratory] Parallel execution Parallel Execution #1103
• [exploratory] Distributed (”hybrid”) execution
• [exploratory] Parametrized/batched execution

Caching

• Remote caching for mo.persistent_cache()
  • S3 backend
• Caching robustness
• Object serialization options (pickle, parquet)
• Cache storage format (file, SQLite)
• [exploratory] Resuming notebooks after they have been shutdown
  • Opt-in cell-level caching

Memory Consumption

• Lazy construction of various objects

Tracing

• Execution tracing/telemetry and identifying slow cells Display cell run history #2898

Pipelines

• Proof-of-concept implementation using marimo notebooks in pipelines
• Integration with Airflow

Enterprise-readiness

Stability

• Internal: better visual snapshot testing for visual regressions
• Internal: more comprehensive testing for performance regressions

Security

• Secret management
• Notebook trust model

Instrumentation

• Custom OTEL instrumentation hook
• Custom logging
• Metrics collection/endpoint
• Custom scripts (e.g analytics) feat: add html_head_file to inject custom head scripts into the app #2926

[raspharaoh]

• Quarto, Zotero plugin or other reference manager.

Better support for references in aid of reproducibility. There is a feature in Marimo where typing a colon ':' produces an icon/emoji list to choose from. It would be good if there was a more general way or another hotkey to produce a popup custom list from a file of items.

Best wishes for 1.0.

[Haleshot]

Community

Integrations

Would be nice to have a hugoblox plugin; although I wonder if you can do something readily now (as it works well with markdown; renders mermaid diagrams well in blog posts).

Shareability

• Have a recommended way to write blog posts powered by marimo easily

I'd really like to shoutout Weights and Biases's (wandb) way of writing reports/blogs where you can see how they display their plots (interactive); good example of dogfooding?

[alexscordellis]

First of all I want to say I'm very excited about marimo. It's giving me very strong "polars circa late 2021" vibes: clearly a better solution shape to the problem than the incumbent, but a few rough edges mean it's not quite ready for primetime yet. Hopefully some of these get ironed out and I look forward to watching it spread across teams in my company the way that polars has over the last couple of years.

From trying marimo as a replacement for JupyterLab over the last few weeks, here are some improvements I would love to see and which would help with adoption.

1. Rendering of large dataframes Rendering large dataframes often crashes my browser. I think this is because marimo currently renders dataframes to JSON on the server then sends this to the browser. I often work with dataframes with millions or tens of millions of rows, to which this approach doesn't scale. Of course I can call .head() before rendering, but this is a new habit to learn and currently the penalty for forgetting is a hard reload of all marimo tabs, which is just too large. The dataframe rendering is a cut above that in Jupyter: the little histograms (especially the null counts) are super useful, as is the ability to page through a small dataframe in the browser - this beats hunting for the relevant rows with .filter(). So I'd hope server side paging can retain all those features while handling large dataframes better.
2. Ability to clear cell outputs independent of computation state I often have many interactive plotly charts rendered in a notebook session. At some point this becomes too much for the browser and plotly starts misbehaving. The solution in JupyterLab is to clear the outputs you aren't looking at any more. In marimo, the only way I can find to do this is to comment out the contents of the relevant cell and re-run it, which isn't good for reproducibility, and can break the dependency graph if those cells exported variables. I'd like marimo to let me (by mouse or keyboard shortcut) clear the display of the cell output (either individually or for entire notebook) without changing the state of the variables the cell(s) defined.

These first two items above are blocking me from moving to marimo as my default notebook engine. The issues here are likely common to many of my colleagues so I think addressing these would really enable wider adoption:

Further suggestions:

1. Run all prerequisites of this cell. If I open a notebook I've not used in a while, often it's to look at one particular chart or other output. Right now I have to work out for myself which cells I need to run first to get to the one I'm after. It would be great if I could just find the relevant cell and click "run all predecessors and this", and it would run the minimal set of predecessor cells. This feels like a great way to make the most of marimo's execution model.
2. Cell runtime history. Something I miss from JL (specifically from https://pypi.org/project/jupyterlab-execute-time/) is being able to see how long a cell took on previous executions. It's really useful to know how long to expect a cell to take before triggering execution. (I can also think of cool ways to combine this with the execution graph e.g. "to get to this cell from the initial state takes X minutes").
3. Display the time at which cell was last run Useful if you've altered some external state e.g. data files on disk, and you want to know which of your cells have been run since.
4. Configure copilot to go via a proxy I work on machines without a direct internet connection, but have access to proxies to allow copilot to connect from e.g. vscode, JetBrains IDEs. Would be great if I could do the same from marimo.

I hope that's helpful, and look forward to seeing marimo grow and develop.

[akshayka]

I can reproduce an issue with rendering dataframes with many columns (~10k), but the number of rows has no effect on performance in my reproduction. @alex-scordellis-izone, I'd be curious if your performance issues are also with wide dataframes, or if you've hit performance issues with narrow dataframes as well (~100 columns or fewer).

EDIT: Reproduction is here - #2991

[AdrienDart]

Hi, I also get the issue with rendering large dataframes that crash the browser tab (sometimes with less than 50 columns). I don't have any reproduction unfortunately.

[mscolnick]

@AdrienDart - what version are you on? the latest version should have a fair amount of improvements for this.

@alex-scordellis-izone, can you also try the latest marimo version (0.9.29) with your large dataframes.

[akshayka]

@alex-scordellis-izone, have you gotten a chance to try the latest version of marimo with your large dataframes? We're very curious to hear whether you are still hitting performance issues.

[AdrienDart]

Hi, sorry for the late reply. I can say that browser crashes have been less frequent but do sometimes happen with a lot of dataframes displayed (sometimes along altair charts) and a few Marimo notebooks open. Quick question for you, when I want the uncropped version of a table, should I use . pipe(mo.ui.table, max_columns=None) or is there an easier way to achieve this? Shall we get at some point a toggle near each table to change page size (as pycharm gives us the option, see (https://www.jetbrains.com/help/pycharm/settings-tools-database-data-views.html#limitations)) or number of columns displayed?

[michaelsch71]

Wow, looks like a very ambitious and promising roadmap. I already love marimo and I am really looking forward to what the future will bring. Since you have mentioned the plugin for VSCode I personally would like to see a plugin for PyCharm as well, which I feel like is one of the goto IDE's for python developers.

I'm looking forward to see what the future of marimo will bring. Thanks for all your passion for this amazing project!

[solarslurpi]

A model context protocol client. How amazing this will be to be able to plug in our data sources and use AI on them. The client should be able to be configured not just with paid LLMs like Claude and OpenAI, but Ollama so that easy integration with fairly powerful locally run LLMs are supported.

Marimo is very exciting. Thank you for a brief moment of sunshine.

[AdrienDart]

Hi,

Congratulation on your latest funding! Well deserved!

I have a few suggestions for you on top of the already mentionned ones. Apologies in advance if some of the features are already implemented.

1. A toggle button on each cell to trigger a plain mode (to avoid resorting to mo.plain manually)
2. The ability to copy to the clipboard lists, dataframes, columns of dataframe, plots
3. %%timeit magic
4. Multiple cells selection/operation (to then delete, move, copy, cut, paste, etc.)
5. Some debugging features
6. Set the default number of lines displayed in the dataframe as a setting
7. Ability to add project dependencies (I currently add sys.path.insert(0,path_to_other_project) in the first cell of my notebook)
8. A terminal?
9. Tabs in a jupyterlab fashion

Thank you!

[schlich]

Piggybacking on number 8 above!

I know terminal-things are not on the v1 roadmap for what are likely very good and pragmatic reasons, and I wonder if this isn't the right space for "wish list" requests (if there is one, i'll be happy to move it there...)

... but. i think i MIGHT be able to die happy if marimo made a terminal emulator (Ha, ok, fine, fine, i'll settle for a TUI). If y'all can do anywhere close the same thing in the terminal as y'all did with the notebook experience, it'd be an incredible win.

Excel watch out? 🤤

Imagine the best of all worlds with me:

• The reactivity and ergonomics of Marimo
• The performance and stability of a modern Terminal e.g. Kitty/Wezterm/Ghostty
• Window Management and context switching e.g. Zellij
• Dataframe support and pipeline scripting w/ Nushell?
• Hotkey ergonomics of Helix/Kakoune (motions first!)
• Simplicity of Harlequin for a traditional catalog

... all on one package?
Sure would pay a hefty premium for that 😉

Regardless, lots of groundwork already laid! Seems like too many moving parts to manage via various plugin systems. Integrated is cooler anyways.

Thanks to the Marimo team for this amazing tool which has already had a seismic impact on my productivity. Very excited to see what the future holds.

[codemee]

I'd like to have a side by side layout that show just one code cell on left and the output on the right with pageup/down or other UI to nivigate prevous/next cell. This would be helpful for instructor to demo or teach coding. Thanks.

[mscolnick]

I think we could extend the Slides layout to do this, such that we can show the code of the cell that is being presented

[codemee]

That's cool. Wish that would happen soon.