Introducing PyScript (summary of PyCon keynote)

What is new is old again.

ActivePython was available via the <object /> tag for Internet Explorer back in the early 2000's.

https://www.componentsource.com/product/activepython/about

Article reports the guy as saying you can't use Python to do a GUI Windows app. Actually there are lots of ways to do this -

* Panda3D's main language is Python

* Godot has Python bindings

* So does raylib

...

No, this is not a project to replace javascript in the browser, this is a project to give Python apps an html-rendered frontend. And yes, you should expect this to be packaged in electron apps.

Maybe it is sad, but it’s definitely the shortest path to brining modern frontend dev to Python.

Will PyScript honour the same naming tradition as JavaScript (which has nothing to do with Java) and thus have nothing to do with Python?

Wow. The article means using pandas in the in-browser demo.

How do they do it? The whole point of numpy and pandas stuff is that they are Fortran and C code that does numeric operations very quickly, while the Python part gives a nice and ergonomic interface on top of them.

So they are showing a WASM port of NumPy / Pandas now, with the Python interface finally surfacing in the browser. It should be a very fair bit slower than native code, though.

Are we seeing the Atwood Law stumbling? That is, things are still migrating into the browser, but to WASM instead of JS now?

I really, REALLY hate the idea of fracturing the frontend ecosystem further with another scripting language option when there is already an absolutely insane overabundance of tools and frameworks for JS alone

It should at this point be enshrined as an official binding standard that browser UAs must support JS and must NOT support any other scripting languages

How does this compare to Brython? [0]

Brython uses:

    <script type="text/python">

From like 2003 to 2010 I loved Python. I was happy to code in it. Found it much better than Perl, my previous no-manual-compile-link-step language. I was mostly a C++ developer but wrote several large tools in python.

I slowly started making more JavaScript stuff and used Selenium (python IIRC).

Then I started learning node. Liked npm's default to local project installs vs python's default to system installs. Eventually I started writing the command line tools that I'd have written in python previously in node. node had some sync I/O so it wasn't hard. Then promise/async/await arrived and I was fully in. I haven't written much python in probably 9 years now.

When I do look at python, I don't feel it's better. I'm not saying it's worse nor am I saying it's not better, rather I'm saying it doesn't *feel* better. Basically I've learned JS inside and out and I'm super comfortable there.

I find it easier to get node installed on multiple platforms and installing it locally without root/admin privileges is trivial via nvm. I'm sure that's possible with python but it's certainly not the default. And of course the browser is everywhere so it's just way more accessible/sharable in JS

Related, I work on Nitro[1], which already offers a polished set of widgets, and a very simple way to author web apps using Python. I'll be releasing Pyodide support this week.

I also contribute to Wave[2], which provides a wide variety of widgets that can be snapped together quickly to build realtime dashboards/apps.

Both help non-front-end folks build web apps, and require no knowledge of HTML/JS/CSS.

[1] https://github.com/h2oai/nitro

[2] https://github.com/h2oai/wave

I'm using the underlying project, Pyodide, to launch a worker that can execute code and provide autocompletions (via jedi) to a codemirror editor. I'm not super crazy about the startup times, but I'm hoping that there will be more work to help optimize it further.

Does WASM end up succeeding generally where Parrot[1] seems to have done otherwise? Right now WASM is browser-bound, but that did not stop Node.

[1] https://en.wikipedia.org/wiki/Parrot_virtual_machine

I just love LWN for how impartial and informative it is. It's a bit clunky with 20x"he said", but it sure does a good job of giving me a balanced idea of what this is all about! Happy to be a subscriber.

Isn't this the same idea as GWT (which is Java in the browser)? That one turned out to be impractical, e.g. for debugging.

Browsers definitely need an alternative to JavaScript but this doesn't look like the native integration I was hoping for.

Hello World example:

15 requests. 21.65 MB / 7.66 MB transferred. Finish: 8.19 s. DOMContentLoaded: 707 ms. load: 2.95 s.

no, stop. I'm super confused about the obsession of clonking specifically the reference implementation when other implementations exist, like micropython for example. Sure, less compatible, but you are already not getting native modules so shrug?

