Live data from Hacker News

Pyodide: Bringing the scientific Python stack to the browser

hacks.mozilla.org

11–20 of 120 posts

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

#11
It's great to see how far WebAssembly and Emscripten has come and this is a really cool app!

> If you haven’t already tried Pyodide in action, go try it now! (50MB download)

I wonder though how ready is it for production usage. At Repl.it, years ago[1], we moved away from browser-based execution to the cloud because it excluded many users who don't have the client-side firepower to download/parse/execute this much JS/WASM.

Repl.it can already run a lot of the examples here [2] but I gotta say the DOM-integration is pretty neat. We could do interactive stuff on Repl.it using our new Graphics infrastructure (GFX)[3] but there is always the roundtrip delay. Here is the same matplotlib example running and streamed down on X11: https://repl.it/@amasad/matplotlib

[1]: https://news.ycombinator.com/item?id=16578943

[2]: https://repl.it/@amasad/pyodide-example

[3]: https://repl.it/blog/gfx

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

#13

Earlier quoted context omitted.

Why not just use Django or Flask? Python web dev is great because you do have access to so many of these incredible scientific libraries like Pandas, etc.

I don't know anything about web dev, so maybe it's a stupid question, but you still need javascript for the front end, right? You can't build the front and back end development completely in python?

I think they're implying that you use a Python web framework and server-side rendering.

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

#14
post #11

It's great to see how far WebAssembly and Emscripten has come and this is a really cool app! > If you haven’t already tried Pyodide in action, go try it now! (50MB download) I wonder though how ready is it for production usage. At Repl.it, years ago[1], we moved away from browser-based execution to the cloud because it excluded many users who don't have the client-side firepower to download/parse/execute this much JS…

That is no doubt great tool. But imagine even one guy like me has manny gpu card for trying some large memory ai model (not even production). It just can’t work on the cloud during development.

What the appeal of this is Standardise on certain way to do things and we can share with others. So far all python and r notebook. Is browser an option?

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

#17
Would be curious to see if a version of Cython could be made to work with this. Much of my data analysis is me passing numpy arrays into C functions which Cython helps a lot with. So I would be looking for a version of Cython that would convert that to webassembly.

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

#18
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 you can do about it. You're at the mercy of each service's UI, which usually means you'll be clicking a lot and maybe sometimes get a keyboard shortcut here and there. Forget about advanced features, or consistency between sites.

- You have near-zero control over your computing environment. Between sandboxing and half the code being obfuscated blob of transpiled JS (the other half of the code is on the server), you can maybe automate the UI a little with userscripts and fix it up with userstyles.

- There's near-zero interoperability. Unless service authors agree on and implement some APIs, things can't talk to each other. Forget about making them talk. Whatever little wiring you can sometimes do (thanks to services like Zapier and IFTTT), you never have control over the process, and it always involves communication through third-party servers, even if all you'd like is to transfer some local data between browser tabs.

If the browser is the next OS, can we make it suck less than desktop OSes in terms of ergonomy / productivity? Desktop OSes already suck in this regard compared to the promise of old Smalltalk and Lisp systems (that's why I live in Emacs most of the time), so all I see is a downwards trend.

Current state of things is fine for casual use and casual users, but if I'm to spend 8+ hours a day doing serious work in a web browser, the browser needs to be better.

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

#19
post #14
post #11

It's great to see how far WebAssembly and Emscripten has come and this is a really cool app! > If you haven’t already tried Pyodide in action, go try it now! (50MB download) I wonder though how ready is it for production usage. At Repl.it, years ago[1], we moved away from browser-based execution to the cloud because it excluded many users who don't have the client-side firepower to download/parse/execute this much JS…

That is no doubt great tool. But imagine even one guy like me has manny gpu card for trying some large memory ai model (not even production). It just can’t work on the cloud during development. What the appeal of this is Standardise on certain way to do things and we can share with others. So far all python and r notebook. Is browser an option?

Browsers don't expose access to GPU compute APIs or multiple GPUs. Any web GPU usage you see right now is limited to shader programs on a single GPU.

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

#20
post #16
post #10

Can it run cuda? Otherwise not that practical. Minor interest. Can this approach run j/k or more important lisp?

Most practical python programs do not use CUDA, even scientific ones.

Says the mkl user.

(Sorry, couldn't resist).

Post reply on HN