[codermike]

Yes, you make a good point. A decent chunk of the size of an engine like mJS or Elk (or XS) is the parser or bytecode compiler (XS and mJS use a bytecode compiler like Microvium but the compiler is designed to run on-device and so contributes to the ROM size by default). Microvium in some sense "cheats" by not having this built into the runtime engine.

From a purely practical standpoint though, how much does that matter? If you want to run JavaScript on a microcontroller and mJS works for your situation, then maybe Microvium will also work for your situation but will do it with less RAM and ROM overhead and more language features. The practical difference is that the build or release or deployment process for your scripts now includes an extra step. Whether you can afford that extra step depends on your situation.

From a philosophical perspective, it’s an interesting question. A Microvium app actually starts running at “compile-time” and a snapshot of the running VM state is downloaded to the target MCU to continue executing where it left off. From the perspective of the running app process, Microvium does support the `import` of JavaScript source text modules (and therefore also parsing), but it just loses that capability when the VM is moved from the compile-time host to the runtime host. So, the small runtime engine doesn’t support it, but Microvium as a whole does support it. I guess this goes back to the practical question of whether your particular application needs `eval` or dynamic `import` at runtime (post-snapshot).

You also brought up the handling of edge cases, which is a good point. No engine has 100% ECMAScript compliance, so it’s a matter of degree of nonconformity, but engines like Elk, mJS and Microvium are particularly far from compliant. Originally I didn’t call Microvium a JS engine (I called it an engine for JS-like scripts, or something like that) but I changed when I saw how other engines with similar capabilities and restrictions are calling themselves JS engines.