Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

Here's the package: https://pypi.org/project/luau-wasm/

  import micropip
  await micropip.install("luau-wasm")
  import luau_wasm
  print(luau_wasm.execute(r'''
  local animals = {"fox", "owl", "frog", "rabbit"}
  table.sort(animals, function(a, b) return #a < #b end)
  for i, name in animals do print(i .. ". " .. name .. " (" .. #name .. ")") end
  '''))

Wrote about this in more detail on my blog: https://simonwillison.net/2026/Jun/13/publishing-wasm-wheels...

From https://news.ycombinator.com/item?id=43201706 :

> jupyterlite-xeus supports environment.yml with jupyterlite with packages from emscripten-forge: https://jupyterlite-xeus.readthedocs.io/en/latest/environmen...

emscripten-forge was a Quetz repo built with but is now hosted on prefix.dev.

From https://emscripten-forge.org/blog/ :

  pixi run setup

  pixi run build-emscripten-wasm32-pkg recipes/recipes_emscripten/regex

Does cibuildwheel already have this new support for building WASM pyodide packages?

Does jupyterlite's `micropip install` install these new WASM packages from PyPI?

Tbh I don't feel great about people just writing up a bunch of scripts pulling things just on every run.

Something as little as the runtime can just get exploited (which that as happened.) and cause a sandbox escape on the client side. There was a Chrome 0day at the runtime level which allowed untrusted code to run and escape the sandbox in the WASM runtime.

This complete worship of WASM (and their runtimes) as this magical silver bullet reminds me of the days and failures of Native Client (NaCL), Java Applets and Flash all over again.

[1] https://github.com/bytecodealliance/componentize-py [2] https://peps.python.org/pep-0816/

It feels like nobody actually consulted actual compiler writers when designing this. I'm sure that isn't true, but it definitely feels that way. (I suspect the truth is that they were consulted, but ignored.)

It means codegen needs to resort to all sorts of hacks (like the relooper) in order to target WASM, a property not shared by any other target.

And apparently, the way they handle variables also results in deoptimization, though I don't recall the details of that.

Add the fact that interacting with the browser on the web still has to go via JavaScript to this day (for the most part, at least), and, well.

---

TL;DR a combination of poor IR design that has a massive impedance mismatch with pre-existing compilers (and most new ones, because it turns out there's a reason the WASM approach isn't standard) plus WASM still being a second-class citizen in its supposed primary environment (the 'W' in WASM) --- the former ensures targeting it consumes a lot of resources/time, the latter ensures the bar for that to be worth it is much higher.

You can target most architectures with little trouble (at least a a baseline --- optimization's a hard problem regardless of target, except maybe SPIR-V due to the recommendation that pre-optimization is limited in scope). But WASM is completely out there, it's closer to trying to target e.g. Java (not JVM!) at the backend instead of machine code or some other IR.

You don't make an IR intended to be targeted by existing/native compilers by making it completely different to anything they had to target before and completely different to their own IRs and representations ... unless you're the guys behind WASM.