This is also sandboxed FWIW. It means users could write plugins in Python and have them run securely, much like browsers running JavaScript, and games that have Lua scripting.

https://webassembly.org/docs/security/ https://www.reddit.com/r/WebAssembly/comments/ryz2zz/are_was...

Deno also touts its permission system. It will be interesting to see if both get interesting use.

micropip is impressive. A lot of JavaScript dev still depends heavily on Node, to the point that only one browser-based build tool exists that can handle most projects and they're keeping it proprietary: https://blog.stackblitz.com/posts/introducing-webcontainers/

The article describes what is possible with Python in a browser, but misses an important detail: how much memory it consumes and how much CPU it uses.

Python is not a fast language. For example, consider a simple loop:

    for i in range(10):
        pass

I remember how I had to use a Dart-based web application (compiled to JS) in one of Google's advertising products. The script weighed around several megabytes and everything was so slow. Furthermore, there also was a small and useless "what's new" applet, and it probably was shipped with a separate copy of Dart runtime because it weighed several megabytes too. Obviously this was a product intended to be used only on latest MacBooks, not on a Windows XP laptop.

It is totally fine to write such application for youself, or maybe for internal use, but if you are a corporation with millions of users, I think you should pay a little attention to performance and choose a better technology. Or, if you are of a Google scale, find a way to optimize the code.

I use to want this. Then I learned JavaScript, and decided it's a much better language for the browser than Python is.

Does anyone else remember the Java <applet /> days? It seems like we've come full circle after twenty years.

I don't see much point in going from one dynamic untyped language to another. Javascript and Python offer much of the same advantages and disadvantages, but having to deal with the overhead of running python code seems to just saddle it with tradeoffs for no real benefit. Learning one or the other is fairly easy too.

May as well write Javascript directly, as NPM is not short on packages if that's what you need. I see more value in going from higher level languages like ReScript, Purescript, Melange (Reasonml + Rescript compiler) to Javascript. You have to deal with things like code interop, strictness, overhead of compilation, but you at least gain in safety and succinctness.

They say that Python has good bindings to C extensions, but for C libraries compiled to WebAssembly, someone will probably write some nice JavaScript bindings, so you might as well use JavaScript.

Meanwhile, JavaScript has been extended with so many language features that it's hard to see another scripting language giving people good reasons to switch. In the early days, JavaScript programming was very limiting and alternatives had a chance, but those days are pretty much over and I'd recommend just learning JavaScript.

