Honest question: what's the advantage of this over the Jupyter notebook support in VSCode? (which I use daily)
Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
11–20 of 100 posts
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#12Honest question: what is not modern about JupyterLab? I know JupyterLab has existed for a long time, but continuous development has kept it modern.
My take:
- The UI is over bloated and bugged, sometimes things scroll, sometimes they don't, sometimes you have to refresh the page. You cannot easily change the UI as lots of CSS parts have hard coded fixed sizes.
- The settings are all over the place, from py files in ~/.jupyter to ini files to auto generated command line parameters.
- The overall architecture is monolithic and hard to break down, jupyter proxy is a good example of the hacks you have to go to to reuse parts of jupyter
- The front end technology (Lumino) is ad hoc and cannot be reused, I had to write my own react components basically reimplementing the whole protocol, come on its 2025.
- The whole automation around nbconvert is error prone and fragile
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#13While 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.
For a fully fledged web app that all the major code notebooks tend to be, Electron makes a lot of sense. The bundled webviews built into OSes tend to be weak and outdated compared to the Chromium build that comes with Electron.
It's why Jupyter fits pretty well into VSCode/VSCodium.
> 5. Rendering your app
> Electron uses Chromium under the hood so your user sees the same on Windows, Linux and macOS. Tauri on the other hand uses the system webview: Edge Webview2 (Chromium) on Windows, WebKitGTK on Linux and WebKit on macOS. Now here comes the bad part, if you are a web developer you know that Safari (Based on WebKit) is always behind a step from every web browser. Just check out Can I Use. There is always a bug that you are not seeing from Chrome, only your dear Safari users. The same issues exists in Tauri, and you can't do anything against it, you have include polyfills. The winner has to be Electron here.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#14What’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.
Yes, the problem with such projects is that the must be very clear benefits for users (rather than developers) to attract a critical mass. At work we had Apache Zeppelin running on the servers alongside with Jupyther. In practice almost nobody used it (probably because almost nobody else used it, so if yourun into any issues you're on your own), so it was quietly shelved after a few years.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#15What's the point of this? Only benefit seems to be decoupling frontend in react. Nobody complaints about Jupyter performance. You can just build frontend and keep Jupyter as it is, it is already concurrent enough for multiple users use cases.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#16Install instructions seem incomplete.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#17I 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 am building it alone fulltime and this is just the first draft. Improvements will come for sure in the near future.
I hope you liked the first draft.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#18Honest question: what is not modern about JupyterLab? I know JupyterLab has existed for a long time, but continuous development has kept it modern.
My take: - The UI is over bloated and bugged, sometimes things scroll, sometimes they don't, sometimes you have to refresh the page. You cannot easily change the UI as lots of CSS parts have hard coded fixed sizes. - The settings are all over the place, from py files in ~/.jupyter to ini files to auto generated command line parameters. - The overall architecture is monolithic and hard to break down, jupyter proxy is…
This is mixing quite a few different things (backend, frontend, auxiliary CLI utilities).
No time to write a lengthy reply here, but I think it's worth separating legitimate like-for-like comparison with a wider feeling on the ecosystem.
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#19I 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
Re: Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go
#20I 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
Thanks @carreau. I think the documentation is amazing! Zasper is built on the great work and documentation from Jupyter team. I will reach out to Jupyter media strategy team.