Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go

github.com

Post reply on HN
Print view View original

71–80 of 100 posts

Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go

#71

Post by _venkatasg »

prasunanand wrote: post #17

I am the author of Zasper. The unique feature of Zasper is that the Jupyter kernel handling is built with Go coroutines and is far superior to how it's done by JupyterLab in Python. Zasper uses one fourth of RAM and one fourth of CPU used by Jupterlab. While Jupyterlab uses around 104.8 MB of RAM and 0.8 CPUs, Zasper uses 26.7 MB of RAM and 0.2 CPUs. Other features like Search are slow because they are not refined. I…

Just wanna say this is a really cool project, and I can't think of higher praise than me hoping I build something as cool as this some day! I've been meaning to learn Go for sometime now, and will be referring to Zasper for the future :)

Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go

#72

Post by crabbone »

prasunanand wrote: post #17

I am the author of Zasper. The unique feature of Zasper is that the Jupyter kernel handling is built with Go coroutines and is far superior to how it's done by JupyterLab in Python. Zasper uses one fourth of RAM and one fourth of CPU used by Jupterlab. While Jupyterlab uses around 104.8 MB of RAM and 0.8 CPUs, Zasper uses 26.7 MB of RAM and 0.2 CPUs. Other features like Search are slow because they are not refined. I…

I'm not directly involved with extending Jupyter Lab, but I'm involved with the results (and testing) of our extension on the daily basis. What I find very often to be the source of complaints is the error reporting. In particular, the kind of error reporting that just disappears from the screen after few seconds. If there's one singular feature of Jupyter Lab that I really want changed, it's this.

Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go

#73

Post by shwouchk »

Demiurge wrote: post #63
shwouchk wrote: post #61

Earlier quoted context omitted.

Hello and thank you for making this! Can I sway you to take this into a ... certain direction? From my POV any browser based editor will be inferior to emacs (and to lesser extent vim) simply because it won't run my elisp code. While a fresh and snappier UI compared to eg jupyter would be nice, I would love to see something that integrates well with emacs out of the box. So, perhaps it would be really nice if the bac…

Did somebody say eMacs? I dunno, I think VI integration could be more important.

I mentioned vim as well and generally proposed something that would be editor agnostic. Shoo! back to your cave.

Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go

#74

Post by mscolnick »

ThouYS wrote: post #47
_l7dh wrote: post #37

It's probably an unrelated post (apologies in advance) but I wanted to shoutout to the Marimo ( https://marimo.io ), it's the only Jupyter alternative that really got me excited, it's like Streamlit and Jupyter had a kid (and the kid took the best genes from both).

marimo is really cool, albeit "pure python" is only true insofar as the diff is concerned. other than that, it's an unconnected group of functions that need the marimo runtime to stitch together. would be cool if marimo could "unroll" the compute graph into a standalone python script that doesn't need the marimo library

it’s already possible to do this: marimo export script nb.py

Pure-python also helps to work with existing tools out of the box: formatting, linting, pytest, importing notebooks as modules, composition, PEP 723 inline metadata

Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go

#75

Post by filmor »

prasunanand wrote: post #17

I am the author of Zasper. The unique feature of Zasper is that the Jupyter kernel handling is built with Go coroutines and is far superior to how it's done by JupyterLab in Python. Zasper uses one fourth of RAM and one fourth of CPU used by Jupterlab. While Jupyterlab uses around 104.8 MB of RAM and 0.8 CPUs, Zasper uses 26.7 MB of RAM and 0.2 CPUs. Other features like Search are slow because they are not refined. I…

It currently hard-codes launching ipykernel, right?

Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go

#76

Post by shwouchk »

zitterbewegung wrote: post #67
shwouchk wrote: post #61

Earlier quoted context omitted.

Hello and thank you for making this! Can I sway you to take this into a ... certain direction? From my POV any browser based editor will be inferior to emacs (and to lesser extent vim) simply because it won't run my elisp code. While a fresh and snappier UI compared to eg jupyter would be nice, I would love to see something that integrates well with emacs out of the box. So, perhaps it would be really nice if the bac…

There already is a library that can interface emacs with Juypter it is called ein. I think what you really want is a kernel that executes emacs code and if you did make that kernel it would probably work in any of these systems. See https://github.com/emacs-jupyter/jupyter

Yes, I'm aware of EIN. To start, it's been abandoned by it's author/maintainer as of April 2024 IIRC.

Further, I do not need a kernel to execute emacs code - I have one and it's called emacs. The point regarding executing elisp code was a cheeky way to state that I am not looking forward to finding replacement and/or porting of all the custom code - mine and others' - that my editor runs, and that no amount of "features" from a webui editor will ever replace that. Hence I also mentioned vim since over time it got customized for me as well and I wouldn't want to port that either. Nor the convenience of the terminal, which is what vim is for.

Putting that aside as with all respect and gratitude to the author, it was rather clunky in many respects - no interactive story, poor handling of sessions and remote kernels (have you tried to start one, disconnect and reconnect?), no integration with LSP, and lack of many many more features that /could/ be made.

