Notebook Environments in 2026 — Jupyter / Marimo / Quarto / Observable Framework / Deepnote / Hex / Positron Deep Dive

Prologue — The word "notebook" points to too many things

In 2026, when a data analyst, an ML engineer, a student, and a researcher all say "notebook", they actually mean four different tools.

• Classic notebooks — Jupyter Lab 5 / Notebook 7, VSCode Notebooks. Cells run top-to-bottom, state lives in the kernel.
• Reactive notebooks — Marimo, Observable Framework, Pluto.jl. Cell dependencies are tracked as a graph; change one cell, downstream cells re-run automatically.
• Publishing systems — Quarto, R Markdown, Curvenote. Render notebooks into PDFs, HTML, papers, books.
• Collaborative SaaS — Deepnote, Hex. Cloud-hosted, team editing, sharing, scheduling.

These four categories sometimes share the ".ipynb" extension, but they solve different problems. And as of 2026, none of them has absorbed the others — competition has only intensified within each category.

This article maps that territory. The consolidation in the Jupyter camp, Marimo's challenge, the publishing pipeline Quarto built, Observable Framework's static-site bet, and the two SaaS axes (Deepnote / Hex). Finally, how Kakao, Toss, Mercari and ZOZO actually use them.

1. The 2026 Notebook Map — Four Categories

Key insight: comparing one category against another using the single word "notebook" always produces wrong conclusions. Saying "Marimo is better than Jupyter" only makes sense in reactive-vs-classic terms; saying "Hex is better than Quarto" mixes categories entirely.

Another insight: language ecosystems decide half the choice. R users naturally flow into RStudio / Positron / Quarto. Julia users into Pluto.jl. JS/D3 users into Observable. Python lives in every category — which is why Python users have the most options and the most confusion.

2. Jupyter Lab 5 + Notebook 7 — The Standard Settles

When JupyterLab 5 shipped in 2024, the Lab 4-era legacy (the old extension system, jupyter-server conflicts) was finally cleaned up. As of 2026, Lab 5 reliably delivers:

• Federated extension system — extensions install via pip without npm builds.
• JupyterLab Desktop — an Electron-based standalone app, no Anaconda dependency.
• Real-time collaboration (RTC) — y-py-based simultaneous editing, stabilized from Lab 4's experimental tier.
• AI assistant integration — jupyter-ai 4.x makes cell-level LLM calls a first-class citizen.

Notebook 7 is "the Classic Notebook UI on top of Lab". The UI looks like old-school Jupyter, but the backend is the same jupyter-server as Lab. It survives because the education market still finds the Lab UI overwhelming.

The lingering problem — Hidden state

Jupyter's structural weakness is cell execution order. You've seen this:

# Cell 1
x = 10

# Cell 2
y = x * 2

# Cell 3
x = 100  # added later

Run cells 1, 2, 3 in order and y is 20. Save the notebook, reopen, run cell 3, then 2, then 1, and y is 200. Same notebook, different result. That is hidden state.

Worse, deleting cell 3 leaves x = 100 in kernel memory. You don't know the truth until you click "Restart kernel and run all". Once a data analysis report falls into this trap, the result is "analysis that doesn't reproduce".

The problem has been documented since 2018, and many solutions appeared (papermill, nbdev, jupytext). In 2024, Marimo answered it head-on: "Then let's rewrite the runtime to be reactive."

3. Marimo (Launched June 2024) — Reactive + .py File Format

Marimo was built by Akshay Agrawal and Myles Scolnick. Public release in June 2024, seed round closed the same year. Two core ideas:

1. Reactive execution graph — variable dependencies between cells are tracked; change one cell and every downstream cell re-runs automatically. Like a spreadsheet.
2. .py file format — the notebook is plain Python, not JSON. Git diffs are clean, and the file is importable from any IDE.

# my_notebook.py — Marimo notebook
import marimo

__generated_with = "0.10.0"
app = marimo.App()


@app.cell
def __():
    import pandas as pd
    return pd,


@app.cell
def __(pd):
    df = pd.read_csv("data.csv")
    return df,


@app.cell
def __(df):
    df.describe()
    return

The whole notebook is one .py file. Because cell inputs are explicit function arguments, the dependency graph can be tracked statically.

Hidden state disappears

• Create x = 100 in cell 3, and the cell using x (cell 2) re-runs automatically, giving y = 200.
• Delete cell 3 and x is gone. Any other cell referencing x shows an error immediately.
• "Restart and run all" is unnecessary. At every moment the visible state equals the code.

Extras

