Deepnote, a Jupyter alternative, is going open source

Original Article ↗ Hacker News Discussion ↗

Positioning Deepnote as “Jupyter’s Successor”

  • Many commenters find the “successor” claim presumptuous and misleading, since Deepnote has no formal relationship with the Jupyter project and Jupyter is still very active.
  • The launch post’s tone (especially early versions) is widely criticized as disrespectful to Jupyter: cherry‑picked contribution graphs, job‑post statistics with dubious framing, and a vibe of “Jupyter is dying, we’re its replacement.”
  • Several people suspect the blog post was written or heavily shaped by an LLM and then quietly edited after backlash, which further hurts trust.
  • General sentiment: the tech might be interesting, but the messaging alienates the exact developer community they’re trying to win over.

Deepnote’s Offering and Open Source Move

  • Some users say Deepnote has long been the nicest Jupyter UI, but locked behind a cloud subscription; open‑sourcing under Apache 2 is praised.
  • Others note confusion: the repo doesn’t yet seem to expose a fully runnable local notebook environment; key pieces are “coming soon.”
  • Deepnote argues notebooks must be reactive, collaborative, and “AI‑ready,” and that this requires a rich project format (YAML + metadata, secrets, multiple block types) beyond plaintext.
  • Skeptics question real‑time collaboration demand (most want git‑style workflows) and dismiss “AI‑ready” as marketing buzz.

Jupyter: Strengths, Weaknesses, and Alternatives

  • Defenses of Jupyter: still “best in class” for many, especially via VS Code; excellent for teaching, ad‑hoc analysis, and REPL‑like workflows where long precomputation is reused.
  • Critiques:
    • .ipynb mixes code and outputs (huge base64 blobs), making git diffs painful.
    • Hidden kernel state causes non‑deterministic behavior and confusion.
  • Tools like nbconvert and jupytext partly address these problems. Some say Jupyter doesn’t need a “successor,” just better practices.

Marimo as the De‑Facto Successor (in the Thread)

  • Marimo is repeatedly recommended as the real Jupyter successor. Praised features:
    • Notebooks as plain .py files (git‑friendly, no embedded output).
    • Optional reactivity with deterministic execution and no hidden state.
    • UI amenities: multi‑column layout, interactive widgets, DataFrame viewers, SQL cells, LLM integrations.
    • Static web export via WASM.
  • Downsides: currently Python‑only; some dislike losing persistent “messy state” workflows; recent acquisition by CoreWeave raises enshitification/lock‑in concerns.

Broader Notebook vs Script / Standardization Discussion

  • Ongoing tension: some prefer plain scripts for simplicity and portability; others view notebooks as superior REPLs and narrative/teaching tools.
  • Several argue notebooks should compile to high‑quality, static, executable HTML for publication, not be the final artifact themselves.
  • Concerns are raised about corporate control of de‑facto standards vs nonprofit stewardship like Jupyter’s, and about startups using “successor” language as marketing rather than community consensus.