Marimo Notebooks di PyCharm: Reproducible Python untuk Data Science Production 2026

Selama hampir satu dekade, Jupyter Notebook adalah pilihan default untuk data science Python. Hampir setiap tutorial, setiap kursus, dan setiap workflow data scientist menggunakan format .ipynb. Namun bagi mereka yang pernah mencoba melakukan code review pada notebook, melakukan merge conflict resolution, atau menjalankan ulang notebook orang lain enam bulan kemudian, kelemahan Jupyter sudah sangat dikenal. Marimo, yang sejak 2023 berkembang sebagai alternatif open source, kini mengumumkan integrasi native ke PyCharm — kombinasi yang membuat notebook reproducible menjadi realistis dalam workflow profesional.

Artikel ini membahas apa yang Marimo tawarkan secara berbeda, mengapa integrasi PyCharm signifikan, dan kapan lo sebaiknya mempertimbangkan migrasi dari Jupyter.

Masalah Reproducibility yang Diabaikan

Notebook Jupyter menyimpan kode dan output dalam format JSON yang merepresentasikan state eksekusi. Masalah mendasarnya: format ini stateful. Sel dieksekusi sesuai urutan, dan dependensi antar sel tidak dideklarasikan secara eksplisit. Hasilnya, sebuah notebook yang dikirim via email bisa gagal dijalankan oleh penerima karena:

• Sel dijalankan dalam urutan yang berbeda
• Variable didefinisikan ulang secara implisit di sel yang berbeda
• Kernel state sudah ter-reset atau berbeda
• Output tersimpan membuat notebook tampak berjalan padahal tidak

Untuk eksplorasi individual, ini bukan masalah besar. Untuk kolaborasi tim, untuk code review, untuk production pipeline, dan untuk reproducibility ilmiah, ini adalah masalah fundamental. Survei internal yang dirujuk oleh beberapa paper akademik menunjukkan bahwa sekitar 30-40% notebook Jupyter yang dibagikan tidak dapat dijalankan ulang tanpa intervensi manual.

Apa yang Berbeda dari Marimo

Marimo mengambil pendekatan yang secara filosofis berlawanan dengan Jupyter. Alih-alih notebook sebagai dokumen yang berisi sel-sel independen, Marimo memperlakukan notebook sebagai reactive graph: setiap sel adalah pure function dari sel-sel lain yang menjadi inputnya. Definisi ulang satu variabel secara otomatis menandai semua sel yang bergantung padanya sebagai stale, dan runner menjalankan ulang sel-sel tersebut sesuai topologi dependensi.

import marimo as mo

app = mo.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):
    summary = df.describe()
    return summary,

@app.cell
def __(summary, mo):
    mo.ui.table(summary)
    return

Perhatikan __ sebagai nama fungsi untuk sel. Ini bukan kebetulan — Marimo memang memperlakukan setiap sel sebagai fungsi Python. Dependency di-deklarasikan secara eksplisit melalui argumen fungsi, dan runtime Marimo membentuk dependency graph secara otomatis.

Konsekuensinya:

1. Tidak ada hidden state. Menjalankan ulang notebook dari awal selalu menghasilkan output yang sama, dengan urutan yang konsisten.
2. Tidak ada out-of-order execution. Runtime hanya menjalankan sel dalam topologi yang benar.
3. Git-friendly diff. File Marimo adalah Python murni (bukan JSON), sehingga diff dan merge bekerja dengan baik.
4. Import otomatis. Library yang digunakan dideklarasikan sebagai argumen sel, dan Marimo menambahkannya ke import sel di posisi teratas.

Integrasi PyCharm: Signifikansi Nyata

Marimo selama ini tersedia sebagai aplikasi web standalone dan sebagai library Python yang bisa dijalankan di browser. Bagi tim data science yang sudah menggunakan JetBrains IDE (PyCharm, DataSpell, IntelliJ), berpindah ke Marimo berarti berpindah ke browser atau editor berbeda. Itu friction yang cukup besar.

Integrasi native ke PyCharm, yang diumumkan di paruh kedua 2026, menghilangkan friction tersebut. Marimo notebook sekarang tampil sebagai file .py dengan cell markers khusus, di-debug seperti script Python biasa, dan benefit dari seluruh ekosistem PyCharm: code completion, refactoring, virtual environment management, debugger, profiler, dan database tools.

Untuk konteks, berikut perbandingan kasual dengan Jupyter di PyCharm:

Aspek	Jupyter (.ipynb)	Marimo (.py di PyCharm)
Format file	JSON	Python murni
Diff Git	Sering konflik	Standar, mudah di-merge
Code completion	Terbatas, di browser	Penuh, via PyCharm
Debugger	Tidak ada native debugger	Breakpoint, step-through
Reproducibility	Stateful, urutan bebas	Reactive, deterministic
Visual output	Inline, via kernel	Panel terpisah, real-time
Deployment	Konversi manual ke script	Run sebagai marimo run app

Studi Kasus: Migrasi Tim dari Jupyter ke Marimo

Salah satu contoh yang sering dirujuk dalam diskusi komunitas adalah tim data science di sebuah perusahaan fintech kecil di Berlin yang memigrasikan 47 notebook dari Jupyter ke Marimo dalam kurun waktu enam minggu. Hasil yang mereka laporkan:

• Waktu onboarding anggota tim baru turun dari rata-rata 4 hari menjadi 1.5 hari (tidak perlu lagi debugging notebook orang lain)
• Bug akibat sel dijalankan dalam urutan salah turun 80% (dari rata-rata 6 insiden per bulan menjadi 1)
• Code review menjadi feasible — sebelumnya notebook Jupyter sulit di-review karena format JSON; sekarang reviewer membaca file Python biasa
• Deployment ke production menjadi satu command: marimo export script notebook.py menghasilkan script standalone

Catatan penting: migrasi ini tidak otomatis. Notebook Jupyter harus ditulis ulang dengan pola Marimo — dependency declaration, reactive cells, dan cell naming convention. Untuk proyek yang sudah mature dengan ratusan notebook, ini adalah investasi yang signifikan. Untuk proyek baru, memulainya langsung dengan Marimo jauh lebih murah.

Hal yang Masih Belum Selesai

Tidak adil membahas Marimo tanpa menyebutkan keterbatasannya. Ecosystem yang lebih kecil berarti beberapa library visualisasi atau widget pihak ketiga mungkin belum kompatibel. Komunitas Marimo, meskipun aktif dan berkembang, masih lebih kecil dari Jupyter. Dokumentasi untuk use case advanced (custom widgets, integrasi dengan tool tertentu) masih lebih sedikit.

Untuk use case yang sangat bergantung pada ekosistem Jupyter tertentu (misalnya nbgrader untuk pendidikan, atau widget ipywidgets yang kompleks), migrasi ke Marimo mungkin belum pragmatic. Untuk use case standar data science — eksplorasi data, feature engineering, modeling, reporting — Marimo memberikan workflow yang lebih bersih dan reproducible.

Rekomendasi

Untuk tim data science yang sering bergulat dengan notebook yang tidak reproducible, code review yang sulit, dan deployment yang manual, integrasi Marimo ke PyCharm adalah momentum yang tepat untuk evaluasi. Mulailah dengan satu notebook baru sebagai pilot, bandingkan workflow dengan Jupyter yang sudah ada, dan putuskan berdasarkan data — bukan berdasarkan hype. Tooling yang baik adalah tooling yang menyelesaikan masalah nyata dalam workflow tim, dan bagi banyak tim, Marimo sekarang menjadi bagian dari jawaban itu.

Konsep Reaktif: Penjelasan Lebih Dalam

Untuk memahami mengapa reactive graph adalah pendekatan yang powerful, ada baiknya membandingkannya dengan eksekusi prosedural yang dipakai Jupyter. Di Jupyter, sel adalah unit eksekusi independen yang dipicu oleh klik "Run" atau shortcut keyboard. Tidak ada kontrak formal tentang dependensi antar sel — dependensi hanya tersirat dari nama variabel yang digunakan. Konsekuensinya, jika sel A mendefinisikan df = pd.read_csv(...) dan sel B menggunakan df, Jupyter tidak tahu bahwa B bergantung pada A. Jika pengguna menjalankan B tanpa menjalankan A terlebih dahulu, hasilnya adalah NameError.

Marimo mengubah ini secara fundamental. Setiap sel adalah pure function dengan signature eksplisit: argumen fungsi menunjukkan apa yang dibaca dari sel lain, dan return value menunjukkan apa yang disediakan untuk sel lain. Runtime Marimo membentuk dependency graph dari signature ini, dan ketika satu variabel berubah, hanya sel-sel yang bergantung padanya yang ditandai stale dan dijalankan ulang. Tidak ada state tersembunyi, tidak ada urutan eksekusi yang salah, dan tidak ada "magic" yang membuat notebook bekerja untuk satu orang tetapi tidak untuk orang lain.

