Indeed, it's really great.
It does the smartest thing of all: it creates an HTML page and uses raw JS timed animations to make it work. Then it records it with ffmpeg and saves the output as the final video.
About 6 months ago I spent 12 hours creating a video for our Edge.js [1] announcement that, in the end... people were not very inspired by (to say the least). See the video here [2].
Then, about a month ago, I spent 6 hours creating a video for our Wasmer SDK announcement. It was better, but still didn't go as viral as I wanted [3]. I always thought we would need a big budget to do them.
But then, yesterday I tried Opus 5.5... and man, I'm impressed. The video was one-shotted with this prompt:
Make a modern slick and punchy video for this announcement:
[content of the blogpost in markdown]
I believe it captures each of the frames as png and then ffmpeg puts them together as a video. Although someone from Anthropic may be able to explain this better
I think this showcases the other issue I commented a few years ago [1].
Pyodide and Cloudflare don't use the real network stack for http requests (they patched the functions to use JS `fetch` underneath). They also patched Python's async event loop to use JS event loop.
This has a major downside: incompatibility issues. JS event loop is preemptive (async functions get called regardless of you calling await on them) while Python is lazy (async functions only execute when you await them).
In my belief, the network semantics should be preserved. When the behavior differs issues start arising.
I think the word you want is "eager". Preemptive usually refers to things like signal handlers: when the signal is received the handler "preempts" normal execution without waiting for an explicit yield point.
In any case, with the WebLoop, Python coroutines stay lazy. The fundamental primitive a Python event loop needs to implement is call_later() which maps fairly cleanly to `setTimeout()`.
The reason we want to use the JS event loop is that the JS event loop is where all the actual I/O events in a JavaScript runtime happen. If you create a second event loop and run it, it will block actual IO on the JS event loop. So making uvloop work would be pointless.
> Pyodide and Cloudflare don't use the real network stack for http requests
Pyodide in browsers _can't_ use the real network stack because of fundamental security principles of browsers. With direct networking you could get around the CORS restrictions.
I was very excited when they first launched Python Workers two years ago. Even though we have competing products at Wasmer, I think Cloudflare work is always exciting and inspiring.
I went back to the feedback I posted in the original launch thread [1]. It's great to see that they have made meaningful progress since then, particularly around package support: PyEmscripten is now standardized through PEP 783.
That said, some of the main architectural concerns I raised at the time are still present:
* Being tied to use only one version of Python/Pyodide (the one that Workerd embeds)
* Architecturally tied to the JS/v8 world, which may show some challenges as they aim to reduce cold start times (in my opinion, it will be quite hard for them to achieve <100ms startup time with their current architecture).
In the benchmark we published earlier this year [2], a minimal Python application started in around 60ms on Wasmer Edge versus around 900ms on Cloudflare Workers (backing my concerns from 2024). Those numbers are now several months old, and I hope Cloudflare has improved them significantly since then.
The GA announcement doesn't seem to include updated cold-start numbers. Could someone from the Cloudflare team share the current p50/p95 cold-start times for Python Workers, ideally both with and without native user packages? (for example, one with FastAPI and other without any dependencies).
> Being tied to use only one version of Python/Pyodide (the one that Workerd embeds)
This isn't quite the case, you can choose between different versions using compatibility flags. For example, `python_workers_314` is the compat flag for Python 3.14[1]. You've also got compat flags for 3.13 and 3.12. Though it is worth noting that by using those older versions you will also be using older Pyodide versions too, which have fewer features (for example they lack JSPI support).
> Architecturally tied to the JS/v8 world, which may show some challenges as they aim to reduce cold start times
That is indeed a challenge. But our memory snapshot implementation has improved the cold starts significantly already and we will be working to reduce these even further. We also have sharding these days which reduces cold start frequency a lot. We wrote about cold starts (and sharding) in a previous blog post[2] which includes some numbers.
> it is worth noting that by using those older versions you will also be using older Pyodide versions too
Yeah, I think this summarizes properly the issue I mentioned. Basically compat flags are a global version that affects not only the Python version used but workerd as well. I believe you'll see some architectural issues from this design. Following up on your example, users will not be able to use a previous version of Python that has JSPI included, unless you update the old workerd as well (please correct me if I'm wrong), which will make certain things a challenge as workerd evolves.
> We wrote about cold starts (and sharding) in a previous blog post[2] which includes some numbers
Thanks for sharing. On that blogpost [2] Cloudflare Python Workers startup time was reported to be about 1.027 seconds, which is way behind the numbers we have at Wasmer for cold starts in Python apps (60ms, or 16x faster). That's why I was asking if you guys remeasured and have better timings now :)
We launched Pi support in Wasmer a few days ago and reception has been great (so you can run pi in your iPhone or browser, or even embedded)
We have set up this demo, if you want to try Pi 1.0 online: https://wasmer.sh/?example=pi
(for an easter egg click on the Pi logo on the top left!)
reply