mJS – A new approach to embedded scripting

25k of flash space sounds like a lot for what is effectively just a JavaScript parser and interpreter. I recall the days when you could fit a whole language&#x27;s compiler into a few measly KB. 1KB RAM is also quite a lot for certain boards, especially if it has to be stack or SRAM.<p>How&#x27;s the performance? Will my 72MHz Cortex or 16MHz Arduino be able to run interesting things with mJS? If I have to do everything through FFI, what&#x27;s the benefit vs. e.g. C++11? The latter has nice language features too but compiles to much smaller native code!

That FFI interface looks <i>way</i> nicer than the node-ffi interface.<p><pre><code> let f = ffi(&#x27;int gpio_write(int, int)&#x27;); </code></pre> vs.<p><pre><code> var current = ffi.Library(null, { &#x27;atoi&#x27;: [ &#x27;int&#x27;, [ &#x27;string&#x27; ] ] });</code></pre>

This looks a lot like Lua&#x27;s FFI interface[0], which is a compliment (but contradicts the statement that this sort of FFI is &quot;the feature that no other engine implemented so far&quot;). Nicely done.<p>[0] <a href="http:&#x2F;&#x2F;csl.sublevel3.org&#x2F;post&#x2F;luajit-cpp&#x2F;" rel="nofollow">http:&#x2F;&#x2F;csl.sublevel3.org&#x2F;post&#x2F;luajit-cpp&#x2F;</a>

Is this a re-packaged v7 [0] (it&#x27;s from Cesanta as well)? mjs.c is 477K. It looks like it as v7.c is 475K [1]. It shaves whole entire 1MB from my staticly linked builds (v7 1.9MB vs. mjs 998K), and almost 2MB from dynamically linked builds (v7 1.9MB vs. mjs 99K) on amd64. If it shares the same underlying architecture and api [2] then this is a pretty great achievement.<p>In their docs, they claim 25K storage and 10K RAM. Blog post claims 25K storage and 1K RAM.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;cesanta&#x2F;mjs&#x2F;blob&#x2F;master&#x2F;mjs.c" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cesanta&#x2F;mjs&#x2F;blob&#x2F;master&#x2F;mjs.c</a><p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;cesanta&#x2F;v7&#x2F;blob&#x2F;master&#x2F;v7.c" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cesanta&#x2F;v7&#x2F;blob&#x2F;master&#x2F;v7.c</a><p>[2] <a href="https:&#x2F;&#x2F;docs.cesanta.com&#x2F;v7&#x2F;master&#x2F;#&#x2F;v7-internals&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.cesanta.com&#x2F;v7&#x2F;master&#x2F;#&#x2F;v7-internals&#x2F;</a>

I&#x27;ve never worked with embedded systems, so forgive my ignorance. Why is this any more useful than just writing c code, if all the code that actually interacts with the hardware has to be written in c anyway?

&gt; One common thing these projects share is an attempt to implement the whole language specification, together with the more or less complete standard library<p>Not in the case of Lua. Well, the &quot;whole language&quot; part is correct, but Lua is a very tiny language spec. It&#x27;s &quot;standard library&quot;, however, is the opposite of &quot;complete&quot;.

So is the only benefit of wasting that space and CPU so you can bill your platform&#x2F;project&#x2F;whatever as being &quot;js&quot; and C&#x2F;C++-free? What does a no standard library JS buy you over a no standard library C++11 everyone else is using these days, besides the pain and trouble of dealing with a dynamically typed language without native debugging support?<p>Why is there so much stigma against _learning_ to code in something other than $favlang these days? Most hard core developers I know appreciate the importance of using the right tool for the job, I don&#x27;t see embedded&#x2F;desktop developers shying away from using whatever the native toolkit&#x2F;language is for their chosen platform and instead shoehorning $x to fit as much as we see this constant trend to try to use &quot;web tech&quot; everywhere. (Scripting in embedded systems has long been a solved problem: use lua.)

Neat. Although languages which are &quot;almost, but not quite &lt;x&gt;&quot; are, I would say, harder for people who know &lt;x&gt; to learn than languages that are entirely different from &lt;x&gt;.

As light weight, easily embeddable JS engines go, I&#x27;d like to mention Duktape[0]. But the FFI of mJS does look quite a bit nicer.

Taking this example:<p><pre><code> let malloc = ffi(&#x27;void *malloc(int)&#x27;); let mem = malloc(10); </code></pre> How do you manipulate that memory?<p>How can you do the following in mJS?<p><pre><code> int* mem = malloc(10); mem[0] = 3; mem[1] = 7; mem[2] = 12; int *rest = mem + 3; </code></pre> There are some things you can do in C without functions. How does mJS achieve this?

This is neat. This isnt quite javascript (which is neither good nor bad) but I think has a lot of potential

Espruino&#x27;s had an FFI interface for the last 3 years! Nice to see they did their research :)

Worth mentioning: <a href="https:&#x2F;&#x2F;github.com&#x2F;elua" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;elua</a><p>Allows to run Lua on bare metal, no OS involved. It&#x27;s what the nodemcu firmware for the ESP cards is based on.

Seems a little crazy that there&#x27;s no support for closures.