JupyterLite is a great project!
Addressing some other comments: the main limitation you'll find is probably the filesystem. WASM File System APIs are not extremely well evolved and (i think?) they're still in-memory FSs.
JupyterLite: a JupyterLab distribution that runs in the browser
11–20 of 58 posts
Re: JupyterLite: a JupyterLab distribution that runs in the browser
#12JupyterLite is a great project! Addressing some other comments: the main limitation you'll find is probably the filesystem. WASM File System APIs are not extremely well evolved and (i think?) they're still in-memory FSs.
Files seem to persist even after quitting chrome, refreshing or closing the tab. I'm not an expert, but assume it's cookie storage.
Re: JupyterLite: a JupyterLab distribution that runs in the browser
#13JupyterLite is a great project! Addressing some other comments: the main limitation you'll find is probably the filesystem. WASM File System APIs are not extremely well evolved and (i think?) they're still in-memory FSs.
Files seem to persist even after quitting chrome, refreshing or closing the tab. I'm not an expert, but assume it's cookie storage.
I think JupyterLite is using localStorage by default. But there are File System APIs for WASM and some external projects[0], I don't think they're yet integrated.
Re: JupyterLite: a JupyterLab distribution that runs in the browser
#14Earlier quoted context omitted.
Files seem to persist even after quitting chrome, refreshing or closing the tab. I'm not an expert, but assume it's cookie storage.
I think JupyterLite is using localStorage by default. But there are File System APIs for WASM and some external projects[0], I don't think they're yet integrated. [0] https://github.com/jvilk/BrowserFS
> I think JupyterLite is using localStorage by default
This has been a problem when using Konqueror.
Re: JupyterLite: a JupyterLab distribution that runs in the browser
#15Earlier quoted context omitted.
Files seem to persist even after quitting chrome, refreshing or closing the tab. I'm not an expert, but assume it's cookie storage.
I think JupyterLite is using localStorage by default. But there are File System APIs for WASM and some external projects[0], I don't think they're yet integrated. [0] https://github.com/jvilk/BrowserFS
Thanks, yes I see it now. It stores the notebook, which is a json, as a value in the localStorage object, with the filename as a key. Interesting, yes, not quite easy to configure (though I haven't read through the documentation or code to find this).
Re: JupyterLite: a JupyterLab distribution that runs in the browser
#16Starboard.gg is similar but also allows JavaScript, CSS, or HTML cells to execute in the same notebook. Python has access to the DOM and can share variables with JavaScript.
I love the idea of Starboard. But seems like the development has stalled?
Re: JupyterLite: a JupyterLab distribution that runs in the browser
#17JupyterLite is such an incredible piece of software. It came out of the Pyodide project, which first got Python compiled to WebAssembly working in the browser. It really is astonishing that they've managed to get the full data science Python stack - a lot of it based around custom C extensions (numpy, Pandas etc) running entirely in the browser.
it's neat, but it's kinda slow (25x slower than native when I tested it)
In a JupyterLyte notebook:
import numpy as np
a = np.random.randn(128,128)
b = np.random.randn(128,128)
%timeit a @ b
1.5 ms ± 3.3 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
$ python3 -m timeit --setup 'import numpy as np; a = np.random.randn(128,128); b = np.random.randn(128,128)' 'a @ b'
5000 loops, best of 5: 59.4 usec per loopRe: JupyterLite: a JupyterLab distribution that runs in the browser
#18Unreal. How does this stack up against a cluster based approach for large datasets?
It runs on your local machine through an intermediary compilation unit, so I think in comparison to a cluster the answer is “poorly”. This is for quickly spinning up an analysis without any of the traditional hosting mechanisms (virtualenvs, docker, etc).
I think of it as a fantastic teaching tool where getting a newbie’s environment configured would otherwise be painful. With this tool, you can share a link and have people coding in moments.
Re: JupyterLite: a JupyterLab distribution that runs in the browser
#19What exactly is Jupyterlab and how does it fit into the Jupiter ecosystem? There are notebooks and jupyterlab and jupyterhub, but I haven’t found anything documenting what role each fulfills.
Jupyter Notebooks was the start (of things Jupyter)
Then people said it can be tough for people who want to do data analysis to have to figure out installing python locally and getting everything set up to run notebooks just to open a web browser, so JupyterHub was created so that Data Analyst types didn’t have to worry about any of that, they could just open a web browser and work (also running on a server lets you have a beefy server to connect to).
JupyterLab is the next version of Jupyter Notebooks, separating some of the concerns on the back end and giving a bit of a different interface on the front end.
Re: JupyterLite: a JupyterLab distribution that runs in the browser
#20JupyterLite is such an incredible piece of software. It came out of the Pyodide project, which first got Python compiled to WebAssembly working in the browser. It really is astonishing that they've managed to get the full data science Python stack - a lot of it based around custom C extensions (numpy, Pandas etc) running entirely in the browser.
it's neat, but it's kinda slow (25x slower than native when I tested it) In a JupyterLyte notebook: import numpy as np a = np.random.randn(128,128) b = np.random.randn(128,128) %timeit a @ b 1.5 ms ± 3.3 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each) On my command line: $ python3 -m timeit --setup 'import numpy as np; a = np.random.randn(128,128); b = np.random.randn(128,128)' 'a @ b' 5000 loops, best of…
Not that I expect this to have fantastic performance, but I think your benchmark is cheating. Locally hosted Jupyter is going to have significant overhead compared to a straight Python interpreter.