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

11–20 of 68 posts

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

#11

Post by pjmlp »

croes wrote: post #5
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.

Isn't that not just Java all over again, but this time with JavaScript?

Java and Flash, but now it is Good (TM), because the powers that be decided so.

"Everything Old is New Again: Binary Security of WebAssembly"

https://www.usenix.org/conference/usenixsecurity20/presentat...

So, enjoy the 2nd coming of applets/flash,

https://platform.uno/

https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

https://tinygo.org/

.... favourite stack compiled into WASM.

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

#12

Post by throwaway894345 »

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 than to pull tens-thousands of GB of data to your local machine. Moreover, I don’t know of many local machines with tens of CPU cores, hundreds or thousands of GB of RAM, or tens-hundreds of TB of SSD for handling that computation quickly.

User devices are great for very small data, but I don’t see the point for larger datasets.

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

#13

Post by OldTimeCoffee »

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…

Most users don't have 'tens-thousands' of GB of data as part of their use case. You're describing a business case, not an end user consumer case.

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

#14

Post by egeozcan »

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…

To be fair, "we don't need more cloud computing" doesn't mean, "we don't need any cloud computing".

I don't agree that we don't need more of cloud, IMO we do, but we need to focus on personal computing much more than now, which is the general theme of the GP comment.

Not everything is big data.

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

#15

Post by throwaway894345 »

egeozcan wrote: post #14
throwaway894345 wrote: post #12

Earlier quoted context omitted.

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

To be fair, "we don't need more cloud computing" doesn't mean, "we don't need any cloud computing". I don't agree that we don't need more of cloud, IMO we do, but we need to focus on personal computing much more than now, which is the general theme of the GP comment. Not everything is big data.

To be clear, I’m not talking about big data. More impotantly though, I didn’t say there was no place for client compute, only that it isn’t economical for datasets in excess of a few GB.

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

#16

Post by adimitrov »

croes wrote: post #5
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.

Isn't that not just Java all over again, but this time with JavaScript?

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 browser's JS engine

- Wasm code is very fast and can achieve near native execution speeds. It can make use of advanced optimisations. SIMD has shipped in Chrome, and will soon in Firefox

- The wasm spec is very, very good, and really quite small. This means that implementing it is comparatively cheap, and this should make it easy to see it implemented by different vendors.

- Java was just Java. Wasm can serve as a platform for any language. See my earlier point about the spec

So it's apples and oranges. The need to have something besides JS hasn't gone away, so their use cases might be similar. The two technologies couldn't be more distinct, though.

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

#17

Post by throwaway894345 »

OldTimeCoffee wrote: post #13
throwaway894345 wrote: post #12

Earlier quoted context omitted.

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

Most users don't have 'tens-thousands' of GB of data as part of their use case. You're describing a business case, not an end user consumer case.

I don’t believe that the majority of Jupyterhub users are “consumers” rather than professionals, but more importantly, that doesn’t change the fact that the professional use case exist and isn’t amenable to the fat client approach.

As an anecdote, I work on a Jupyterhub managed service offering with customers in both the private and public sectors and our data sizes are pretty much all in this range.

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

#18

Post by [deleted] »

throwaway894345 wrote: post #17
OldTimeCoffee wrote: post #13

Earlier quoted context omitted.

Most users don't have 'tens-thousands' of GB of data as part of their use case. You're describing a business case, not an end user consumer case.

I don’t believe that the majority of Jupyterhub users are “consumers” rather than professionals, but more importantly, that doesn’t change the fact that the professional use case exist and isn’t amenable to the fat client approach. As an anecdote, I work on a Jupyterhub managed service offering with customers in both the private and public sectors and our data sizes are pretty much all in this range.

[deleted]

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

#19

Post by mrtesthah »

throwaway894345 wrote: post #17
OldTimeCoffee wrote: post #13

Earlier quoted context omitted.

Most users don't have 'tens-thousands' of GB of data as part of their use case. You're describing a business case, not an end user consumer case.

I don’t believe that the majority of Jupyterhub users are “consumers” rather than professionals, but more importantly, that doesn’t change the fact that the professional use case exist and isn’t amenable to the fat client approach. As an anecdote, I work on a Jupyterhub managed service offering with customers in both the private and public sectors and our data sizes are pretty much all in this range.

> I work on a Jupyterhub managed service offering ...

That sounds like selection bias.

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

#20

Post by croes »

adimitrov wrote: post #16
croes wrote: post #5

Earlier quoted context omitted.

Isn't that not just Java all over again, but this time with JavaScript?

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 like the JVM to access the file system and such, we get the same problems.

Post reply on HN