Nice thing about pain-free FFI is that you can move functionality between the scripting-layer and engine-layer as you see fit. Start in JS, perhaps move pieces down to compiled-lang as they solidify or perf becomes an issue. Maybe only the high-level logic is JS. Or maybe you have JS as "plugin" extension points. Or one could design a domain-specialized "framework", and use JS as the embedding language for an embedded DSL. Acheivable performance would depend a lot on such architectural decisions.

With C++ one would unfortunately have to create C-wrappers, but with say something with easier C interop like Nim or Rust.

1kb RAM and 25k of flash is impressively low for Javascript engines for embedded system. I know it is still heavy for MCUs. Other JS engine implementations like Ducktape [1] and Jerryscript [2] takes more than 10kb of RAM and 150 of FLASH. Javascript is simply much heavier you might think. But I personally don't see any benefits neither.

[1] http://duktape.org/

[2] http://jerryscript.net/

Ideally none of the flash space is spent on a parser/compiler, that's quite wasteful if you could compile bytecode offline.

I don't know if you can do that with mJS, alas.

If you want to support eval, then the whole parser/compiler needs to be on the device.

But do you really need eval?

mJS appears to include the parser and compiler, as it seems capable of running code dynamically.

Will it run it in real time is the important thing.

I'd wager a large amount of that is handling symbol lookup for calling through the FFI.

I quote the mJS readme from the repo:

> In order to make FFI work, mJS must be able to get the address of a C function by its name. On POSIX systems, dlsym() API can do that. On Windows, GetProcAddress(). On embedded systems, a system resolver should be either manually written, or be implemented with some aid from a firmware linker script.

So I guess they don't provide any implementation for their FFI linking on embedded platforms? It's not clear if the 25k size figure includes any dlsym support, but if it requires instrumenting your firmware image on-disk then the size costs could balloon significantly.

Currently we use mJS in our Mongoose OS firmware framework. There, a symbol resolver is generated automatically from the configuration file which tells which symbols you'd like to use.

https://github.com/cesanta/mongoose-os/blob/master/fw/exampl...