@sampottinger these are great goals! My immediate thought when I saw the reference was “Why is the API so different?”
I’ve wound re-implementing py5’s API twice, more or less. The Raspberry Pi Foundation did too, so I think there’s something to it. Here are my projects:
- ipycc is a wrapper around ipycanvas. I made it for my K–12 math and data science students. It’s nice being able to point them to a JupyterLite notebook to start sketching/visualizing.
- proceso is my first attempt to bridge PyScript and p5.js. A design goal is to make the package work seamlessly with both Pyodide (ecosystem) and MicroPython (efficiency).
The MicroPython option excites me because it requires less data transfer and is generally faster than Pyodide. Those features combine for a better user experience, especially in a classroom full of modest Chromebooks. They also wind up being more carbon efficient, which matters to me. MicroPython just fixed a memory bug that should enable the new implementation I’m testing.
At a very high level, what do people think about coordinating a bit on API design? No need for something like POSIX, but it’d be nice to smooth out learning curves and make sketches (mostly) interoperable.