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

61–70 of 100 posts

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

#61

Post by shwouchk »

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…

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 backend+API was really polished as an end product itself in such a way that it could easily interface with other frontends, with remote attachment.

I could go on with my list of demands but I would be thrilled and amazed at my luck if even those two happen...

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

#62

Post by jampekka »

set92 wrote: post #44
jampekka wrote: post #35

Earlier quoted context omitted.

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.

I use mostly the script workflow, but for exploration Marimo is more convenient. It got also to-disk memoization recently. Kinda best of both worlds for exploration (although I'm not a huge fan of editing code in browser). In comparison to the JupyterLab hidden state spaghetti it's a fix.

With proper structuring of the blocks, Marimo will not re-execute the cell. Also memoization in script based workflows is still somewhat clunky on Python even with something like Snakemake.

I do find Marimo's approach, "global" variables tracked between blocks, less than ideal, but it's the best out there.

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

#63

Post by Demiurge »

shwouchk wrote: post #61
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…

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.

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

#65

Post by qsort »

CraigJPerry wrote: post #46
_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 sti…

I'm mostly in the camp that notebooks aren't that great for software development, they thrive as an "excel for coders" of sorts, but take a look at nbdev from fast.ai.

The literate programming aspect is very nice and I wish it was explored more.

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

#66

Post by jerf »

Panoramix wrote: post #58
pplonski86 wrote: post #39

Earlier quoted context omitted.

Yes, I tried Jupyter Desktop. It is fantastic, I like that you can double click on notebook file to open app. However, it might be a little to complicated for beginners, you need to setup Python and select kernels. That's too much.

People can program in python but cannot select a kernel from a list? I find that hard to believe

I mean this without rancor or insult, but a lot of data scientists may use Python, but are definitely not Python programmers. They know the subset of Python necessary to process data, and literally not one bit more. They would have no idea how to create an iterator function, their own "with" handler, may not even know how to create a new subclass with a method. They just take data in, chew on it, and spit it out.

Again, not an insult intended to them. They have their job and they do it, and I don't know much about their world either, after all. And of course you can find some data scientists who also deeply know Python. My point is merely that modeling them all generically as "Python programmers" in your head can lead to a model that makes bad predictions, which I found in my brief stint in that world can include you building tools for them that expect more out of them than they have.

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

#67

Post by zitterbewegung »

shwouchk wrote: post #61
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…

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

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

#68

Post by spudlyo »

shwouchk wrote: post #61
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…

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…

I'm curious what your thoughts on are on emacs-jupyter[0] which seems to integrate reasonably well with Org mode. I have some complaints about how it has to handle output blocks, but otherwise it seems like a great way for Emacs to act as a frontend to a Jupyter kernel.

[0]: https://github.com/emacs-jupyter/jupyter

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

#69

Post by amoss »

set92 wrote: post #44
jampekka wrote: post #35

Earlier quoted context omitted.

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.

https://docs.marimo.io/guides/expensive_notebooks/

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

#70

Post by williamstein »

dleeftink wrote: post #55
carreau wrote: post #26

Earlier quoted context omitted.

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

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

Post reply on HN