reflex-dev
Suggestion: Pyodide usage in rendering pipeline
Hello, it may be worth considering shifting the focus from server-side state mutation to client-side rendering.
The current use of web sockets for state management can result in slow performance, so it may be a more secure and efficient solution to handle state changes locally using a tool like Pyodide (https://github.com/pyodide/pyodide).
This way, all state mutating events can be processed within a WebAssembly virtual machine.
I tried pyodide and it was really slow to load and limited in the packages you can use. Did you have a good experience with it?
We do want to use some sort of wasm in the future but the current python solutions seems premature.
To clarify, for client-side rendering, you do not necessarily need a large number of packages or even any packages at all. State event handling can be handled using JavaScript, and the processing can be forwarded to the Pyodide instance.
However, one potential issue with using Pyodide is that its bundle size can make the initial download and load time slow, its still being worked on over and over https://github.com/pyodide/pyodide/labels/size%20%26%20load%20time%20optimization.
However, since it does not rely on HTTP requests, it can still provide a faster pipeline compared to using WebSockets in the context you mentioned.
Have you benchmarked it? In my option use WASM package for client side rendering will lead to longer white screen time and bad user experience, the package is too big for frontend assets.
I've not saw benchmark like that because it's not very common and it's very original to use Python like that but I can understand your point, maybe when the version of CPython for WASM (on browser) will be fully released it would be more interesting https://github.com/python/cpython/tree/main/Tools/wasm
There is no path to providing this functionality in the current roadmap for reflex.
- too slow
- client-side code unable to interact with the backend
