wasthon (real CPython C via WASM) vs Brython native (pure-Python or JS reimpls).
What matters here is the "Match" column, not the speedup.
Wasthon's _random is CPython's actual Mersenne Twister C source
compiled to WASM, so the same seed produces the same sequence as
CPython on desktop — code that depends on reproducible randomness (testing,
simulation, scientific reproducibility) works identically in browser and
on the server. Brython ships its own MT reimplementation in JavaScript, but
it is not guaranteed bit-exact with CPython's MT. Same ballpark speed; only
one is bit-exact with the rest of the Python ecosystem.
| Operation | wasthon ms/call | Brython ms/call | Speedup | Match (sample) |
|---|
| Operation | wasthon ms/call | Brython ms/call | Speedup | Match |
|---|
Two distinct verdicts here:
Brython's unicodedata is a thin wrapper over the browser's
built-ins — it lacks category() and name()
entirely (those rows FAIL on the Brython column). Wasthon is the only way
to call them from browser-Python.
On the other hand normalize() in Brython delegates to
String.prototype.normalize(), a heavily-optimised C++
function in V8/SpiderMonkey. Wasthon goes through its WASM unicodedata
with per-character table lookups, so it loses on this op — predictable
and accepted: we can't beat the browser's own native Unicode normalizer.
| Operation | wasthon ms/call | Brython ms/call | Speedup | Match (sample) |
|---|