• marimo run — turn the notebook directly into an interactive web app, no Streamlit wrapping required.
• marimo edit — editing mode with a Lab-like UI.
• WASM runtime — runs in the browser via Pyodide, share notebooks without a server.
• AI assistant — Claude / OpenAI model integration, cell-level calls.

Limits

• Smaller ecosystem than Jupyter. ipywidgets compatibility is partial.
• The "one cell = one function" structure feels awkward if you're used to global variables.
• Redefining the same variable in two cells is an error — unlike Jupyter where "the last cell wins".

Marimo's position in 2026: it has not replaced Jupyter, but it has become a frequent default for new ML/data projects — especially in research labs and MLOps teams that care about reproducibility.

4. Quarto (Posit) — Unified R / Python / Julia Publishing

Quarto is the next-generation publishing system Posit (the new name for RStudio Inc., since 2022) introduced. It started as a successor to R Markdown, but by 2026 it can mix R, Python, Julia and Observable JS in one document.

.qmd — the source of everything

---
title: "Monthly Sales Analysis"
format:
  html:
    toc: true
  pdf:
    pdf-engine: xelatex
  docx: default
---

## Load data

```{python}
import pandas as pd
df = pd.read_csv("sales.csv")
df.head()
```

## Visualize

```{r}
library(ggplot2)
ggplot(df, aes(month, revenue)) + geom_line()
```

Mix Python and R cells in the same .qmd, then quarto render to HTML / PDF / Word / EPUB. Academic papers (quarto-academic), books (Quarto Book), websites (Quarto Website) all build from the same tool.

A layer on top of Pandoc + Jupyter

Internally, Quarto runs cells via Jupyter kernels, serializes the result to Pandoc Markdown, and lets Pandoc emit the final format. Quarto is not a new notebook runtime — it's a publishing orchestrator.

Where it sits in 2026

• The new standard for university statistics courses — almost completely absorbed R Markdown.
• The dominant way data scientists ship results — Jupyter notebook to PDF, mostly Quarto-powered.
• Government and finance reports — PDF output is a first-class target.

Limits

• Builds are slow. The Pandoc + LaTeX chain is heavy.
• Interactive components depend on Observable JS or Shiny — Quarto's own widgets are weak.
• Initial setup is painful — quarto CLI + TinyTeX + language runtimes.

5. Observable Framework — Mike Bostock's Static-Site Generator

In 2024, Mike Bostock (D3.js author, Observable founder) released Observable Framework, built around the idea "notebook equals static-site generator". It is a separate open-source project from the existing Observable Cloud (the hosted notebooks on observablehq.com).

Core idea — data loaders

• Markdown files with JavaScript code cells.
• At build time, "data loaders" (Python, R, shell — any language) run and serialize results to static JSON or Parquet.
• The client visualizes that static data with D3 and Plot. No server runtime at all.

---
title: Sales dashboard
---

```js
const sales = FileAttachment("data/sales.parquet").parquet();
```

# Monthly revenue

```js
Plot.plot({
  marks: [
    Plot.line(sales, {x: "month", y: "revenue"})
  ]
})
```

A sibling file data/sales.parquet.py runs at build time to produce the data.

Who is it for

• Data journalists — used by graphics teams at NYT, FT and similar outlets.
• Internal dashboards — static site, so hosting is cheap and fast.
• Teams that don't want to build a BI tool but won't compromise on visualization quality.

Limits

• It is more "static-site builder" than "notebook". Not an interactive analysis tool.
• Python and R live inside data loaders only. The main flow is JS.
• D3 and Plot have a steep learning curve.

As of 2026, Observable Framework is becoming the new standard when visualization is the main deliverable. People don't use it for everyday analysis.

6. Deepnote — Collaborative Cloud Notebooks

Deepnote is a Czech-American SaaS founded in 2019. OpenAI participated in a follow-on Series B in 2024-2025. Its core value is collaboration.

Features

• Browser-based simultaneous editing — Google Docs style.
• Direct connections to Snowflake, BigQuery, Postgres; SQL runs from a cell.
• Chart cells — drag-and-drop visualizations without code.
• Scheduled notebooks — run a notebook on a cron-like schedule.
• Permission model — workspaces, projects, cell-level controls.

Who uses it

• Data scientists who need to share with PMs and analysts.
• Companies steeped in the Notion + Slack culture — Deepnote fits that flow.
• "Send me last week's Snowflake query results every Monday" requirements.

Limits

• Lock-in — .ipynb export works, but chart cells, variables explorer, and similar features are Deepnote-only.
• Price — team plans start around $30+ per user per month.
• Heavy compute happens elsewhere — large GPU jobs run on Modal / Beam and only results flow into Deepnote.

7. Hex — Data Scientist SaaS

