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

Pyodide: Bringing the scientific Python stack to the browser

hacks.mozilla.org

Post reply on HN
Print view View original

91–100 of 120 posts

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

#91

Post by pkghost »

TeMPOraL wrote: post #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…

Hypothesis: it would be better to live in a world where UI is mostly user-authored, and B2C is mostly an API marketplace.

In other words, imagine that instead of being forced to digest a plurality of static and unforgiving view hierarchies from designers on high, you have with a single, long-lived, personalized UI that is flexible, changes with your needs, and allows you to integrate new data and services alongside or into existing workflows. Think of it as a personal UI agent.

I like this model of software primarily because of how much creative power and agency it gives end users. "B2C" could end in "creator" instead of "consumer". It's unix-y in its composable nature, and more in line with the hopes we had for the web's ability to unlock creativity in its infancy.

It also seems like a step towards a world where we see fewer ads, because there's more of a culture of paying for digital products by usage or subscription (though ad-supported options would remain; I don't see this as a revolution against ad-supported models).

Obviously, lots of challenges to execution, but would love to hear of anyone else thinking along these lines!

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

#92

Post by stult »

amelius wrote: post #85
callahad wrote: post #80

Earlier quoted context omitted.

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.

Wouldn't it be more straightforward then to compile Python to WASM, and combine the resulting binary with Jupyter so everything can run in the browser?

Compiling Python to WASM was far from straightforward. That's essentially all Pyodide is, and why it is impressive. Presumably no one has taken the time to combine it with Jupyter since it is so brand spanking new.

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

#94

Post by zamadatix »

jononor wrote: post #83
zamadatix wrote: post #19

Earlier quoted context omitted.

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.

Tensorflow.js can actually use WebGL to accelerate machine learning. Have not tried it though.

Tensorflow.js is a example of using the fragment shaders I was talking about:

"Tensors are stored as WebGL textures and mathematical operations are implemented in WebGL shaders." https://www.tensorflow.org/js/guide/platform_environment

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

#95

Post by fulafel »

speedplane wrote: post #50
VectorLock wrote: post #3

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.

I find it ridiculous that javascript is the only language available for the web. Almost every other platform, from bare metal to Excel, support multiple languages. It's well past due to untie the browser from a mandated language.

You've been living under a rock :)

People are using a variety languages that compile to JS on the frontend for many years. Elm, TypeScript, ClojureScript, Reason, Scala.js, Fable, etc. In fact even modern JS is often compiled into backward compatible legacy-JS these days.

WebAssembly is porting the C machine model to the web, so for the foreseeable future JS is still going to be a better runtime for most GCd languages.

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

#96

Post by bglusman »

pkghost wrote: post #91
TeMPOraL wrote: post #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…

Hypothesis: it would be better to live in a world where UI is mostly user-authored, and B2C is mostly an API marketplace. In other words, imagine that instead of being forced to digest a plurality of static and unforgiving view hierarchies from designers on high, you have with a single, long-lived, personalized UI that is flexible, changes with your needs, and allows you to integrate new data and services alongside o…

I like the idea, but I think most users never would/could author their own UI's, and many who could would only want to a small percentage of the time.... but maybe your idea could work if there was essentially an API marketplace AND a UI marketplace, and services competed on both of them seperately... v1 from a service would (probably) always offer both to be usable but if it published some contract for how they talk to each other so they were decoupled and anyone could author a new UI (and, I suppose if it were a marketplace, sell it, but maybe given constraints only selling the API is realistic and UI is more FOSS/enthusiast driven/fork based?) and make it discoverable as an alternative to try out.

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

#97

Post by TeMPOraL »

pkghost wrote: post #91
TeMPOraL wrote: post #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…

Hypothesis: it would be better to live in a world where UI is mostly user-authored, and B2C is mostly an API marketplace. In other words, imagine that instead of being forced to digest a plurality of static and unforgiving view hierarchies from designers on high, you have with a single, long-lived, personalized UI that is flexible, changes with your needs, and allows you to integrate new data and services alongside o…

> Hypothesis: it would be better to live in a world where UI is mostly user-authored, and B2C is mostly an API marketplace.

I tentatively believe in this hypothesis. That's part of the reason I moved most of my computing into Emacs - I get greater control over the UI there, and reap the benefits of deep interoperability.

I think this would be a working system. You'd have a separate market for services, and a separate market for software consuming these services. I doubt most regular people would become full-blown creators, but they would happily shop for more ergonomic tools and customize them to the limit of their needs. It's kind of similar to the "right to repair", where nobody honestly expects that everyone will be fixing their appliances themselves - the point is that those who can, would, and they would also offer their services to those who can't or don't want.

I'm not sure how to get to this world. That's kind of the question in my original post - I see fixing the browser for productive use to be a potential stepping stone involving the same or similar changes.

I have one idea I'm hesitant about: it would be nice if we could force all services on the Internet to communicate with open and documented protocols and APIs, while simultaneously banning any kind of "you can only use our official app" clauses in ToS. That is, force the decoupling between a service and client software that consumes it.

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

#98

Post by fulafel »

armitron wrote: post #24
geofft wrote: post #12

Earlier quoted context omitted.

You can do GPGPU stuff via WebGL, right?

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.

People have been doing GPU computation for a long time before the gl "compute shader" feature. There's nothing emulationy about it. The shading language (GLSL) and available data types are the same in "compute shaders" and the familiar fragment/vertex shaders.

Compute shaders are just a shader type in OpenGL (and possibly a future version of WebGL) that have some convenient properties, for example they can more easily run out of step with the rendering pipeling if you have an application wanting to mix OpenGL/webGL graphics and non-graphics compute concurrently. See eg https://www.khronos.org/opengl/wiki/Compute_Shader#Dispatch

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

#99

Post by TeMPOraL »

bglusman wrote: post #96
pkghost wrote: post #91

Earlier quoted context omitted.

Hypothesis: it would be better to live in a world where UI is mostly user-authored, and B2C is mostly an API marketplace. In other words, imagine that instead of being forced to digest a plurality of static and unforgiving view hierarchies from designers on high, you have with a single, long-lived, personalized UI that is flexible, changes with your needs, and allows you to integrate new data and services alongside o…

I like the idea, but I think most users never would/could author their own UI's, and many who could would only want to a small percentage of the time.... but maybe your idea could work if there was essentially an API marketplace AND a UI marketplace, and services competed on both of them seperately... v1 from a service would (probably) always offer both to be usable but if it published some contract for how they talk…

I agree with your points here, and I think two markets - service API market and client software market - would be a great thing to have. One of the things that makes a lot of services suck (social media platforms in particular) is the control they have on APIs they provide. To pick one example, I can sort of use the Facebook API for some of the things, after jumping through enough contractual hoops, but I can't really go and build a Facebook client that would have feature parity with the official one. Not without risking my account getting banned. I especially couldn't distribute such a client either.

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

#100

Post by TeMPOraL »

pjmlp wrote: post #90
TeMPOraL wrote: post #81

Earlier quoted context omitted.

Most of which are webpages in a webview these days; mobile software is also much more skewed towards casual use due to device form factor. Here I'm focusing on more professional or even prosumer use cases.

Not really, plenty of native code as well. Also both iOS and Android have very interesting architecture features, still not widespread on desktop OSes.

> Also both iOS and Android have very interesting architecture features, still not widespread on desktop OSes.

Most of those are heavily favouring security at the expense of interoperability and user control. Not exactly the direction I'd like things to see heading on the desktop. Compared to laptops and PCs, mobile devices are essentially interactive TVs.

Post reply on HN