(I say this as someone who spent more time exploring alternative languages than writing JavaScript by hand. Nowadays it's hard to come up with a good reason to bother.)

I would love to see Python in browsers more than Javascript. But since this works through WASM, I'd probably stick with Rust in that case.

If I'm going to be bound by the limitations of how immature WebAssembly is right now, I'd at least use its more mature ecosystem for development, which is Rust. And actually, I recently began doing so in my free time with a framework named Yew[1].

I know that it's unrealistic to expect Python to be a first-class citizen in browsers as JS is, but at some point we'll grow tired of reading "X language is now available for browsers" when it's more like "X can do WASM now".

edit: Anyway, I don't want to come off as under-appreciative of PyScript. I'm sure a lot of people will love it and make it grow a lot. I'd probably give it a try someday too. Props to the developers!

1 : https://github.com/yewstack/yew

PyScript seems interesting, but must we have infomercial-level hyperbole at the adversity of the status quo to sell it?

> For example, you cannot write iOS apps with Python. You cannot create an application for Windows—the most popular corporate desktop—with a user interface

You can, in fact, do both of those things with Python. Heck, the latter you can do with the standard library alone.

While I love the tech behind this (as well as the good article and fun demo video), I'm very skeptical that this will be a good approach for most web apps. I hope it doesn't turn into Python programmers suddenly pulling in 7MB of WASM code/data just to render their websites (along with a 5s startup time), adding yet another layer of complexity and virtualization between their code and the browser. I think the interest in the tool is overall a good thing, but I think we need to be very careful about what kinds of projects we use this for.

I was looking at PyScript and I was disappointed when I saw this code.

https://pyscript.net/examples/d3.html

The python version is much much slower loading at least on my browser. I counted 7 seconds to having it render the graph.

I kinda wish they spent the time thinking about Dom manipulation from a pythonic point of view rather than just providing the python to js interface and calling it a day.

An alternative, which doesn't require insane loading times, is to use any of the many great Python libraries that allow you to write web apps in Python, which get converted to JS web apps.

For example, I'm one of developers of Gradio [0], which lets you write your web app in Python, which gets rendered using Svelte-based components:

[0] https://www.gradio.dev

Ya know, it’s funny. I like Python. We like it enough to actually use it in embedded products. It has its limits, and we use other tools where it doesn’t fit. Python in a browser seems like a keen idea.

But JavaScript vs Python isn’t really the key thing for me on the web. It’s the uncanny pile of other software one uses to build a man-machine connection that flummoxes me. It’s the CSS, the DOM, the events, the browser API, the ever churning massive pile of complexity that interactive software has become with the voluminous W3C specs, expressed in near BNF form and full of edge cases and backwards compatibility, all so every thing my user does can be observed by myself a few megacorps. I honestly wouldn’t care if I could write it in Fortran. It’s such a minor wart of the whole mess.

Caring about which actual language you can use in all the script tags of a jacked up text format feels like caring which font is being used in your favorite hot piece of government legislation.

At https://hal9.com, we built components for data science in native JavaScript to avoid the waiting times and download overhead if Pyodide. We found out the best tools for doing data science in the browser are a combination of Arquero and D3 and TensorFlow.js. At least for now.

We wrote our findings of this and many other libraries here: https://news.hal9.com/posts/data-science-with-javascript

I'm really enthusiastic about what's happening with PyScript as the opportunities for the right use cases are enormous.

That said, it has really brought out the knee-jerked clichéd responses:

- X is way better than Y

- X is the Y killer / no it isn't

- Did you know Python is really slow?

- Sure you can, but why do this? (implication: don't do this)

To add to the fun, it attracts huge interest, and amongst those interested are a weird set of people who seem to know little about Python, little about JavaScript and seem unable to read before they try something impossible and then post a query about why their almost certainly never-going-to-work attempt hasn't worked! It needs plenty of patience pointing them to the huge pile of matching queries! I'm sure something will be done to give those types a friendly nudge in the right direction.

  > But there is another aspect of the language that makes it so desirable from his standpoint: it can be extended with binary extensions that use an API that is written in C, but can be accessed from other languages. He likens Python to "a Honda Civic with mounting bolts for a warp drive". So the language can be picked up by kids who can then pop open the trunk "and bolt on warp nacelles" that allows the code to run faster than C or C++ in some cases, Wang said.
  > 
  > That aspect is sometimes overlooked, but it means that Python can be used in ways that other, similar languages cannot. "It's not just like Node, it's not just an alternative to Ruby".

https://nodejs.org/api/n-api.html https://silverhammermba.github.io/emberb/c/

let's be real, this has no chance of seeing any real adoption, except as a novelty or for technical demos, because the runtime takes multiple seconds to download, which is insane. reading that document without anything addressing this felt like I was taking crazy pills

Nice! Fans of the two most awful languages fighting each other. I'm just gonna grab some popcorn!

This is a laudable effort, but I'm not a fan of shipping the entire interpreter. I looked around a few weeks ago and found https://transcrypt.org, which compiles your Python script to JS, so size is minimal.

It's great for shipping small, internal tools/apps, I love how maintainable they are by all the Python devs, plus they're very fast to load and execute.

My first impressions using pyscript:

https://pwhiddy.github.io/more-writing/2022/05/05/Pyscript-T...

The video of this presentation is here: https://youtu.be/qKfkCY7cmBQ

What I really hate about this is the absolutely disastrous API. From the <py-script> tag that could easily have been more standard-ish <script type="text/python">, to <py-config> and <py-env> that embed YAML for some reason, to weird custom components like <py-inputbox> that don't integrate with existing ecosystem at all. Brython, albeit still clunky, got it a lot better.

[Brython]: https://www.brython.info/