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

101–110 of 120 posts

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

#101

Post by TeMPOraL »

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

Well, I guess we could built up on this old idea. https://www.lively-kernel.org/

Interesting, but that's still something to be used within a web application. Here, I'm talking about fixing up the browser. I don't see how I could use Lively Kernel to e.g. force consistent advanced autocomplete UI on every text field in every tab, or to shuttle data between two tabs harbouring applications that were not explicitly designed to talk to each other.

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

#102

Post by sandGorgon »

alexgmcm wrote: post #60

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?

interoperability between the js and python ecosystem. This is pretty much a holy grail. By interoperability, I mean python functions can render to the browser and your javascript functions can include a python library directly.

have a single runtime (js) execute both your front end and backend code.

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

#103

Post by TeMPOraL »

zapzupnz wrote: post #73
TeMPOraL wrote: post #65

Earlier quoted context omitted.

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…

> That's no more true now than it has been for the past 10 to 15 years.

It is, though. 10 years ago I'd expect to get a PDF or an .XLS or a bundle of Matlab code. Maybe a static page. Today, if you can't interactively explore the data in the browser, it's considered subpar.

> 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

Disagree. The Internet may be mostly services, but they're services with default UIs you're forced to use, and are not freely consumable through other forms. REST APIs are restricted both in terms of features and what ToS allows you, and more often than not you couldn't build an alternative UI with feature parity to the original one.

> Dropbox: files sync with the various apps and utilities

Sorta, kinda. Can I have an alternative implementation of the Dropbox client? The problem isn't bad here though - Dropbox does one thing and does it well, i.e. syncing files with real OS-es and their filesystems. You can work with that to the extent your OS lets you.

> Pages, Keynote, Numbers ... Office 365

All being increasingly replaced by Google Docs, because it's free and you already have an account. You can't edit those outside the browser.

> Github

Exception, not the rule, and it's an artifact of the fact that developers still mostly work on desktop OSes with real filesystems. I'm worried about the future in which we'll all be using some future evolution of VS Code in the browser, communicating with future Github in the background over some APIs you can't hook into.

I'm not saying everything is in the browser now. But it sure as hell looks like in 10 years it'll all be.

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

#104

Post by _visgean »

maxnoe wrote: post #86
_visgean wrote: post #82

Earlier quoted context omitted.

Not just that, but a lot of organization use the setup to give good starting interface to data scientist who might know nothing about how to set up all the python packages...

A data scientist wo knows nothing about how to setup the tools he or she uses daily? Tell me more.

Well I have some friends doing genetics and their infrastructure is maintained by IT team. For them the whole programming experience is connecting to jupyter server running on pre-configured server. I think there are even some online services offering this kind of configuration for teams.

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

#105

Post by TeMPOraL »

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

These are some good points. One small way in which Iodide advances this is that by having the editor being a single text editing widget (rather than multiple cells as you see in Jupyter and others), it should be easier to replace that widget with an alternative editor, or (using an extension) link to a native editor on the machine. But all of these other issues, I agree, are things that would be nice to improve upon.…

Sure, I'm not saying Pyodide team should take that on! You've already done an awesome job, and the whining in my comments isn't aimed at you - it's aimed at the direction computing is heading, of which your project is but a symptom. Right now there isn't much you could do; the browser platform isn't geared towards this kind of user-driven interop.

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

#106

Post by fulafel »

mschuetz wrote: post #68
armitron wrote: post #24

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.

Compute shaders are available on chrome on windows if you start chrome with some flags. Here are some compute shader demos: https://github.com/9ballsyndrome/WebGL_Compute_shader And here is a draft spec for WebGL2 Compute: https://www.khronos.org/registry/webgl/specs/latest/2.0-comp... Only a matter of time until this will be available in chrome and firefox by default. Probably never in Safari though, since it doesn'…

I wonder why they are talking about "WebGL 2 compute" instead of a new WebGL version based on GLES 3.1. WebGL 2 is based on OpenGL ES 3.0, and the major feature of OpenGL ES 3.1 was compute shaders.

Apparently one snag in all this is that Apple's OpenGL version is stuck in a time before compute shaders, and all Mac/iOS browsers currently implement WebGL on top of OpenGL. (ANGLE doesn't support Metal).

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

#107

Post by saboot »

make3 wrote: post #43
saboot wrote: post #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.

isn't it already doing that, converting the C generated by Cython to JS with emscripten? otherwise a huge amount of numerical libs wouldn't work. or did you mean directly without passing by C

I'm not sure, I didn't see Cython in the list of supported libraries. But if it's doing what you described yes that would be awesome.

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

#108

Post by dekhn »

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…

The browser developers have some hard constraints that prevent them from making the browser better for desktop applications. There were a lot of battles at Google over making ssh work in the browser while supporting standard terminal keyboard shortcuts. Even today I hate working in Jupyter because I can't alt-tab-navigate the tabs (it switches browser tabs).

Everything you described is an expected consequence of inner platform syndrome. It would have IMO been better if libraries like qt made cross-platform, network-driven desktop application development the preferred software delivery mechanism.

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

#109

Post by jononor »

mdboom wrote: post #22
saboot wrote: post #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.

Cython works for ahead-of-time compilation. (Pandas requires it, for example). Making it work in the browser would also mean putting a C compiler there, which people have done. I have no idea how well that would all hold together, though.

Ideally Cython would allow to compile directly to Webassembly (and maybe using Pyodine converters), without going through C and requiring a C compiler also.

Of course that is a huge job and might very well never happen.

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

#110

Post by pjmlp »

TeMPOraL wrote: post #100
pjmlp wrote: post #90

Earlier quoted context omitted.

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.

From architecture point of view there are plenty of interesting things to explore beyond security.

But yeah, I want to see sandboxes everywhere and also enjoy the direction that OS X and Windows are going into that regard.

Post reply on HN