Konsekuensi menarik dari reactive graph: Marimo secara otomatis mencegah beberapa kelas bug yang umum di Jupyter. Misalnya, mendefinisikan ulang df di dua sel yang berbeda adalah error di Marimo (runtime menolak karena konflik definisi), sementara di Jupyter hal itu hanya menimpa variabel secara diam-diam. Untuk pemula Python, feedback seperti ini sangat berharga karena mengajarkan konsep scope dan dependency sejak awal.

Format File: PyBening, Bukan JSON

Salah satu keputusan desain Marimo yang paling penting adalah format file: notebook disimpan sebagai file Python murni dengan dekorator @app.cell, bukan sebagai JSON seperti Jupyter. Konsekuensinya sangat terasa dalam workflow sehari-hari:

• Diff Git menjadi meaningful. Perubahan satu sel muncul sebagai diff beberapa baris Python, bukan diff JSON yang berantakan dengan metadata Jupyter yang ikut berubah setiap kali notebook dijalankan.
• Merge conflict resolvable. Dua orang yang mengedit sel berbeda dari notebook yang sama tidak akan mengalami merge conflict pada file yang sama, karena setiap sel adalah unit kode yang terpisah dan Git dapat menggabungkan mereka dengan benar.
• Code review feasible. Reviewer dapat membaca notebook sebagai kode Python, dengan syntax highlighting dan tooling review standar. Tidak perlu membuka JSON atau Jupyter UI khusus.
• Tooling Python bekerja penuh. Black, ruff, mypy, IDE support — semua tooling Python standar bekerja langsung pada file Marimo.

Untuk tim yang sudah menggunakan pre-commit hooks dan CI pipeline untuk kualitas kode Python, Marimo menyatu secara natural. Tidak ada langkah tambahan untuk "membersihkan" notebook sebelum commit, karena formatnya sudah clean Python.

UI Elements: Lebih dari Sekadar Text

Marimo bukan hanya tentang reproducibility — library ini juga menawarkan koleksi UI elements interaktif yang modern: slider, dropdown, table dengan filter, chart interaktif, dan form components. Elemen-elemen ini reactive secara default: mengubah slider akan secara otomatis men-trigger sel yang menggunakan nilai slider tersebut untuk dijalankan ulang, dan output akan ter-update secara real-time.

Untuk dashboard analitis, ini memberikan workflow yang sangat ergonomis. Tim data science yang sebelumnya harus membuat dashboard terpisah (misalnya dengan Streamlit atau Dash) sekarang bisa membuat interactive analysis langsung di notebook yang sama dengan eksplorasi data. Hasilnya: satu file, satu workflow, satu deployment artifact.

Untuk deployment, Marimo notebook bisa dijalankan sebagai web app interaktif dengan satu command: marimo run notebook.py. Ini sangat berbeda dari workflow Jupyter tradisional, di mana notebook harus dikonversi ke script dan kemudian dibungkus dengan framework web. Marimo adalah web app secara native.

Pertimbangan Performa

Reactive graph memiliki implikasi performa yang perlu dipahami. Setiap kali satu variabel berubah, semua sel yang bergantung padanya dijalankan ulang — dan jika chain dependensi panjang, ini bisa menjadi mahal. Untuk analisis data yang melibatkan komputasi berat (misalnya training model ML pada dataset besar), pendekatan ini mungkin tidak ideal karena akan melatih ulang model setiap kali ada variabel upstream yang berubah.

Untuk kasus seperti ini, idiom Marimo adalah menggunakan mo.stop() atau memisahkan komputasi berat ke sel yang tidak bergantung pada variabel interaktif. Library ini memang tidak dirancang untuk menggantikan Spark atau Dask untuk komputasi distributed — ia dirancang untuk interactive analysis dan reproducible research, di mana chain dependensi umumnya pendek dan komputasi relatif ringan.

Untuk analisis dengan dataset besar (jutaan baris), praktik terbaik adalah melakukan data loading dan preprocessing di script terpisah, lalu load hasil preprocessing ke notebook Marimo untuk eksplorasi interaktif. Pola ini menjaga Marimo tetap responsif sambil memanfaatkan kekuatan Python data stack untuk data processing.