Live data from Hacker News

Pyodide: Bringing the scientific Python stack to the browser

hacks.mozilla.org

71–80 of 120 posts

Re: Pyodide: Bringing the scientific Python stack to the browser

#71

Wow, it seems to work really well. After giving it a small test drive, I'm impressed. Solid work from Mozilla, and a pretty informative article too! That said, between this, iodide and ObservableHQ, I guess I give up. The browser is the new OS. My question now is - how can we make browser environment to be more like Emacs (bear with me)? My main complaints are: - Browser ergonomy absolutely sucks, and there's nothing…

> the other half of the code is on the server

Somewhat of a side note, but the same holds true for many equivalent native apps as well.

> There's near-zero interoperability.

This is the problem that Tim Berners-Lee's SOLID is trying to solve: https://solid.inrupt.com/

Re: Pyodide: Bringing the scientific Python stack to the browser

#72

It's a cool project technically, but I don't understand the use case? I mean surely everyone can just have real python/jupyterlab - if you run it in Docker it's easy to handle the dependencies etc. Am I missing something?

I gave a keynote at PyCon last year that touched on this: https://www.youtube.com/watch?v=ITksU31c1WY#t=32 For me, the most important aspect of Pyodide is that it allows the scientific Python stack to go everywhere the Web goes. And the Web goes everywhere. That means I can share a link to a Pyodide notebook, and the recipient gets a fully interactive experience, no installation required. And that's really important…

As someone not familiar with any of this: is that not exactly what Jupyter Lab does? I understood that the main difference between Pyodide and that is that Pyodide allows you to also use e.g. D3 for rendering?

Re: Pyodide: Bringing the scientific Python stack to the browser

#73

Earlier quoted context omitted.

Fully valid points. And I see no reason why we should accept the urge to use the browser for many tasks which are way better accomplished with existing solutions. After all, aren't we increasing the complexity while limiting functionality and ease of use? Sure, if your core business is in the Cloud and browser market, this may look different, but I believe the terminal will still continue to serve the scientific comp…

I'm getting tired of fighting an uphill battle here. Web technologies have overwhelming dev mindshare; all the cool things happen either as web pages or Electron apps now (which are even worse than web pages, because raw browsers we can upfix a bit with userscripts and plugins). > terminal will still continue to serve the scientific computing community well I hope so, but note how data is on the web, the output is ex…

> the output is expected to be on the web

That's no more true now than it has been for the past 10 to 15 years. However, output is just one view; something that automatically generates HTML to display things, like scientific data, is great, but that's far from the only, or even primary, way that many things are consumed from the internet.

Other views exist that can visualise the same data in other ways. That is, data can be available online without necessarily being web first. Heck, most things are — data provided to mobile apps and desktop clients via services that might have a web frontend.

My personal thinking is that people really are too hooked on this narrative about the browser as an OS, and maybe have gotten tunnel vision from it.

The internet, as it is today, is still mainly services. Many things may be more and more accessible in the web by preference, yet remain freely available and consumable through other forms (REST APIs, direct database access, etc) and delivered through apps and integrations within operating systems. Some examples might include:

- Dropbox: files sync with the various apps and utilities - iCloud: mail, contact, calendar are mostly consumed by the native apps. Pages, Keynote, Numbers documents are mostly edited in the Mac apps. - Office 365: the Windows apps remain the dominant way to access and edit Word, Excel, and PowerPoint documents. - Github: the most popular source code repository today, but still very much consumed at the command line. The website is strongest at wiki editing, forums, and so on, but the bulk of code moving back and forth done with the `git` command or IDE integration.

Let us not underestimate how much of the internet is not primarily consumed in web browsers and likely never will be through the vast majority of certain markets (for instance, developers), where internet-located data will be consumed as services that interact with apps much more than as web sites.

Re: Pyodide: Bringing the scientific Python stack to the browser

#74

I want to believe so bad. Being able to do web development with Python instead of JavaScript has been something I've dreamed about forever.

It was available as browser plugin since the early days, it just went nowhere.

If I remember correctly, ActiveState was the one offering it.

Re: Pyodide: Bringing the scientific Python stack to the browser

#76

Earlier quoted context omitted.

What now? https://www.tensorflow.org/js/guide/platform_environment#web...

I don't know the details but the WebGL backend will have severe limitations because it doesn't use compute shaders or CUDA. This means that certain functionality like random writes to arbitrary buffers can only be emulated through workarounds that are like an order of magnitude slower than using compute shaders, and some things are going to be impossible entirely. There is something about CUDA in the link you provide…

[deleted]

Re: Pyodide: Bringing the scientific Python stack to the browser

#77

Wow, it seems to work really well. After giving it a small test drive, I'm impressed. Solid work from Mozilla, and a pretty informative article too! That said, between this, iodide and ObservableHQ, I guess I give up. The browser is the new OS. My question now is - how can we make browser environment to be more like Emacs (bear with me)? My main complaints are: - Browser ergonomy absolutely sucks, and there's nothing…

Well, I guess we could built up on this old idea.

https://www.lively-kernel.org/

Re: Pyodide: Bringing the scientific Python stack to the browser

#78

Earlier quoted context omitted.

Fully valid points. And I see no reason why we should accept the urge to use the browser for many tasks which are way better accomplished with existing solutions. After all, aren't we increasing the complexity while limiting functionality and ease of use? Sure, if your core business is in the Cloud and browser market, this may look different, but I believe the terminal will still continue to serve the scientific comp…

I'm getting tired of fighting an uphill battle here. Web technologies have overwhelming dev mindshare; all the cool things happen either as web pages or Electron apps now (which are even worse than web pages, because raw browsers we can upfix a bit with userscripts and plugins). > terminal will still continue to serve the scientific computing community well I hope so, but note how data is on the web, the output is ex…

> all the cool things happen either as web pages or Electron apps now

There are also plenty of cool things on mobile OSes.

Re: Pyodide: Bringing the scientific Python stack to the browser

#79

Earlier quoted context omitted.

WebGL doesn't have compute shaders. There are (gross) hacks that "emulate" gpu compute on top of stock shaders but they're limited and can't possibly compete with CUDA.

What now? https://www.tensorflow.org/js/guide/platform_environment#web...

When I last benchmarked tensorflow.js, it was 40 times slower than native tensorflow on my laptop. However, even if WebGL compute shaders were available, Nvidia's cuBLAS and cuDNN libraries would still be faster.

Re: Pyodide: Bringing the scientific Python stack to the browser

#80
post #72

Earlier quoted context omitted.

I gave a keynote at PyCon last year that touched on this: https://www.youtube.com/watch?v=ITksU31c1WY#t=32 For me, the most important aspect of Pyodide is that it allows the scientific Python stack to go everywhere the Web goes. And the Web goes everywhere. That means I can share a link to a Pyodide notebook, and the recipient gets a fully interactive experience, no installation required. And that's really important…

As someone not familiar with any of this: is that not exactly what Jupyter Lab does? I understood that the main difference between Pyodide and that is that Pyodide allows you to also use e.g. D3 for rendering?

A big difference is where Python runs. With Pyodide, everything runs entirely in your browser, and the server side can be completely static. With Jupyter, you need a separate copy of Python running on a server somewhere to actually perform any computation.
Post reply on HN