Live data from Hacker News

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

github.com

21–30 of 100 posts

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

#22
post #10
post #8

Earlier quoted context omitted.

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.

I was primarily talking in the context of shared server deployments for teams

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

#23
post #19

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…

IPython maintainer and Jupyter dev (even if I barely touch frontend stuff these days). Happy to see diversity, keep up the good work and happy new year. Feel free to open issues upstream if you find lack of documentation or issue with protocol. You can also try to reach to jupyter media strategy team, maybe they'll be open to have a blog post about this on blog.jupyter.org

That's stellar sportmanship right there.

Not that jupyter's team needed even more respect from the community but damn.

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

#24
post #8
post #4

What’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.

uvx --from jupyter helps with that significantly.

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

#25

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…

Congratulations on the launch! It's great to see alternatives to Jupyter. JupyterLab is an excellent, however creating editor for broad audience is challenging. I've found Jupyter difficult to use, especially for beginners. Managing kernels, Python environments, and installing new packages can be quite cumbersome. Are you planning to address these challenges in Zasper?

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

#26
post #19

Earlier quoted context omitted.

IPython maintainer and Jupyter dev (even if I barely touch frontend stuff these days). Happy to see diversity, keep up the good work and happy new year. Feel free to open issues upstream if you find lack of documentation or issue with protocol. You can also try to reach to jupyter media strategy team, maybe they'll be open to have a blog post about this on blog.jupyter.org

That's stellar sportmanship right there. Not that jupyter's team needed even more respect from the community but damn.

I think that's fairly normal, having alternative frontends can only be beneficial to the community. I know it also look like there is a single Jupyter team, but the project is quite large, there are a lot of constraints and disagreements internally and there is not way to accomodate all users in the default jupyter install. Alternative are always welcome ; at least if they don't fragment the ecosystem by being not backward compatible with the default.

Also to be fair I'm also one of the Jupyter dev that agree with many points of OP, and would have pulled it into a different direction; but regardldess I will still support people wanting to go in a different direction than mine.

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

#27

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…

Congratulations on the launch! It's great to see alternatives to Jupyter. JupyterLab is an excellent, however creating editor for broad audience is challenging. I've found Jupyter difficult to use, especially for beginners. Managing kernels, Python environments, and installing new packages can be quite cumbersome. Are you planning to address these challenges in Zasper?

Yeah, I will work on these problems and I already have solutions in mind. Just wanted to get the word out about the project first and see if the world actually needs something like Zasper.

I am really happy to see the welcoming response from the dev community.

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

#28
post #9

I 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

You can use CodeMirror with Wails I think, it's still web technologies but with a thinner layer compared to electron.

https://wails.io/docs/howdoesitwork

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

#29

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…

Congratulations on the launch! It's great to see alternatives to Jupyter. JupyterLab is an excellent, however creating editor for broad audience is challenging. I've found Jupyter difficult to use, especially for beginners. Managing kernels, Python environments, and installing new packages can be quite cumbersome. Are you planning to address these challenges in Zasper?

Have you tried the Jupyter desktop app? It's more self-contained.

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

#30

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…

On a quick glance, it seems it's possible to run this as a service similar to JupyterLab, right?

I'd be keen to offer it as an alternative to Jupyter on my little GPU platform experiment.

Post reply on HN