I don't know how much use you make of jupyter kernels or mathematica notebooks or similar technologies, but in my case I explored the available landcape quite thoroughly and regularly revisit. I know what I'm looking for and EIN is/was not it.

[EDIT] I just noticed you mentioned EIN but linked to emacs-jupyer. Used that as well, of course. Ill add a bit more detail to that in sibling

Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go

#77

Post by westurner »

williamstein wrote: post #70
dleeftink wrote: post #55

Earlier quoted context omitted.

> Alternative are always welcome; at least if they don't fragment the ecosystem by being not backward compatible with the default. Genuinely curious; what mechanisms has Jupyter introduced to prevent ecosystem fragmentation?

The Jupyter community maintains a public spec of the notebook file format [1], the kernel protocol [2], etc. I have been involved with many alternative Jupyter clients, and having these specs combined with a friendly and welcoming community is incredibly helpful!!! [1] https://github.com/jupyter/nbformat [2] https://jupyter-client.readthedocs.io/en/latest/messaging.ht...

jupyter-server/enterprise_gateway: https://github.com/jupyter-server/enterprise_gateway

JupyterLab supports Lumino and React widgets.

Jupyter Notebook was built on jQuery, but Notebook is now forked from JupyterLab and there's NbClassic.

Breaking the notebook extension API from Notebook to Lab unfortunately caused re-work for progress, as I recall.

jupyter-xeus/xeus is an "Implementation of the Jupyter kernel protocol in C++* https://github.com/jupyter-xeus/xeus

jupyter-xeus/xeus-python is a "Jupyter kernel for the Python programming language"* that's also what JupyterLite runs in WASM instead of ipykernel: https://github.com/jupyter-xeus/xeus-python#what-are-the-adv...

JupyterLite kernels normally run in WASM; which they are compiled to by emscripten / LLVM.

To also host WASM kernels in a go process, I just found: going: https://github.com/fizx/goingo .. https://news.ycombinator.com/item?id=26159440

Vscode and vscode.dev support wasm container runtimes now; so the Python kernel runs in WASM runs in a WASM container runs in vscode FWIU.

Vscode supports polyglot notebooks that run multiple kernels, like "vatlab/sos-notebook" and "minrk/allthekernels". Defining how to share variables between kernels is the more unsolved part AFAIU. E.g. Arrow has bindings for zero-copy sharing in multiple languages.

Cocalc, Zeppelin, Marimo notebook, Data Bricks, Google Colaboratory (Colab tools), and VSCode have different takes on notebooks with I/O in JSON.

There is no CDATA in HTML5; so HTML within an HTML based notebook format would need to escape encode binary data in cell output, too. But the notebook format is not a packaging format. So, for reproducibility of (polyglot) notebooks there must also be a requirements.txt or an environment.yml to indicate the version+platform of each dependency in Python and other languages.

repo2docker (and repo2podman) build containers by installing packages according to the first requirements .txt or environment.yml it finds according to REES Reproducible Execution Environment Standard. repo2docker includes a recent version of jupyterlab in the container.

JupyterLab does not default to HTTPS with an LetsEncrypt self-signed cert but probably should, because Jupyter is a shell that can run commands as the user that owns the Jupyter kernel process.

MoSH is another way to run a web-based remote terminal. Jupyter terminal is not built on MoSH Mobile Shell.

jupyterlab/jupyter-collaboration for real time collaboration is based on the yjs/yjs CRDT. https://github.com/jupyterlab/jupyter-collaboration

Cocalc's Time Slider tracks revisions to all files in a project; including latex manuscripts (for ArXiV), which - with Computer Modern fonts and two columns - are the typical output of scholarly collaboration on a ScholarlyArticle.

Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go

#78

Post by lutusp »

williamstein wrote: post #54
lutusp wrote: post #40

Earlier quoted context omitted.

>> JupyterLab kernel > There is no such thing. A Web search reveals that the alternate term "Jupyter kernel," appears equally often. The terms are interchangeable. > I'm pretty sure Sage was always intended as a project that integrates the world, never "small footprint". A large install became true eventually, but it began as a small Python-based install, about 120 KB. Then people asked for extensions, and William St…

No.

Okay, a slightly exaggerated account.

Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go

#79

Post by 3eb7988a1663 »

mscolnick wrote: post #74
ThouYS wrote: post #47

Earlier quoted context omitted.

marimo is really cool, albeit "pure python" is only true insofar as the diff is concerned. other than that, it's an unconnected group of functions that need the marimo runtime to stitch together. would be cool if marimo could "unroll" the compute graph into a standalone python script that doesn't need the marimo library

it’s already possible to do this: marimo export script nb.py Pure-python also helps to work with existing tools out of the box: formatting, linting, pytest, importing notebooks as modules, composition, PEP 723 inline metadata

If you are going to do that, you could stick with Jupyter + nbconvert.

I rarely use notebooks directly anymore unless I require the output to be stored. Do most everything in VSCode with interactive .py files. Gets you the same notebook-y experience + all of the Python tooling.

Post reply on HN