syrusakbary

That's great!

Also awesome to see that you guys are using Wasmer/WASIX under the hood. Would love to schedule some time to chat to see how we can help! (feel free to ping me at [email protected] )

> I believe Cloudflare is the only FaaS that offers that

Wasmer also offers the same (charging only for active CPU usage), with the advantage that you can run full Node.js and Python workloads

https://wasmer.io/

The point of Wasm is that can run anywhere, the goal of Wasmer is to run real workloads on WebAssembly. In my view Wasmer relates quite a bit to MXC generally, and to your first comment particularly.

If you think my comments do not add value, you can simply skip interacting. They might still be useful for others though :)

> the goal of the project is to make all these interfaces plugable with reference implementations that can sit on common infrastructure

That's great to hear.

> You'll have to find me in person over drinks somehow. ;)

Challenge accepted!

I believe Wasmer is the only one that let you use unmodified Python (which can run native modules and even sqlalchemy/gevent), or run Node.js workloads fully... so even if there are many WebAssembly runtimes, there's only one that mostly cover the POSIX semantics

We have Wasmer :)

https://wasmer.io/ (some cool examples here https://wasmer.sh/)

Thanks for chiming in Kenton.

> workerd and its semantics are not exclusive to Cloudflare infrastructure

I believe they are. You may be able to run workerd, but you can't run D1 (Sqlite alternative), you can't run KV or Queues (please correct me if I'm wrong).

All those are primitives that already exist in the non CF world: KV can be easily redis/memcached. Queues, Kafka and so on. I believe that a system that reuses those would be stronger.

> I really wish I was allowed to say who because one of the users is hilariously ironic

Ok, this peaked my curiosity. Would be great if you could share it!

> consortium of companies invested in using the runtime

I believe this is very unlikely to happen. If the founder (Ryan) was involved in it or it have strong market position, it would have strong chances.

Now, is a kingdom without a king and without strong companies to steward it forward. I hope to be wrong though!

I believe it indicates a healthy market and pushes competition and better outcomes for customers. In this case, Deno pushed Web primitives for Node.js and Bun pushed forward on speed (and helped Node.js work on their numbers better).

This have a similar analogy with browsers. Back then when Internet Explorer was the only supported browser, the websites were not evolving as fast. When Firefox pushed it forward and then Chrome, customers won (better and faster sites).

I'm happy that the Deno team found a suitable home. Cloudflare is likely the best place for them to land. I believe they will do great things together. However, I'm a bit concerned that there are very few independent Node.js runtimes: Anthropic acquired Bun, and now Deno will not be developed further.

Somehow I don't believe that Cloudflare doubling down on their own runtime -workerd, which will be likely migrated to Rust soon [1]- is the right choice (since it push on semantics that can only be run on Cloudflare infrastructure). I strongly believe Node.js semantics are likely the right ones for agents.

If anyone is looking for a full-open source alternative to Node.js that can run everywhere (browsers, phones or servers), please be aware that you can rely and use Edge.js [2] (disclaimer: Edge.js is part of the company that I founded: Wasmer)

[1] https://x.com/KentonVarda/status/2108559594691690663

[2] https://edgejs.org/

Love your profile. I just wish you were based in Europe (we are hiring in Europe at Wasmer)

Same! Pi is incredibly exciting.

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!)

Nice!

This is great. A few days ago we were able to enable running Pi fully in the browser (and in the iPhone). Demo here: https://wasmer.sh/?example=pi

I'd be curious if we could compile Rpi to WASIX (https://wasix.org) and get it there as well!

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

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]

This is what Claude Opus 5.5 one-shotted (tl;dr: we went viral): https://x.com/wasmerio/status/2102849543260029379

[1] https://edgejs.org/

[2] https://x.com/wasmerio/status/2033966082944577693

[3] https://x.com/wasmerio/status/2094845905379922302

> I think the word you want is "eager".

Yup, thanks for the correction! (and appreciate the extra insight!)

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.

[1] https://news.ycombinator.com/item?id=39907240

Thanks for chiming in!

> 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 :)

Great work from the Cloudflare team!

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).

[1] https://news.ycombinator.com/item?id=39907120

[2] https://wasmer.io/posts/wasm-clouds-the-world-after-containe...

This is incredibly impressive. Great work!

We will launch very soon the Wasmer SDK with support for mobile (androids and iOS)

Wait to see what Wasmer has in store... :P

ahahaha

It's refreshing to see more self-made JS runtimes.

I'd love to see if I can integrate it onto Edge.js for full Node.js support ( https://edgejs.org )

Fixed!