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

111–120 of 120 posts

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

#111

Post by ptx »

jdpigeon wrote: post #31
chowes wrote: post #21

Earlier quoted context omitted.

Why wouldn't you just use regular Python?

My goal would primarily be to avoid having to make sure there's an active python installation with all the right dependencies set up on a client's computer. That's been a huge problem for me in the past during deployment (esp. older windows OS's). A nice side benefit I foresee would be easier coordination of state between a JS front end and a Python process running specialized computations. The current best approach…

You can bundle the whole Python distribution with your application and it will still be smaller than Electron. Recent releases of Python have an embeddable distribution for this purpose: https://docs.python.org/3.7/using/windows.html#windows-embed...

This is also the way Java is supposed to be deployed on client machines nowadays, apparently - using the jlink tool to create a bundle of the Java runtime for your application.

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

#112

Post by Pete_D »

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…

I think it's impossible. We lost. The incentives aren't there for interoperability and support for client-side customization to meaningfully improve - big names will resist, either because it makes it easier for users to sidestep ads and tracking, or because the kinds of features it would require aren't within reach of the minimum viable user (https://www.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...).

Legally-enforced open APIs and client-agnosticity like you mention downthread sounds wonderful (maybe we could start by deprecating the User-Agent header) but for similar reasons, I can't see it ever taking off.

Pessimism notwithstanding, here's an idea: imagine a browser extension where you could implement privileged pages/tabs that had access to other tabs' script environments/DOM, and could inject elements from other pages into itself. So you could write a workflow like:

1. open a Wikipedia page in a background tab (`const wiki = new Tab(etc...);`)

2. run some JS to pick out values from a in it

3. open a Google Docs spreadsheet in a background tab

4. fill out the spreadsheet using the previously obtained data

5. as a bonus, inject the table + spreadsheet elements into the extension page for side-by-side reference

Not sure what the emacs analogy would be - maybe something like org-mode and Babel being able to generate things using the contents of other buffers.

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

#113

Post by spurgu »

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

I think it's impossible. We lost. The incentives aren't there for interoperability and support for client-side customization to meaningfully improve - big names will resist, either because it makes it easier for users to sidestep ads and tracking, or because the kinds of features it would require aren't within reach of the minimum viable user ( https://www.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr... ). Legall…

Puppeteer?

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

#114

Post by TeMPOraL »

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

I think it's impossible. We lost. The incentives aren't there for interoperability and support for client-side customization to meaningfully improve - big names will resist, either because it makes it easier for users to sidestep ads and tracking, or because the kinds of features it would require aren't within reach of the minimum viable user ( https://www.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr... ). Legall…

> The incentives aren't there for interoperability and support for client-side customization to meaningfully improve - big names will resist, either because it makes it easier for users to sidestep ads and tracking, or because the kinds of features it would require aren't within reach of the minimum viable user

Yup. Also, because of security - that, I imagine, will be the argument legitimizing the whole thing. I'm acutely aware how interoperability conflicts with security. Every security compromise you make to make the software be more useful is something that can be a way for users to self-pwn when subjected to social engineering attacks. My Emacs is a monster of productivity, but then again it's so niche that nobody is writing elisp malware.

> Not sure what the emacs analogy would be - maybe something like org-mode and Babel being able to generate things using the contents of other buffers.

Your example is actually something one would do in Emacs - (1) open a buffer with some data in the background, (2) copy the interesting parts, (3) paste it into a new buffer in some specific major mode that helps you (4) restructure the data, and (5) show the work; all in a single step you could bind to a key or button.

Different example of Emacs-style integration I'd like to do: run all my IMs in the browser (FB Messenger, Slack, Skype, Telegram) as background tabs, and have a resident piece of code that reacts to new messages in each and aggregates them, displaying a foreground tab with "event stream" ordered by time (and possibly a "reply" button). Kind of like IRC channel unifying all your browser IMs, with ability for you to add new ones without having to deal with OAuth and API calls to IM servers.

