Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
1–10 of 100 posts
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#2While it looks like a great effort was put into this, an alternative has to support the same platforms, languages and related tooling, not run only on macOS, partial support on Linux, and IPython.
Then all the performance improvements by using Go, are taken away by using Electron.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#3This looks pretty nice - this is specifically replacing the JupyterLab frontend and keeping the connections to Jupyter kernels - there shouldn't be any theoretical reason that it couldn't support Javascript or other language kernels, although I guess the project has only been tested with IPython kernels.
Would be interested to see where this goes.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#4What’s the advantage of this? It isn’t obvious to me that reducing memory usage and CPU of an empty/idle kernel is all that meaningful if the actual Python code in your notebook uses far more resources. It’s also not obvious to me how Go’s better threading helps, either, if all the computational bits are in Python anyway.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#5Honest question: what is not modern about JupyterLab? I know JupyterLab has existed for a long time, but continuous development has kept it modern.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#6What’s the advantage of this? It isn’t obvious to me that reducing memory usage and CPU of an empty/idle kernel is all that meaningful if the actual Python code in your notebook uses far more resources. It’s also not obvious to me how Go’s better threading helps, either, if all the computational bits are in Python anyway.
I have one nit with JupyterLab. When I press Ctrl+F, it takes ~0.4 seconds for the search box to open, and sometimes the first keystroke doesn't register when I type something into that search box.
"Zasper ... provides ... exceptional speed".
If they can just make input latency indistinguishable from vim, that's a very worthwhile value add.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#7I wish the author considered https://wails.io/ for UI. Why all the effort with Go and ended up with Electron?
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#8What’s the advantage of this? It isn’t obvious to me that reducing memory usage and CPU of an empty/idle kernel is all that meaningful if the actual Python code in your notebook uses far more resources. It’s also not obvious to me how Go’s better threading helps, either, if all the computational bits are in Python anyway.
It is quite beneficial for people who aren't writing python. And for them managing jupyterlab installations is a bit of pain.
I would like to use this with xeus kernel for sql (which is also native) and if this reduces the resource consumption of that setup significantly, its a big plus for me.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#9I wish the author considered https://wails.io/ for UI. Why all the effort with Go and ended up with Electron?
Because they use code mirror to build their ide
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#10What’s the advantage of this? It isn’t obvious to me that reducing memory usage and CPU of an empty/idle kernel is all that meaningful if the actual Python code in your notebook uses far more resources. It’s also not obvious to me how Go’s better threading helps, either, if all the computational bits are in Python anyway.
It is quite beneficial for people who aren't writing python. And for them managing jupyterlab installations is a bit of pain. I would like to use this with xeus kernel for sql (which is also native) and if this reduces the resource consumption of that setup significantly, its a big plus for me.
The README says the savings is ~75 MB. In most notebook workflows you’re at most running a couple at once. Saving <1% of my system memory doesn’t let me do anything I couldn’t do before. This also isn’t going to add concurrency/parallelism to your SQL unless xeus has some special magic that this is somehow able to exploit.