Introducing PyScript

Posted Jun 22, 2022 22:20 UTC (Wed) by Paf (subscriber, #91811)
Parent article: Introducing PyScript

This is a very fun article about what sounds like a very fun talk!

Introducing PyScript

Posted Jun 23, 2022 3:23 UTC (Thu) by mcon147 (subscriber, #56569) [Link] (16 responses)

Has there ever been discussion about the browser makers providing alternative language options natively alongside js? It seems unfortunate to have to download a wasm cpython

Introducing PyScript

Posted Jun 23, 2022 4:22 UTC (Thu) by JanC_ (guest, #34940) [Link]

Historically there have been many such alternative language options (VBScript, Python, PascalScript, …), but AFAIK each one of them was limited to one browser maker, and most of them date back to when writing a browser (engine) was a lot less complicated than it is now.

Introducing PyScript

Posted Jun 23, 2022 7:11 UTC (Thu) by jokeyrhyme (subscriber, #136576) [Link] (14 responses)

In theory, WASM/WASI paves the way for possible (and distant) future where browsers do not even ship with JavaScript by default, but rather have each web application download the runtimes (and specific versions of runtimes) that they need

e.g. a web developer prefers Apple's JavaScriptCore runtime and rather than testing their app in Google's V8, they just add JavaScriptCore to their page, and even non-Apple browsers download JavaScriptCore when the page loads

Introducing PyScript

Posted Jun 23, 2022 9:11 UTC (Thu) by Wol (subscriber, #4433) [Link] (3 responses)

Isn't that a worry, downloading an executable or something like that?

Or maybe they should just implement "core forth" :-) istr that once you had the minimal version running, most of your typical forth system was written in forth. Similar to lisp. So anything that implemented the bare-bones version could download and run whatever runtime the app developer wanted :-)

The more things change, the more they stay the same ...

Cheers,
Wol

Introducing PyScript

Posted Jun 23, 2022 11:05 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

> The more things change, the more they stay the same ...

Not really. Things are becoming worse. If you want to do GUI in browser you have to use JavaScript (or something compileable to JavaScript), or else things wouldn't work reliably.

PyScript doesn't do that which, basically, means it would interact poorly with browser extensions, etc.

Means we would have even more flaky and unreliable GUI.

Pity, really: as computers become more powerful and robust the end-user things become ever more finiky and fragile.

Introducing PyScript

Posted Jun 23, 2022 14:13 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

> If you want to do GUI in browser you have to use JavaScript

Is this because the DOM is only accessible through JS APIs? Or is it something else?

Introducing PyScript

Posted Jun 24, 2022 16:29 UTC (Fri) by khim (subscriber, #9252) [Link]

Yes. DOM can only be synchronously accessed by JS.

And if you recall that extensions can (and do) modify DOM while you app is running…

It's possible to write GUI in JS or JS+Something… but at this point battle is already lost: JS is just simpler.

If you want to have some reliable web app then you have to have JS-based “agent” which does actual interaction with DOM and if you have resigned yourself to the fact that you would have part of the code in JS (or something JS-targetable like Dart or TS)… the desire to do GUI in anything else just vanes.

Introducing PyScript

Posted Jun 23, 2022 10:59 UTC (Thu) by khim (subscriber, #9252) [Link] (8 responses)

> In theory, WASM/WASI paves the way for possible (and distant) future where browsers do not even ship with JavaScript by default, but rather have each web application download the runtimes (and specific versions of runtimes) that they need

Nope. Wouldn't work. You couldn't implement JavaScript API on top of WASI.

Browsers makers made sure that JavaScript can not be ever replaced when they killed NPAPI.

Even when Google tried to push PPAPI it made sure it was crippled enough before it shipped it.

There was brief excitement when NaCl was first released (projects like NaTcl and other such things) and then Google decided it needs to ensure that NaCl would be DOA and crippled PPAPI.

They kept uncrippled version for some time, but it was only accessible to Flash plugin (and was one of the main reasons why they wanted that plugin dead) and now it's gone, too.

Thus… don't hold your breath. JavaScript is here to stay.

Introducing PyScript

Posted Jun 23, 2022 14:14 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (7 responses)

Fascinating. Do you have any insight into the motivations behind these cripplings?

Introducing PyScript

Posted Jun 24, 2022 4:37 UTC (Fri) by samlh (subscriber, #56788) [Link] (5 responses)

There are several competing goals in browser development:
- Security (non-negotiable)
- Providing a cross-platform runtime (Windows/MacOs/Android/..., x86/arm/arm64/...)
- Performance
- Providing features to developers

Unfortunately, all the acronyms that khim mentioned had significant problems, meaning that all the browser developers agreed they were not acceptable to keep long-term (or were even dead on arrival).

The NPAPI plugin API was primarily about allowing Flash and Java to be embedded into webpages. This was great early on, as Flash had better APIs than what was available to JS, at least in it's niches.

The big downside: Java, then Flash, were the cause of a never-ending stream of security issues that the browser developers could not fix themselves. In addition, malware developers loved to prompt folk to install "Flash", and thus infect people's PCs.

The other major downside was that it was a totally separate development experience. Making a plugin was quite hard to do well, so basically only Flash was really worth it. Flash was nice, but had totally different APIs than what was available to JS, and the browser developers had a significant maintenance burden keeping Flash working.

In the end, the vast majority of Flash usage in practice was ads, games, and (IMO) shitty websites. When JS was able to replace Flash for ads and games, browser developers finally removed support for NPAPI. I do miss the games, but I don't miss the Flash ads or the folks who tried to make full on websites in Flash.

PPAPI was NPAPI "reimagined", with most of the same problems - it really wasn't too interesting, and didn't have a particularly long lifespan.

The original NaCl was x86 only (non-portable), so it was dead on arrival.

The successor PNaCl was built on top of LLVM bitcode, but the real problem was that it had significantly different APIs available to it than what was available to JS.

Firefox and IE had significant market share at the time, so their refusal to do the (significant) development effort to support the PNaCl APIs (which I think was the right call), basically made it DOA as well.

WebAssembly is PNaCl done right - it has good interop with JS so there aren't 2 different sets of APIs, it is portable, and it's design is well-thought out security-wise. Huzzah, finally!

Introducing PyScript

Posted Jun 24, 2022 5:14 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> PPAPI was NPAPI "reimagined", with most of the same problems

PPAPI was much better than the current WebAsm API. Also, it's insulting comparing PNaCl that actually involved engineers designing it to WebAssembly that was designed by W3C.

PPAPI+PNaCl allowed fully asynchronous access to DOM, non-brainded threading, exception handling, setjmp/longjmp, SIMD, etc.

Heck, it supported gotos while WebAssembly still forces compiler writers to use nested loops with flags to emulate them. Try to disassemble a Go binary compiled for WASM and weep.

Introducing PyScript

Posted Jul 1, 2022 3:25 UTC (Fri) by clay.sweetser@gmail.com (guest, #155278) [Link] (1 responses)

Huh. Do you know any resources discussing the architecture and details of PPAPI? It sounds like it was quite an interesting effort.

Introducing PyScript

Posted Jul 1, 2022 8:36 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

It was not terribly popular even back in the day, and I can't find a mailing list that I used for information on it (RIP GMane).

But it honestly was a pretty logical API design, with out-of-process sandboxing and a fairly typical functionality (communication with the browser side via messages, access to files, graphics, etc.)

Introducing PyScript

Posted Jun 24, 2022 15:51 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

> The original NaCl was x86 only (non-portable), so it was dead on arrival.

It was never given the chance. Version with sane (NPAPI-style) API was never made available and version with crippled PPAPI was only ever made available for the Chrome Web Store (which was never popular and is now almost gone completely).

Note that while, technically, binaries were x86-only they were forced to be fully decompileable (for security purposes) which meant that is was trivial to make a AOT cross-compiler. But that wasn't sexy enough, had little chance to give nice bonus/raise for any PM thus such approach was rejected.

> WebAssembly is PNaCl done right - it has good interop with JS so there aren't 2 different sets of APIs, it is portable, and it's design is well-thought out security-wise. Huzzah, finally!

Webassembly is, essentially, DOA, too.

Web technologies had a short window of opportunity around when first version of NaCl was released.

But that one was killed for political reasons. When PNaCl and Webassembly arrived the need for complex web apps was not there anymore: if you want to do something more complex than web site with three buttons you have to provide iOS and Android apps anyway, and while you can use something like Flutter to save a bit of development costs the urge to create cross-platform web apps is just not there.

For web sites with three buttons there are more than enough JavaScript-capable developers, anyway.

Introducing PyScript

Posted Jun 30, 2022 10:47 UTC (Thu) by mrugiero (guest, #153040) [Link]

Seeing how pervasive Electron apps are (much to my grief), this whole "can't use webapps for serious stuff" sounds like nonsense. Those are glorified webapps running on a bundled Chromium browser and a lot of consumer applications are leaning on that.

Introducing PyScript

Posted Jun 24, 2022 15:36 UTC (Fri) by khim (subscriber, #9252) [Link]

The road to hell is paved with good intentions.

JavaScript, NPAPI (and special Flash-only PPAPI functions) provided blocking access to DOM.

That was considered problematic by browsers developers: bad plugin may render any web page unresponsive!

Dream solution: provide asynchronous interfaces and people would write asynchronous apps. Everything would be rainbow and ponies.

Grim reality: people don't know how to make asynchronous interfaces, thus they try to emulate synchronous API on top of the asynchronous one. This works badly (if there are no way to ensure DOM is frozen while you are working with it then sooner or later something would misbehave), web apps are laggy and barely usable, but hey, it's not browser developer's fault is it?

Introducing PyScript

Posted Jun 29, 2022 14:48 UTC (Wed) by eru (subscriber, #2753) [Link]

That would make page loading even slower than now. Load the extension language and possibly compile it into whatever the browser supports natively. Load its libraries. Load the script...