Elsewhere in the thread[0], 'zapzupnz says that "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.". Well, so how come I can't easily do automated queries to my bank to fetch my balance, put it in whatever accounting app I want to use, and display it on my personal dashboard for extra fun? The only way I can do this today is through scripting around bank's authentication and scrapping their page - which risks termination of account for ToS violations. This is less about the browsers and more about API control and problematic ToS - but it would be mighty easier to do if I could easily shuttle arbitrary data between browser tabs myself.

BTW. this thread made me realize that I'm not very clear on what a browser extension can or can't do; maybe the situation is slightly better than I think. Need to check it out.

--

[0] - https://news.ycombinator.com/item?id=19680964

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

#115

Post by frmdstryr »

arduinomancer wrote: post #35
outlace wrote: post #33

Can this be used to create a desktop application using Electron?

That would be an interesting stack if you could write desktop apps using Python but use the DOM/Browser stuff for the UI layer.

https://github.com/codelv/enaml-web/ does exactly that

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

#116

Post by colobas »

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 think you're mistaking Cython (Python extended with C - https://cython.org/) and CPython (the canonical Python implementation, written in C)

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

#117

Post by zapzupnz »

TeMPOraL wrote: post #103
zapzupnz wrote: post #73

Earlier quoted context omitted.

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

> Today, if you can't interactively explore the data in the browser, it's considered subpar.

PDFs still remain a primary form of interchange for academic documentation. People who really want to crunch the data will want raw data files or some sort of common interchange format.

> but they're services with default UIs you're forced to use

I gave a bunch of examples where you're not forced to use them. Most of the popular web services are also available through apps on mobile.

> REST APIs are restricted both in terms of features and what ToS allows you

For public REST APIs, sure. For private use, it's still things like REST and whatnot that power desktop and mobile apps, bringing data from those internet-based services to local clients, completely bypassing the web.

> Can I have an alternative implementation of the Dropbox client?

You can, but that isn't the point. The point is that the Dropbox client, the executable program or mobile app, is how people tend to use Dropbox. If not that, people also connect to Dropbox through alternative third party apps.

Completely possibly, and I wager mostly the case, to bypass the web.

> All being increasingly replaced by Google Docs

Citation needed.

> You can't edit those outside the browser

You can, using Google's apps. They're not fantastic, but that's not the app's fault, that's Google's. Meanwhile, iWork and Office 365 let one easily edit documents with the desktop and mobile apps — and Office remains king of the hill in enterprise, whatever people may wish to believe.

> Exception, not the rule

But still highly relevant.

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

It really doesn't. There's no pattern from which to base this. Apps are far more popular, especially thanks to the rise of smartphones; the web remains a convoluted mess of inconsistent looks and feels that increasingly assume a high-quality broadband connection even though there are still vast portions of the developed world that still don't have adequate internet to completely shift away from local apps; and plenty of enterprises still run on older versions of software and standards.

When one examines the whole picture, the web is far from being as ubiquitous as you imagine it to be or shall be — it's merely the next biggest alternative that happens to be huge.

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

#118

Post by solatic »

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 think having a distinct separation between back-ends and swappable front-ends would be a good thing, but by this point, it would require government intervention to make it happen. Twitter, Facebook, etc. froze out third-party clients to protect their advertising revenue. They're not going to let third-party clients back in unless they're forced to, and such a move by the government would be tantamount to declaring war on the advertising industry, so, it's not likely to happen.

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

#119

Post by make3 »

colobas wrote: post #116
make3 wrote: post #43

Earlier quoted context omitted.

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 think you're mistaking Cython (Python extended with C - https://cython.org/ ) and CPython (the canonical Python implementation, written in C)

I don't think I am

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

#120

Post by jonrgrover »

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…

To do this we need to build technologies that can work with information and meaning in code in addition to data. Users think in terms of information and meaning much more than in terms of data. These technologies would allow us to build code in the language that users use. This will give us the right tools to build meaningful user interfaces easily. In other words, we need the right tools for the job. I am building one of the many tools needed for this. It is called the endeme. It is a library for c# that can be found here: https://github.com/jonrgroverlib/InfoLib. Discussion can be found here: https://thisstack.wordpress.com.
Post reply on HN