[HN Gopher] Zasper: A Modern and Efficient Alternative to Jupyte...
___________________________________________________________________
Zasper: A Modern and Efficient Alternative to JupyterLab, Built in
Go
Author : thunderbong
Score : 368 points
Date : 2025-01-02 05:55 UTC (17 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pjmlp wrote:
| 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.
| benatkin wrote:
| 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.
|
| https://www.levminer.com/blog/tauri-vs-electron
| est wrote:
| Then why can't Chrome/Edge provide a up-to-date library for
| everyone like mshtml.dll?
| pjmlp wrote:
| That is what Edge Webview2 is,
|
| https://developer.microsoft.com/en-gb/microsoft-
| edge/webview...
|
| https://learn.microsoft.com/en-us/microsoft-edge/webview2/
| benatkin wrote:
| Maybe the situation only sucks on OS X. On Linux you
| could hopefully swap it out with a new one on build, and
| it isn't based on WebKit which is slow to support lots of
| stuff. Either way, I think perhaps Tauri should provide a
| way to optionally use its own build of the rendering
| engine and a preset/example configuration that uses the
| included one for the platforms that are up to date and
| its own build of a rendering engine for OS X and possibly
| Linux.
| pjmlp wrote:
| Well, there we have the whole issue that Web has
| literally become ChromeOS for all practical purposes of
| who is driving it, and browser market share.
|
| It is called Webview2, because the first MSHTML.dll
| replacement was based on the original updated Edge
| engine, which Microsoft dropped for their own Chrome
| fork.
|
| So either one cares to use portable Web development
| practices, or whatever Chrome does, with the side effect
| to increase its market share even further.
| Flux159 wrote:
| This 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.
| oivey wrote:
| 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.
| energy123 wrote:
| 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.
| lf-non wrote:
| 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.
| oivey wrote:
| 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.
| lf-non wrote:
| I was primarily talking in the context of shared server
| deployments for teams
| BiteCode_dev wrote:
| uvx --from jupyter helps with that significantly.
| em500 wrote:
| 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.
| DandyDev wrote:
| Honest question: what is not modern about JupyterLab? I know
| JupyterLab has existed for a long time, but continuous
| development has kept it modern.
| Galanwe wrote:
| 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
| agoose77 wrote:
| 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.
| dist-epoch wrote:
| The need to start the server is really annoying. Especially
| when you have notebooks in multiple places, or multiple virtual
| envs.
|
| This is why I moved to working with Jupyter notebooks in VS
| Code, there is no server to manually start.
| pletnes wrote:
| Vscode will start the server for you, in practice. This is
| great if you just want to get going. It gives you a bit less
| flexibility though, if you want to do something fancy.
|
| Vscode can also connect to existing servers. This can be very
| useful. For instance, you can put a ton of data and CPU in a
| server and work with vscode on a small laptop. If network
| latency is low enough, this works great.
| low_tech_punk wrote:
| I wish the author considered https://wails.io/ for UI. Why all
| the effort with Go and ended up with Electron?
| nbittich wrote:
| Because they use code mirror to build their ide
| hbbio wrote:
| 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
| RossBencina wrote:
| Honest question: what's the advantage of this over the Jupyter
| notebook support in VSCode? (which I use daily)
| bandrami wrote:
| Or for that matter Emacs
| v3ss0n wrote:
| What'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.
| dizhn wrote:
| Install instructions seem incomplete.
| prasunanand wrote:
| 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 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.
| carreau wrote:
| 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
| prasunanand wrote:
| 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.
| BiteCode_dev wrote:
| That's stellar sportmanship right there.
|
| Not that jupyter's team needed even more respect from the
| community but damn.
| carreau wrote:
| 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.
| BiteCode_dev wrote:
| The last paragraph let me think your normal is
| particularly collaborative lol.
| dleeftink wrote:
| > 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?
| williamstein wrote:
| 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...
| westurner wrote:
| jupyter-server/enterprise_gateway:
| https://github.com/jupyter-server/enterprise_gateway
|
| JupyterLab supports Lumino and React widgets.
|
| Jupyter Notebook was built on jQuery, but Notebook is now
| forked from JupyterLab and there's NbClassic.
|
| Breaking the notebook extension API from Notebook to Lab
| unfortunately caused re-work for progress, as I recall.
|
| jupyter-xeus/xeus is an _" Implementation of the Jupyter
| kernel protocol in C++* https://github.com/jupyter-
| xeus/xeus
|
| jupyter-xeus/xeus-python is a _"Jupyter kernel for the
| Python programming language"* that's also what
| JupyterLite runs in WASM instead of ipykernel:
| https://github.com/jupyter-xeus/xeus-python#what-are-the-
| adv...
|
| JupyterLite kernels normally run in WASM; which they are
| compiled to by emscripten / LLVM.
|
| To also host WASM kernels in a go process, I just found:
| going: https://github.com/fizx/goingo ..
| https://news.ycombinator.com/item?id=26159440
|
| Vscode and vscode.dev support wasm container runtimes
| now; so the Python kernel runs in WASM runs in a WASM
| container runs in vscode FWIU.
|
| Vscode supports _polyglot notebooks_ that run multiple
| kernels, like "vatlab/sos-notebook" and
| "minrk/allthekernels". Defining how to share variables
| between kernels is the more unsolved part AFAIU. E.g.
| Arrow has bindings for zero-copy sharing in multiple
| languages.
|
| Cocalc, Zeppelin, Marimo notebook, Data Bricks, Google
| Colaboratory (Colab tools), and VSCode have different
| takes on notebooks with I/O in JSON.
|
| There is no CDATA in HTML5; so HTML within an HTML based
| notebook format would need to escape encode binary data
| in cell output, too. But the notebook format is not a
| packaging format. So, for reproducibility of (polyglot)
| notebooks there must also be a requirements.txt or an
| environment.yml to indicate the version+platform of each
| dependency in Python and other languages.
|
| repo2docker (and repo2podman) build containers by
| installing packages according to the first requirements
| .txt or environment.yml it finds according to REES
| Reproducible Execution Environment Standard. repo2docker
| includes a recent version of jupyterlab in the container.
|
| JupyterLab does not default to HTTPS with an LetsEncrypt
| self-signed cert but probably should, because Jupyter is
| a shell that can run commands as the user that owns the
| Jupyter kernel process.
|
| MoSH is another way to run a web-based remote terminal.
| Jupyter terminal is not built on MoSH Mobile Shell.
|
| jupyterlab/jupyter-collaboration for real time
| collaboration is based on the yjs/yjs CRDT.
| https://github.com/jupyterlab/jupyter-collaboration
|
| _Cocalc_ 's Time Slider tracks revisions to all files in
| a project; including latex manuscripts (for ArXiV), which
| - with Computer Modern fonts and _two columns_ - are the
| typical output of scholarly collaboration on a
| ScholarlyArticle.
| BiteCode_dev wrote:
| At this stage, notebooks should be a GUI powered docker-
| like image format you download and then click to run.
|
| Non programmers using notebooks are usually the least
| qualified to make them reproducible, so better just ship
| the whole thing.
| szvsw wrote:
| I'm not adding a lot to the conversation, but it's not often
| you run into someone who contributes to creating a tool so
| fundamental to your daily life, career, growth as a
| researcher etc, so let me just take the opportunity to say:
| thank you and the rest of your team for creating such an
| amazing interactive tool.
| pplonski86 wrote:
| 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?
| prasunanand wrote:
| 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.
| dist-epoch wrote:
| Have you tried the Jupyter desktop app? It's more self-
| contained.
| pplonski86 wrote:
| 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.
| Panoramix wrote:
| People can program in python but cannot select a kernel
| from a list? I find that hard to believe
| jerf wrote:
| 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.
| hedgehog wrote:
| That's not to mention getting dependencies installed. I
| know a good amount about everything from the silicon up
| and it can still take some time to get to the point where
| I have a Python ML environment working. Debugging
| whichever vendor's barque build process, broken drivers,
| etc etc, not fun and not something we probably want every
| notebook user to spend time on.
| tudorizer wrote:
| 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.
| zelphirkalt wrote:
| 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.
| petre wrote:
| Does it have a Racket kernel yet? I love using Racket for
| notebooks in Jupyter, but the UI is just too slow.
| klooney wrote:
| How was your experience working with 0mq?
| shwouchk wrote:
| 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...
| Demiurge wrote:
| Did somebody say eMacs? I dunno, I think VI integration could
| be more important.
| shwouchk wrote:
| I mentioned vim as well and generally proposed something
| that would be editor agnostic. Shoo! back to your cave.
| zitterbewegung wrote:
| 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
| shwouchk wrote:
| Yes, I'm aware of EIN. To start, it's been abandoned by
| it's author/maintainer as of April 2024 IIRC.
|
| Further, I do not need a kernel to execute emacs code - I
| have one and it's called emacs. The point regarding
| executing elisp code was a cheeky way to state that I am
| not looking forward to finding replacement and/or porting
| of all the custom code - mine and others' - that my editor
| runs, and that no amount of "features" from a webui editor
| will ever replace that. Hence I also mentioned vim since
| over time it got customized for me as well and I wouldn't
| want to port that either. Nor the convenience of the
| terminal, which is what vim is for.
|
| Putting that aside as with all respect and gratitude to the
| author, it was rather clunky in many respects - no
| interactive story, poor handling of sessions and remote
| kernels (have you tried to start one, disconnect and
| reconnect?), no integration with LSP, and lack of many many
| more features that /could/ be made.
|
| I don't know how much use you make of jupyter kernels or
| mathematica notebooks or similar technologies, but in my
| case I explored the available landcape quite thoroughly and
| regularly revisit. I know what I'm looking for and EIN
| is/was not it.
|
| [EDIT] I just noticed you mentioned EIN but linked to
| emacs-jupyer. Used that as well, of course. Ill add a bit
| more detail to that in sibling
| zitterbewegung wrote:
| I'm guessing you already looked at org-mode code blocks
| which basically do the same thing as a juypter notebook
| without a web protocol, webUI and anything else if you
| wanted an experience that is easier to commit to a git
| repo and has a notion of cells which is the magic sauce
| for juypter (it was originally derived from ipython which
| is a command line interface). I am also a emacs user :)
|
| Juypter has an interface and API built in. What Zasper is
| the reimplementation of the juypter protocol. You can see
| this at [1]. Juypter kernels are very different from
| Mathematica notebooks. Mathematica notebooks aren't
| related to juypter.
|
| Juypter kernels encapsulate language runtimes so that
| they can be interfaced when called from a notebook.
|
| [1] https://jupyter-client.readthedocs.io/en/stable/
| spudlyo wrote:
| 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
| d0mine wrote:
| Have you tried https://github.com/emacs-jupyter/jupyter Eg as
| org-mode code blocks.
| _venkatasg wrote:
| Just wanna say this is a really cool project, and I can't think
| of higher praise than me hoping I build something as cool as
| this some day! I've been meaning to learn Go for sometime now,
| and will be referring to Zasper for the future :)
| crabbone wrote:
| I'm not directly involved with extending Jupyter Lab, but I'm
| involved with the results (and testing) of our extension on the
| daily basis. What I find very often to be the source of
| complaints is the error reporting. In particular, the kind of
| error reporting that just disappears from the screen after few
| seconds. If there's one singular feature of Jupyter Lab that I
| really want changed, it's this.
| filmor wrote:
| It currently hard-codes launching ipykernel, right?
| llm_trw wrote:
| I mean, I appreciate the effort, but my average notebook uses
| gb to tb of ram and vram. At that scale having mb is...
| lutusp wrote:
| > ... 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 a smaller, more efficient REPL
| environment. * Over time ... wash, rinse, repeat.
|
| This BTW is what happened to Sage, which grew over time and was
| eventually replaced by IPython, then Jupyter, then JupyterLab.
| Sage is now an installable JupyterLab kernel, as is Go, among
| many other languages, in an environment that's increasingly
| difficult to install and maintain.
|
| Hey -- just saying. Zasper might be clearly better and replace
| everything, in a process that mimics biological evolution. Can't
| leave without an XKCD reference: https://xkcd.com/927/
|
| Again, not meant as criticism -- not at all.
| RossBencina wrote:
| > JupyterLab kernel
|
| There is no such thing. There are Jupyter kernels. JupyterLab
| is just one of many UIs that speak the Jupyter protocol. Other
| examples include the original Jupyter notebook editor, VSCode
| Jupyter extension, and now Zasper.
|
| I'm pretty sure Sage was always intended as a project that
| integrates the world, never "small footprint".
| lutusp wrote:
| >> JupyterLab kernel
|
| > There is no such thing.
|
| A Web search reveals that the alternate term "Jupyter
| kernel," appears equally often. The terms are
| interchangeable.
|
| > I'm pretty sure Sage was always intended as a project that
| integrates the world, never "small footprint".
|
| A large install became true eventually, but it began as a
| small Python-based install, about 120 KB. Then people asked
| for extensions, and William Stein said "Yes".
| williamstein wrote:
| No.
| lutusp wrote:
| Okay, a slightly exaggerated account.
| williamstein wrote:
| Thanks for explaining that background!
| lutusp wrote:
| You're most welcome -- I was afraid I had offended you.
| Corrections are more than welcome.
| esafak wrote:
| Only on HN!
| prirai wrote:
| 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.
| lutusp wrote:
| > 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.
| __tyler__ wrote:
| How does this compare to Marimo?
| jampekka wrote:
| Doesn't seem to fix the invisible state problem that Marimo
| fixes.
| set92 wrote:
| 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.
| jampekka wrote:
| 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.
| amoss wrote:
| https://docs.marimo.io/guides/expensive_notebooks/
| niyyou wrote:
| 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).
| CraigJPerry wrote:
| >> 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.
| szvsw wrote:
| I actually think the problem you are describing is actually
| sometimes helpful from a design perspective, _if_ you can be
| conscientious enough to periodically review your notebooks
| and figure out what is the actual useful code which should be
| properly integrated into the codebase vs what is the "one-
| off" / non-modular code. Like you mentioned, calculation vs
| side-effects is one way to help you decide but not the only.
| There's definitely no single answer. The key is to just
| periodically figure out what ought to be refactored into
| library code, which notebooks should just be straight up
| deleted (hopefully as many as possible - you can always get
| them back in your git history if needed!), and so on.
| qsort wrote:
| 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.
| ThouYS wrote:
| 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
| mscolnick wrote:
| it's already possible to do this: marimo export script nb.py
|
| Pure-python also helps to work with existing tools out of the
| box: formatting, linting, pytest, importing notebooks as
| modules, composition, PEP 723 inline metadata
| 3eb7988a1663 wrote:
| If you are going to do that, you could stick with Jupyter +
| nbconvert.
|
| I rarely use notebooks directly anymore unless I require
| the output to be stored. Do most everything in VSCode with
| interactive .py files. Gets you the same notebook-y
| experience + all of the Python tooling.
| cess11 wrote:
| How's the maturity compared to Livebook?
|
| https://livebook.dev/
| 1121redblackgo wrote:
| Good looking project I will check this out for sure
| gdevenyi wrote:
| Can I disconnect and reconnect from a running frontend (close and
| reopen a tab) and not lose any output?
| barrettondricka wrote:
| That demo gif is horrible.
|
| You are not showcasing anything, but looping low resolution
| screenshots with special effects.
| JZL003 wrote:
| I'll look later if this is allowed but I would love love an
| rstudio like interface in Jupyter. Being able to control enter to
| run a block of code (not line) in the accompanying repl is huge
| for iterating and building new things
|
| As an example I love jupyterlab's "open console for notebook" but
| can't find a way of sending copied text to it, or switching focus
| with a keyboard shortcut
|
| It's a big reason I can't do vscode Jupiters implementation
___________________________________________________________________
(page generated 2025-01-02 23:00 UTC)