What is the difference between this repo and the official javascript port?

[rafi16jan]

What is the difference between this repo and the official javascript port?

https://github.com/micropython/micropython/tree/master/ports/javascript

[pmp-p]

Hi though i did not check in depth the official port, probably those differences :

• use a wasm shared library, core can be dlopen and used from another program. geared toward full baremetal wasm port (long term).
• provides a static library that you can embed into other programs via libmicropython.a
• has FFI support for dynamic C/C++ modules. ( yeah you read it right, C++ with class and fancy )
• can open local and remotes files.
• can import externals py/.mpy files and also compile py -> .mpy without a host.
• has an automatic asyncio default loop browser controlled via requestAnimationFrame (no need for user to know JS to start it).
• does not use node.js for anything.
• has an history list about emscripten support code bits and threads about problems encountered.
• provides support to use micropython as a brython replacement via script tags, to execute remote scripts, still while connecting repl to a terminal.
• can be used with lv_micropython a fork that has special bindings to LittlevGL graphic toolkit see https://littlevgl.com/live-demo.
• can acces dom and canvas see https://pmp-p.github.io/micropython-next/dom-rw.html

Things that could run better.

• does not crash browser on input() but input() return '' most of the time.
• EMTERPRETER builds, you can have sleep() functions working if you need to. like on npm port from @rafi16jan. : problem is that running could be a lot slower.

WIP not pushed yet:

• has builtin support for uasyncio native loop via requestAnimationFrame() (done)
• support for multiple PTS ( multiple terminals connected to same micropython instance )
• has builtin support for sockets.
• is ready to accept full DOM/WebGL/Canvas2D (done) access and will most likely support the great LittleVGL library https://littlevgl.com/ (done)

Future:

• async repl.
• f-strings support, including the new https://docs.python.org/3.8/whatsnew/3.8.html#f-strings-now-support-for-quick-and-easy-debugging

[rafi16jan]

Ok, that is very nice. Just curious, why are you using requestAnimationFrame for async instead of setTimeout or setInterval?

And maybe in the meantime I will make a benchmarks between RapydScript, MicroPython official javascript port, and your port. Currently I'm developing an ephemeral Python in a browser/node framework using RapydScript but I'm open to new possibilities.

[pmp-p]

i updated the list a bit and referenced that informative issue in the readme.
@rafi16jan , web is all about visual interaction with user and requestAnimationFrame as called there is expected to be called and sync with specific refresh rate ( mobile / 50-60Hz desktop classic, (free/g)-sync etc ) the user is facing. Trying to emulate that behavior would be huge task if not impossible.
also it's a emscripten provided facility for running async programs.