Agreed that it's far from perfect, and there's a lot of work to be done to make sure all the common native code libraries are well-supported.
But, what I find really interesting is, we are finding it a lot easier to transpile other "managed" languages to JavaScript than to target WebAssembly. Building Python to Wasm hasn't worked well so far because the code footprint is quite large, and brings with it a whole language runtime including interpreter, garbage collector, API glue, etc. Whereas if we transpile to JS, we get V8's built-in GC, and it's much easier to call into existing high-level JS APIs. The result is nice, low code footprint, which can be distributed to thousands of edge nodes at low cost and can start up very quickly.
Both transpiling and Wasm approaches come with challenges when you want to support native-code extensions: the corresponding native library itself needs to be ported to Wasm. (Once it has, then it can be called by Wasm code or JS code, so it seems like whether or not the rest of the app is Wasm or transpiled is not critical.)
There are plans to extend Wasm to support built-in GC. Maybe then Wasm will make sense for managed languages. But, right now we're seeing Wasm is best-suited to C/C++/Rust, while transpiling is a better way to support most other languages.
(I'm the tech lead for Workers, though I wasn't directly involved in this specific project.)
I totally understand that CPython is too heavy to build for WebAssembly and the limitations of Transcrypt are very reasonable for what the Transcrypt project is aiming to do. It's neat that it works at all as a backdoor way to run some Python-looking code on CF and it's a cool OSS project.
But I also don't think that a light transpiler is ever going to get anywhere close to a "real" Python developer experience. Python has an enormous standard library and Transcrypt implements almost none of it. The standard library is core to what makes Python Python. If I can't use any of the built-in functions that I know and love, I don't think it's really fair to claim I'm using Python except in a very superficial way.
I think the disappointment is that I was excited to have an alternative to Google Cloud Functions and AWS Lambda (which both more or less support Python "for real"). This feels more like 20% support in my opinion.
But, what I find really interesting is, we are finding it a lot easier to transpile other "managed" languages to JavaScript than to target WebAssembly. Building Python to Wasm hasn't worked well so far because the code footprint is quite large, and brings with it a whole language runtime including interpreter, garbage collector, API glue, etc. Whereas if we transpile to JS, we get V8's built-in GC, and it's much easier to call into existing high-level JS APIs. The result is nice, low code footprint, which can be distributed to thousands of edge nodes at low cost and can start up very quickly.
Both transpiling and Wasm approaches come with challenges when you want to support native-code extensions: the corresponding native library itself needs to be ported to Wasm. (Once it has, then it can be called by Wasm code or JS code, so it seems like whether or not the rest of the app is Wasm or transpiled is not critical.)
There are plans to extend Wasm to support built-in GC. Maybe then Wasm will make sense for managed languages. But, right now we're seeing Wasm is best-suited to C/C++/Rust, while transpiling is a better way to support most other languages.
(I'm the tech lead for Workers, though I wasn't directly involved in this specific project.)