Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JupyterLite – WASM-powered Jupyter running in the browser

github.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: JupyterLite – WASM-powered Jupyter running in the browser

#41

Post by atoav »

ipsum2 wrote: post #6
atoav wrote: post #3

Earlier quoted context omitted.

The solution I use for local jupyter notebooks is nteract [0] which is like a standalone application that can edit/open .ipynb files. It has a few quirks, but works quite good for daily use. [0] https://nteract.io/

What do you like about nteract over Jupyter's frontend? The website is devoid of details.

I like that it is a standalone notepad.exe-like program that opens my notebook and just works. I usually use it more for looking at notebooks than writing them tho.

Re: JupyterLite – WASM-powered Jupyter running in the browser

#42

Post by westurner »

croes wrote: post #20
adimitrov wrote: post #16

Earlier quoted context omitted.

There are crucial differences between Java applets and JS. - Applets tried to render their own GUI, Wasm doesn't and defers to the browser. - applets needed a big, slow to start and resource hungry VM. Wasm is running in the same thread your JS is also running in, it's light, and loads faster than JS - Java and flash were plugins, which needed to be installed and kept up to date separately. Wasm is baked into your br…

You must view the browser with JS and WASM as a unit. The browser renders it's own GUI too, it's not OS native The browser uses lots of resources too. The browser is kind of a plugin to the OS and must be updated separately. Java nowadays is pretty fast too. Java VM serves a platform for multiple languages like Scala, Kotlin, Clojure. Let's face it, the browser is the new JVM and a soon it gets the same permissions l…

From https://news.ycombinator.com/item?id=24052393 re: Starboard:

> https://developer.mozilla.org/en-US/docs/Web/Security/Subres... : "Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match."

> There's a new Native Filesystem API: "The new Native File System API allows web apps to read or save changes directly to files and folders on the user's device." https://web.dev/native-file-system/

> We'll need a way to grant specific URLs specific, limited amounts of storage.

[...]

> https://github.com/deathbeds/jyve/issues/46 :

> Would [Micromamba] and conda-forge build a WASM architecture target?

Re: JupyterLite – WASM-powered Jupyter running in the browser

#44

Post by mrtesthah »

throwaway894345 wrote: post #24
mrtesthah wrote: post #19

Earlier quoted context omitted.

> I work on a Jupyterhub managed service offering ... That sounds like selection bias.

It might be. Like I said: anecdote.

Isn't it, though? The people most likely to need a cloud-managed service like that probably have too much data to crunch on a laptop, as you described.

Re: JupyterLite – WASM-powered Jupyter running in the browser

#45

Post by throwaway894345 »

mrtesthah wrote: post #44
throwaway894345 wrote: post #24

Earlier quoted context omitted.

It might be. Like I said: anecdote.

Isn't it, though? The people most likely to need a cloud-managed service like that probably have too much data to crunch on a laptop, as you described.

Ah, to be clear I’m not saying our users are a representative sample of Jupyterhub users. I am saying that there are a lot of people who use Jupyterhub for large datasets—it’s certainly not uncommon.

Re: JupyterLite – WASM-powered Jupyter running in the browser

#46

Post by kierangill »

croes wrote: post #20
adimitrov wrote: post #16

Earlier quoted context omitted.

There are crucial differences between Java applets and JS. - Applets tried to render their own GUI, Wasm doesn't and defers to the browser. - applets needed a big, slow to start and resource hungry VM. Wasm is running in the same thread your JS is also running in, it's light, and loads faster than JS - Java and flash were plugins, which needed to be installed and kept up to date separately. Wasm is baked into your br…

You must view the browser with JS and WASM as a unit. The browser renders it's own GUI too, it's not OS native The browser uses lots of resources too. The browser is kind of a plugin to the OS and must be updated separately. Java nowadays is pretty fast too. Java VM serves a platform for multiple languages like Scala, Kotlin, Clojure. Let's face it, the browser is the new JVM and a soon it gets the same permissions l…

> You must view the browser with JS and WASM as a unit

“Web” assembly is a bit of a misnomer. It’s an IR at the end of the day and can be run without a browser[1]. But your other points could be true one day if the de facto WASM runtime becomes bloated or decides to ship with some GUI renderer.

[1] https://github.com/bytecodealliance/wasmtime

Re: JupyterLite – WASM-powered Jupyter running in the browser

#47

Post by huac »

throwaway894345 wrote: post #12
ktpsns wrote: post #2

Despite Pyolite has a miserable performance (20MB of downloads), the overall project direction is correct. I said this already 10 years ago: We don't need more cloud computing but need to empower users end devices again. Jupyter is typically operated on powerful notebooks and not on mobile devices.

> I said this already 10 years ago: We don't need more cloud computing but need to empower users end devices again. Jupyter is typically operated on powerful notebooks and not on mobile devices. If you’re working with data of any significant size at all it then it doesn’t matter how fast your user device is—it’s so much cheaper (time and network egress costs) to send the computations from a user device to the cloud t…

Not only do cloud services offer better compute capabilities (and GPUs/TPUs etc), but they offer easier reproduciblity and sharing. Even when I hack on stuff myself, Colab is quick and easy to set up, no worrying about Docker or virtualenvs.

Re: JupyterLite – WASM-powered Jupyter running in the browser

#48

Post by jcims »

Godel_unicode wrote: post #40
jcims wrote: post #27

Earlier quoted context omitted.

Unfortunately we will need more cloud computing. If you're watching what's going on in the ransomware and cyber insurance space, small and many medium-sized companies that require E&O coverage for their contracts are not going to be able to afford to run on their own equipment.

Good. People who are bad at administering computers will stop doing it, and will focus on what they're good at. Then, we can use the on-demand nature of cloud services to reduce their power consumption. Simultaneously we can move that consumption into renewable-powered datacenters. This is literally better for everyone.

Meanwhile we create tremendous concentration risk and the world pays rent to Amazon, Google and Microsoft? I wouldn't call that 'good'.

Re: JupyterLite – WASM-powered Jupyter running in the browser

#49

Post by qbasic_forever »

This is _really_ cool. I don't know why a lot of commenters here are going into the weeds to grouse about Java, flash, and general anger at computational notebooks.

What we have here is a complete client-side browser environment for development. Not some half-assed language or hyper restricted toy--this is real Python, and your browser's full JS engine all available in JupyterLab's IDE (basically a simpler VS Code at this point, it uses the same editing component).

We all freaked out a bit as Apple drove out IDEs from their app store, Google locked down Termux and similar developer tools from Android. Well, here's the answer to those situations. Something no app store owner can kill on a whim. I love stuff like this and hope it helps to enable and inspire the next generation of developers.

Re: JupyterLite – WASM-powered Jupyter running in the browser

#50

Post by qbasic_forever »

airocker wrote: post #43

The kernels will still run on the cloud I believe. It would be great if Jupiter works better for larger programs and ui development.

No, read more from the README. This uses pyodide, a WASM port of desktop Python that runs entirely in the browser (obviously stuff like file access is sandboxed). In addition it adds a web worker that runs a Javascript kernel powered by your browser's JS engine. All of this runs 100% in your browser, there is no server component at all.
Post reply on HN