Zasper – Eine moderne, effiziente JupyterLab-Alternative, die in Go entwickelt wurde

• Zasper ist eine IDE, die für große Parallelität entwickelt wurde
  • Sie bietet minimalen Speicherverbrauch und eine hervorragende Geschwindigkeit und verarbeitet mehrere gleichzeitige Verbindungen
  • Sie eignet sich für die Ausführung von Datenanwendungen im REPL-Stil, ähnlich wie Jupyter Notebooks
• Benchmarks
  • Zasper nutzt im Vergleich zu JupyterLab 4-mal weniger RAM und CPU
  • Während JupyterLab etwa 104,8 MB RAM und 0,8 CPU verbraucht, benötigt Zasper nur 26,7 MB RAM und 0,2 CPU
• Warum Zasper entwickelt wurde
  • Auf dem Markt gibt es JupyterLab-ähnliche Frontend-Werkzeuge wie Databricks Notebooks und Deepnote Notebooks, doch die meisten sind nicht kostenlos und müssen in der Cloud betrieben werden
  • Zasper läuft flüssig auf lokalen Maschinen und nutzt verfügbare Ressourcen effektiv, um maximale Effizienz zu gewährleisten
  • Go bietet eine starke Unterstützung für REST-, RPC- und WS-Protokolle und überzeugt bei Parallelität und Leistung
  • Python eignet sich gut für I/O-zentrierte asynchrone Arbeiten, hat aber bei CPU-zentrierten Aufgaben Grenzen
• Es bietet verschiedene Funktionen wie Editor, Terminal, Launcher, Jupyter Notebook, Versionsverwaltung, Befehlspalette und Dark Mode
• Es wird sowohl als Electron-App als auch als Web-App angeboten
• Roadmap
  • Zasper zielt auf ein leistungsfähiges IDE-Ökosystem für Data Scientists und KI-Ingenieure ab, mit der folgenden Entwicklungsrichtung:
    • Unterstützung für benutzerdefinierte Daten-Apps, nicht nur für Jupyter Notebooks
    • Erleichterung der Integration mit bestehenden Tools
    • Bereitstellung von Zasper Hub für Self-Hosted-Betrieb in der Cloud

[GN⁺]

Hacker News Kommentar

• Der Autor von Zasper erklärt, dass die Jupyter-Kernel-Verarbeitung in Zasper mit Go-Routinen umgesetzt wurde und besser sei als die Python-basierte Variante von JupyterLab.

  • Zasper nutzt im Vergleich zu JupyterLab nur rund ein Viertel an RAM und CPU.
  • Suchfunktionen usw. sind noch nicht optimiert und daher langsam.
  • Er entwickelt das Projekt alleine in Vollzeit und wird es künftig weiter verbessern.
  • Er erwartet positives Feedback zum ersten Entwurf.

• Marimo wirkt als Jupyter-Alternative interessant, weil es die Vorteile von Streamlit und Jupyter verbindet.

• Es wurde infrage gestellt, ob die Reduktion von Speicher- und CPU-Nutzung tatsächlich relevant ist.

  • Da Python-Code mehr Ressourcen verbraucht, ist unklar, wie viel Go-Routinen dabei helfen.

• Es wurde angemerkt, dass JupyterLab trotz seines Alters durch kontinuierliche Entwicklung weiterhin modern ist.

• Es wurde kritisiert, dass die Alternative nur auf macOS läuft, auf Linux nur teilweise unterstützt wird und nur IPython unterstützt.

  • Es wurde erwähnt, dass die Performancevorteile von Go durch den Einsatz von Electron wieder aufgehoben werden.

• Es wurde der Wunsch nach einer Jupyter-ähnlichen Oberfläche wie in RStudio geäußert; besonders wichtig ist die Möglichkeit, Codeblöcke ausführen zu können.

  • Die Funktion „open console for notebook“ in JupyterLab wird gelobt, aber es wurde kein Weg gefunden, wie man Text sendet oder per Tastaturkürzel den Fokus wechselt.
  • Aus diesem Grund wird die Jupyter-Implementierung von VSCode nicht genutzt.

• Es wurde angeregt, für die UI Wails in Betracht zu ziehen.

  • Da viel Arbeit in Go geflossen ist, wird bedauert, dass dennoch Electron verwendet wurde.

• Es wurde gefragt, welche Vorteile gegenüber der Jupyter-Notebook-Unterstützung in VSCode bestehen.

• Es wurde gefragt, ob Ausgaben verloren gehen, wenn die Verbindung im laufenden Frontend getrennt und erneut hergestellt wird.

• Das Projekt scheint darauf ausgelegt zu sein, das JupyterLab-Frontend zu ersetzen und die Verbindung zum Jupyter-Kernel beizubehalten.

  • Theoretisch scheint es möglich zu sein, auch JavaScript- oder andere Sprach-Kernel zu unterstützen.
  • Es wurde erwähnt, dass das Projekt bislang nur mit dem IPython-Kernel getestet wurde; das zukünftige Entwicklungspotenzial weckt Interesse.