Inconsistent JS–Python FFI behavior between Pyodide and MicroPython runtimes

Recommended Runtime for Integration Tests

Pyodide should be chosen as the default runtime for integration tests involving the JavaScript–Python Foreign Function Interface (FFI). Because Pyodide provides a more mature and comprehensive js module with robust proxying of JavaScript objects, it offers the highest reliability for confirming that Python code can interact with JS stubs without runtime-specific failures.

Likely Cause of Inconsistency

The inconsistency stems from the differing architectural goals of the two runtimes. Pyodide is designed as a full Python distribution for the browser, whereas MicroPython is optimized for a minimal footprint. This results in two primary discrepancies:

• Proxying depth: Pyodide creates rich proxies for JS objects, allowing Python to call methods and access properties naturally. MicroPython's FFI is more lightweight and may treat complex JS objects as simpler types or require more explicit handling.
• Async handling: Pyodide's integration with JS Promises is deeply integrated into its FFI layer. MicroPython's asynchronous implementation may not map 1:1 to the JS event loop, potentially causing mocks to resolve inconsistently.

Configuration for FFI Parity

To achieve consistent behavior across both runtimes, avoid direct reliance on the js module's implicit behavior. Instead, implement a thin compatibility wrapper:

1. Abstract the import: Create a utility function to handle the js module import, as the availability and behavior of the global scope can vary between runtimes.
2. Normalize type conversions: Explicitly cast or validate the return types of JS stub functions. Do not assume a JS object will behave as a Python dictionary or class instance under MicroPython.
3. Synchronize startup: Ensure the JavaScript stub module is fully loaded in the browser global scope before the Python runtime initializes, to prevent race conditions caused by MicroPython's faster startup latency.

Verification Snippet

Detect the active runtime inside your test suite so conditional logic can be applied where parity cannot be reached through abstraction:

import sys
runtime = "pyodide" if "pyodide" in sys.modules else "micropython"
print(f"Testing FFI on: {runtime}")

Run the same test suite twice, once with the PyScript configuration set to the Pyodide runtime and once with MicroPython, and compare the FFI output. Note that FFI capabilities are coupled to the underlying WebAssembly build, so record the exact runtime versions used in each pass.

Missing Diagnostic Detail

To give a more specific configuration for the asynchronous mocks, clarify whether the Python side uses asyncio to await JS Promises or whether it relies on JS-side callbacks, since the parity strategy differs between those two patterns.