What is new is old again.
ActivePython was available via the <object /> tag for Internet Explorer back in the early 2000's.Reply
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
Maybe it is sad, but it’s definitely the shortest path to brining modern frontend dev to Python.Reply
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?Reply
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 languagesReply
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.
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 JSReply
Related, I work on Nitro, 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, 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.Reply
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.Reply
Does WASM end up succeeding generally where Parrot seems to have done otherwise? Right now WASM is browser-bound, but that did not stop Node.Reply
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.Reply
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.Reply
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?Reply
Deno also touts its permission system. It will be interesting to see if both get interesting use.
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:
In Python, this will be compiled into: a call to range(), heap allocation of an Iterable, calling getIterator() on an Iterable (which might also do allocation), calling next() on an Iterator while catching for StopIteration exception (and calls are often slow in interpreted languages). While in C we could just have a loop without any calls.
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.Reply
Does anyone else remember the Java <applet /> days? It seems like we've come full circle after twenty years.Reply
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.
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!Reply
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.Reply
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.Reply
I was looking at PyScript and I was disappointed when I saw this code.
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.Reply
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 , which lets you write your web app in Python, which gets rendered using Svelte-based components:Reply
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.
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.Reply
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)
Both node and Ruby have a comprehensive C API, this is a very common language feature since binding to native libraries is unavoidable. Is there actually anything different about python here?Reply
> 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".
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 pillsReply
Nice! Fans of the two most awful languages fighting each other. I'm just gonna grab some popcorn!Reply
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.Reply
My first impressions using pyscript:Reply
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.