I think this is probably the most ideal behaviour. It may require changes to how the print function is implemented though, as wasm-bindgen captures stdout.

This also raises the question to whether we want wasm support integrated directly into RustPython or as a bolt-on.

Personally, the former certainly seems more straightforward to me in terms of implementation.

IMHO wasm support is a nice selling point for RustPython. If we support running on the web from the beginning, it will be a nice differentiation from exiting Python implementation. Otherwise we need to compete with cpython for performance and stability, or it will remain as a toy project forever.

I'm also thinking about exposing the REPL to JS, so we can implement a web page in which a textarea (or canvas?) can work as a REPL terminal. But I'm not super sure how that API will look like.

This would certainly make for a very cool demonstration! I had originally stripped our native REPL out of the wasm demo because of build problems with the rustyline crate.

It is also worth noting that following something like:
https://github.com/pybee/batavia

It might be useful to make a shippable version of RustPython that was only the VM in order to reduce the bootstrap size and make it a somewhat more viable option to end users. This would require us to produce serialised bytecode, and potentially refactor the dependencies on the parser however @windelbouwman seemed to indicate that this should not be a particularly difficult undertaking.

Interesting! Batavia actually compile the bytcode on the server side and send it back to the JS-based VM for execution. Might be an interesting alternative to play with.

For mapping print to console.log, I need a a custom version of print in [vm/src/builtins.rs](https://github.com/RustPython/RustPython/blob/master/vm/src/builtins.rs). What would be the best method to reuse most of the builtins.rsbut allow overwriting thebuiltin_print` function?

For demo purpose we are rendering directly to DOM. This issue is a subset of #210 and we need further discussion about the API design. So let's move the discussion into #210