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

41–50 of 100 posts

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

#41

Post by prirai »

lutusp wrote: post #32

> ... A Modern and Efficient Alternative to JupyterLab ... This is not meant as criticism, just perspective. It's a classic development sequence: * A team creates a powerful, small-footprint, REPL environment. * Over time people ask for more features and languages. * The developers agree to all such requests. * The environment inevitably becomes more difficult to install and maintain. * A new development team offers…

Sagemath offers a different purpose which is scientific computing in order to compete with Mathematica and MATLAB. It offered a good interactive notebook interface which went on till about 2016, and later on was migrated to using the jupyter backend. It currently isn't well supported in Windows which is what you might have meant by the complexity. However it works pretty well with linux systems.

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

#43

Post by zelphirkalt »

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…

The actual RAM issue is another one. Every Python kernel you start consumes around 100-150MB RAM. So unless you are starting different kernels using Zasper, the majority of RAM usage is still going to be the same.

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

#44

Post by set92 »

jampekka wrote: post #35
tylerhillery wrote: post #33

How does this compare to Marimo?

Doesn't seem to fix the invisible state problem that Marimo fixes.

From my POV is not fixing, is another way of work. I don't like what Marimo does, because for that I have scripts.

If I'm loading files from S3, I'm being charge for it. If Marimo re-executes this cell to maintain the state, it will charge me double. I don't need that. I'm able to organize my code, and know how it is being run.

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

#45

Post by lutusp »

prirai wrote: post #41
lutusp wrote: post #32

> ... A Modern and Efficient Alternative to JupyterLab ... This is not meant as criticism, just perspective. It's a classic development sequence: * A team creates a powerful, small-footprint, REPL environment. * Over time people ask for more features and languages. * The developers agree to all such requests. * The environment inevitably becomes more difficult to install and maintain. * A new development team offers…

Sagemath offers a different purpose which is scientific computing in order to compete with Mathematica and MATLAB. It offered a good interactive notebook interface which went on till about 2016, and later on was migrated to using the jupyter backend. It currently isn't well supported in Windows which is what you might have meant by the complexity. However it works pretty well with linux systems.

> Sagemath offers a different purpose which is scientific computing in order to compete with Mathematica and MATLAB.

Yes, that was its goal, when Python wasn't as evolved as it is now. More recently I've come to rely on Python libraries like sympy for symbolic processing. For these kinds of results Sage relies on a rather old environment called Maxima, and I think current sympy does pretty much everything that Maxima does. And as time passes Python libraries are beginning to provide some of the numerical processing originally provided by MATLAB (but more slowly).

> It currently isn't well supported in Windows which is what you might have meant by the complexity.

Actually I was thinking of JupyterLab itself. As time passes I find it more difficult to get it installed without library conflicts. But that can be said about many Python-based projects in modern times, which is why a Python virtual environment is becoming more the rule than the exception, in particular with GPU-reliant chatbots and imaging apps, to avoid the seemingly inevitable library version conflicts.

If memory serves, Sage now installs on Windows by creating a Linux VM to support it.

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

#46

Post by CraigJPerry »

_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 notebooks are pure Python and stored as .py files

That sounds like a solid improvement. I’m going to give this a test drive. I feel like modularity is one of the hardest aspects of Jupyter notebooks in a team environment.

I’d be interested to hear if anyone has cracked a workflow with notebooks for larger teams. Notebooks are easy for solo or very small teams, and the literate programming style benefits still apply in larger teams but there’s a lot of friction: “hey just %run this shared notebook with a bunch of useful utilities in it - oops yeah it tries to write some files because of some stuff unrelated to your use case in there (that’s essential to my use case)”

My current best that I know of is to keep “calculation” (pure) code in a .py and just the “action“ (side-effectful) code in the notebook. Then as far as physically possible, keep the data outside of notebook (usually a database or csv’s). That helps avoid the main time sink pitfalls (resolving git conflicts, versioning, testing etc) but it doesn’t solve for example tooling you might want to run - maybe mypy against that action code - sure you can use nbqa but… interested to learn better approaches.

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

#47

Post by ThouYS »

_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

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

#48

Post by petre »

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…

Does it have a Racket kernel yet? I love using Racket for notebooks in Jupyter, but the UI is just too slow.

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

#49

Post by est »

benatkin wrote: post #13
pjmlp wrote: post #2

While 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 oth…

Then why can't Chrome/Edge provide a up-to-date library for everyone like mshtml.dll?

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

#50

Post by pjmlp »

est wrote: post #49
benatkin wrote: post #13

Earlier quoted context omitted.

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 oth…

Then why can't Chrome/Edge provide a up-to-date library for everyone like mshtml.dll?

That is what Edge Webview2 is,

https://developer.microsoft.com/en-gb/microsoft-edge/webview...

https://learn.microsoft.com/en-us/microsoft-edge/webview2/

Post reply on HN