Hex (San Francisco, founded 2019) is Deepnote's direct competitor. Snowflake reportedly took a stake in 2024. The positioning rhymes, but the emphasis differs.

Hex's differentiators

• Hex Magic — the smoothest cell-level AI assistant. SQL to Python conversion, chart generation, debugging.
• App mode — deploy a notebook straight as an interactive app. A Streamlit alternative.
• Magic SQL — natural language to SQL, dbt model awareness.

Limits

• Pricier than competitors — enterprise focus.
• Weak sales presence in Korea and Japan — English-speaking customers first.

8. Curvenote / Polars Notebook / Pluto.jl — Notables in the Long Tail

Curvenote

Notebook plus collaboration tool specialized for scientific publishing. Built on MyST Markdown (a scientific extension of Markdown) with first-class support for citations, equations and figure labels. Workflow targets PDF submission to arXiv or a journal.

Polars Notebook

A new notebook project announced by the Polars (fast DataFrame library) team in 2025. The Rust backend handles in-memory DataFrame operations quickly, and SQL, Python and Polars expressions mix smoothly in one notebook. Still in beta.

Pluto.jl

The reactive notebook of the Julia ecosystem. It has implemented Marimo's philosophy (cell dependency graph, .jl file format) in the Julia world since 2019 — Pluto.jl is Marimo's senior. For Julia users, it is essentially the default.

Jupytext

Two-way conversion between Jupyter .ipynb and .py / .md / .Rmd. The answer for teams that want to keep Jupyter but enjoy clean git diffs. It was the most common solution before Marimo arrived, and is still widely used.

9. VSCode Notebooks + Positron (Posit, May 2024) — IDE Notebooks

VSCode Notebooks

VSCode has had first-class .ipynb support since 2020, and by 2026 it is essentially feature-equivalent to JupyterLab. The Python extension + Jupyter extension combo handles cell execution, debugging, variable inspector and plot viewer. AI assistant integration (Copilot, Cursor, Cline) is the most natural here — that is the dominant reason people pick VSCode for notebook work.

Positron — RStudio's successor

Posit unveiled Positron in May 2024 as the next-generation IDE. Where RStudio was R-centric, Positron treats R and Python as equal. Built on a fork of Code OSS (the open-source base of VSCode).

Highlights:

• R and Python consoles live as separate panels, always present.
• Data viewer — inspect DataFrames like a spreadsheet.
• Plot viewer — chart history is managed in the side panel.
• Jupyter kernels run inside the IDE.
• 1.0 GA shipped in 2025, stable through 2026.

Where users land

10. The "Hidden State" Problem and the Reactive Answer

Hidden state is the notebook's deepest trap. To restate:

What the problem actually is

1. Cells can run in arbitrary order.
2. Kernel memory outlives the code — variables persist after their defining cells are deleted.
3. When the same variable is redefined across multiple cells, the code alone can't tell you which definition is active.

Put together, you arrive at a state where you cannot confidently answer "if I rerun this notebook from scratch, do I get the same result?"

Solution 1 — Discipline (Jupyter camp)

• Always "Restart kernel and run all" before committing.
• One cell, one function; minimize globals.
• Lint with nbQA (ruff / black); use nbdev to turn notebooks into libraries.
• Weakness: depends on human willpower. Breaks in practice.

Solution 2 — Reactive runtime (Marimo / Observable / Pluto.jl)

• Cell dependency graph is tracked statically.
• Change one cell, every downstream cell re-runs.
• Variable redefinition is an error — ambiguity removed.
• Result: the visible cell state always equals "the output if I ran the code from scratch".

Solution 3 — Separate the persistent artifact (Quarto / Papermill)

• The notebook is the input; the rendered HTML / PDF is the output.
• "The final artifact is what the renderer produced by running cells start-to-finish" is the contract.
• Weakness: doesn't fit interactive exploration.

The 2026 consensus: reactive for research and analysis, Quarto for publishing, Jupyter for learning and experiments. One tool does not do all three.

11. R Markdown to Quarto Migration

When Posit shipped Quarto in 2022, R Markdown moved into maintenance-only mode — new features land in Quarto. By 2026, R users have nearly completed the migration.

Migration map

Conversion tools

• quarto convert input.Rmd — automatic conversion. Simple .Rmd files work almost as-is.
• More complex cases (custom output formats, child documents) need manual work.

Why migrate

• New features (quarto-dashboard, Observable JS integration) only land in Quarto.
• Python / Julia users can share the tool with R users — useful when both languages live in the same company.
• Improved PDF output quality — a Typst backend is now available.

12. Korea and Japan — Real-World Patterns

Kakao — data notebook environment

Kakao's data org runs JupyterHub on internal Kubernetes. Per-user containers, automated GPU request/release, S3-compatible object storage integration. In 2024-2025 they integrated jupyter-ai to enable cell-level LLM calls; since 2026 some teams have piloted Marimo.

Notable detail: the internal data workflow system (Airflow + DataHub) is separate from the notebooks, so any notebook analysis must be ported to an Airflow DAG to be promoted to production. This is a common Korean enterprise pattern.

Toss — analytics environment

At Toss, data analysts work primarily in SQL; notebooks come in only when going deeper (cohort, anomaly, ML experiments). JupyterHub plus an in-house BI tool (Querypie family) is the standard stack. Job postings in 2025 hinted at a Hex pilot — Magic SQL and collaboration features are attractive to a SQL-first analyst.

Mercari — data team

The Tokyo headquarters data team has long used GCP — BigQuery plus Vertex AI Workbench (GCP's hosted JupyterLab). Since 2024 some teams have adopted Deepnote where collaboration and scheduled notebooks are needed, especially in BI. Quarto has been adopted as an internal research-report standard, per a published engineering blog.

ZOZO — data and MLOps

ZOZO Research (ZOZO's R&D org) runs ML experiments on JupyterLab plus Kubeflow Notebooks on internal GPU clusters. Conference-publication results are organized through Quarto — one pipeline all the way to PDF submission. Some recommendation-system papers published in 2026 came with the original notebooks open-sourced.

Shared APAC patterns

• Large-scale operations: JupyterHub on Kubernetes, managed by the in-house platform team.
• Collaboration-critical analysis: Deepnote / Hex — but English-first companies adopt faster.
• Publishing and papers: Quarto — especially strong in the Japanese academic R community.
• Marimo: early-adopter stage in 2026, growing adoption in greenfield projects.

13. Who Should Pick What

By situation:

Students / coursework

• First Python data analysis course: Jupyter Lab 5 (or Google Colab).
• Statistics / R course: RStudio or Positron, submit assignments via Quarto.
• Reproducibility-focused course: Marimo — prevents hidden state from ever being a problem.

Personal data analysis

• Quick look, in and out: Jupyter Lab 5 + jupytext (clean git diffs).
• Publish results as PDF / blog: Quarto.
• Visualization is the deliverable: Observable Framework.

ML research

• Reproducibility + experiment tracking: Marimo + Weights & Biases / Aim.
• On a cluster GPU: JupyterHub on Kubernetes (internal) or Vertex AI Workbench / SageMaker Notebooks (cloud).
• All the way to a paper: Quarto + LaTeX.

Team collaboration

• Small team, free-tier first: Jupyter Lab 5 RTC.
• Data scientist + analyst collaboration: Hex or Deepnote.
• Analyst + PM sharing: Deepnote (UI friendlier for non-technical users).

Data journalism / interactive visualization

• Observable Framework — done.
• Runner-up: Quarto + Observable JS.

Publishing / papers / books

• Quarto — for any of R, Python, Julia.
• Scientific publishing specialist: Curvenote.

R users

• Positron (or RStudio) + Quarto. That is the 2026 answer.

Julia users

• Pluto.jl + Quarto.

"If I have to pick exactly one"

• Python · general analyst: Jupyter Lab 5 + Quarto.
• Python · new project + reproducibility: Marimo.
• R: Positron + Quarto.
• Team + company budget: Hex or Deepnote.
• D3 enthusiast: Observable Framework.

14. References

Jupyter

• JupyterLab Documentation
• Jupyter Notebook 7 announcement
• JupyterLab Desktop
• jupyter-ai

Marimo

• Marimo official site
• Marimo GitHub
• Marimo launch announcement (2024-06)
• Marimo Why blog

Quarto / Posit / Positron

• Quarto documentation
• Quarto Dashboards
• Positron IDE
• RStudio rebrands to Posit
• R Markdown to Quarto migration

Observable

• Observable Framework
• Observable Plot
• Mike Bostock - Why we built Framework

Deepnote / Hex

• Deepnote
• Hex
• Hex Magic AI

Other

• Curvenote
• Pluto.jl
• Polars Notebook
• Jupytext
• Papermill
• nbdev

Comparisons / commentary

• Marimo vs Jupyter (Marimo blog)
• Joel Grus - I Don't Like Notebooks (2018 JupyterCon talk)
• Quarto vs R Markdown (Posit blog)

Korea / Japan case studies (blogs / talks)

• Kakao data analysis environment (tech.kakao.com)
• Toss data engineering (toss.tech)
• Mercari Engineering Blog
• ZOZO Tech Blog