
XS7 – A compact JavaScript engine for embedded applications - mpweiher
http://www.moddable.com/XS7-TC-39
======
moltensyntax
Tessel ([https://tessel.io/](https://tessel.io/)) also runs JavaScript on
embedded. It cleverly used Lua as an intermediate language.

~~~
CharlesW
That makes it sound they're running Lua on embedded. In that case, is the JS-
to-Lua transpiling done on-device as well?

------
ricardobeat
Any benchmarks available? Would love to know how it compares to Duktape
([http://duktape.org/](http://duktape.org/)).

~~~
lprader
We can run our helloworld sample ([https://github.com/Moddable-
OpenSource/moddable/tree/public/...](https://github.com/Moddable-
OpenSource/moddable/tree/public/examples/helloworld)) with the xsbug debugger
attached in 6000 bytes of RAM on the ESP8266. 5456 bytes for the stack and
heaps, 256 for the dynamic symbol table, and 288 for the alias array.

With the 26KB RAM Duktape needs for "Hello world" we can run apps like the
Sensor hub described in this blog post (run on a Thunderboard that only has
32KB of RAM total): [http://blog.moddable.tech/blog/moddable-tech-
presentation-to...](http://blog.moddable.tech/blog/moddable-tech-presentation-
to-tc-39/)

~~~
svaarala
By default Duktape maintains the built-in objects purely in RAM, but for low
footprint targets the built-in objects (and also custom user objects) can be
made pure ROM objects which reduces memory usage quite a bit; the lowest
startup RAM usage is around 1,5kB, see
[https://github.com/svaarala/duktape/blob/master/doc/low-
memo...](https://github.com/svaarala/duktape/blob/master/doc/low-memory.rst).

------
ithkuil
Similar projects
[https://github.com/cesanta/v7](https://github.com/cesanta/v7) And
[https://github.com/cesanta/mjs](https://github.com/cesanta/mjs)

------
positivecomment
This is very cool. I hope one day someone creates a basic DOM for this with
good CSS support and then we'd have the mini-electron. I hope that a very
limited subset of the features of a browser (no downloads, tabs, networking,
security contexts and everything else which would be irrelevant for desktop
apps) can be implemented with few orders of magnitude less lines of code.

~~~
c-smile
In fact I am looking on something like XS7 for my Sciter
([https://sciter.com](https://sciter.com)) to provide ability to run <script
type=text/javascript>.

Sciter is an implementation of HTML(~5)/CSS(~3) and DOM/layout/rendering. As
for now it has its own JS alike script and VM and is contained in single DLL <
5mb all together.

So "yes", mini-electron is feasible and exists already I would say.

~~~
maxpert
Have you considered opening up the source code for Sciter? You can easily get
a significant amount of apps just due to the size and still maintain "paid and
supported" version.

~~~
c-smile
I am considering that too. The only thing that is worrying me is that it may
take quite a lot of time/effort to publish it.

Yet, I am not that good in "legaleze" language, GPL vs BSD vs paid options,
etc.

~~~
vijaybritto
Pls seek help and capitalise on the current situation in desktop apps. We need
low memory consuming apps seriously

------
yazr
this + light-weight OSS browser = mini-electron ?!

Any technical barriers to this ?

~~~
mort96
Well, implementing all of HTML and CSS and the DOM in something light-weight
might be difficult.

~~~
Can_Not
Perhaps something like bindings for QT or GTK would be preferred.

~~~
carussell
GTK already has JS bindings. If you're running Gnome, then substantial parts
of what you're seeing and interacting with on your desktop is JS.

The Gnome folks tried anointing JS as the de jure development language across
the Gnome project (i.e., for apps, too) a few years back, but there was a
minor backlash. Unfortunately, Electron came along within the next year or so
has since snagged most of the mindshare that was up for grabs after they
backpeddled a bit. You can write JS apps, but it's not a prominent park of the
environment outside of Gnome Shell and extensions, AFAIK. The documentation is
pretty lacking.

GJS is SpiderMonkey under the hood—the same JS engine used in Firefox. It
would be interesting to see if XS were an improvement for Gnome. Web browsers
are subject to constraints that aren't necessarily a relevant factor for
static packages downloaded from your distro vendor. For example, it looks like
XS/Kinoma/Moddable supports AOT compilation, which could be a win.

Metrics here look like they focus on RAM and not on speed of computation.

On the softer side, GTK folks do favor C, and the explicit endorsement of
(L)GPLv3 is worth brownie points in that circle. (SpiderMonkey is written in
C++, and MPL2 is compatible with (L)GPL, but its copyleft is weaker and allows
more permissive use.)

In any case, this project is really neat. I only wish I'd heard about it back
in 2015.

~~~
Can_Not
What was the backlash specifically?

~~~
carussell
Specifically? I don't think there were specifics. Just the familiar general
anti-JS sentiment.

I spent a few seconds looking through my feed of past Planet Gnome posts. It
looks like the first announcement was here in 2013:

[http://treitter.livejournal.com/14871.html](http://treitter.livejournal.com/14871.html)

You can get a taste from the comments there. Here's some meta-commentary:

[https://www.reddit.com/r/javascript/comments/17w0z5/javascri...](https://www.reddit.com/r/javascript/comments/17w0z5/javascript_to_become_primary_language_for/)

IIRC, it didn't really let up. I don't have a reference, but I vaguely recall
something that, if not an official recantation, was akin to the general
sentiment of backpeddling from the original stance, although I may be
misremembering. In any case, the forthcoming concerted effort to go all-in on
JS-for-Gnome didn't really happen as that post suggests it would.

A couple months after the fomentatious announcement linked above, GitHub
quietly started work on Atom Shell and then a year later released Atom and
Electron under MIT. What a massive lost opportunity for the Gnome folks to
take advantage of the lead they'd set up for themselves instead of bowing to
the vocal pressure! Had that not been the case, GTK+JS might've been the go-to
framework for rapid cross-platform desktop app development in the instances
where people are reaching for Electron today. (And that recurring plea for
more "native" UIs would never be heard—or at the very least there'd be a
straightforward path to migrate codebases to native in a piecemeal fashion if
there was any motivation to do so.)

------
nerpderp83
JavaScriptCore is already running on WASM,
[https://github.com/mbbill/JSC.js](https://github.com/mbbill/JSC.js) so all
you need is a WASM execution context and you get a great ECMAScript engine.

------
CharlesW
XS6's ECMAScript 6 compatibility: 95%[1]

[1] [https://kangax.github.io/compat-
table/es6/#xs6](https://kangax.github.io/compat-table/es6/#xs6)

~~~
phoddie
Better than that, XS today achieves over 99% compatibility on test262, the
official JavaScript language test suite, for ECMAScript 2017 (the latest
versin of the JavaScript language). That's over 50,000 tests. Details on the
test results in our GitHub repository @ [https://github.com/Moddable-
OpenSource/moddable/blob/public/...](https://github.com/Moddable-
OpenSource/moddable/blob/public/documentation/xs/XS%20Conformance.md#results)

~~~
CharlesW
Cool, congratulations!

------
marktangotango
Can I create a secure sandbox? Users only have access to functions and objects
i whitelist, I can set max allowed heap, limit stack, and limit number of
opcodes (or whatever) executed?

~~~
lprader
Yes, absolutely. XS just provides the basic built-in JavaScript objects (Date,
RegExp, String, Number, etc.). Everything else is up to you (meaning the
person who creates the virtual machine). And memory allocation can be static
or dynamic, so you can control how much memory is available.

In case you're interested, here's the doc that describes the C interface to
the runtime of the XS JavaScript engine: [https://github.com/Moddable-
OpenSource/moddable/blob/public/...](https://github.com/Moddable-
OpenSource/moddable/blob/public/documentation/xs/XS%20in%20C.md)

~~~
marktangotango
I didn’t see anything in that doc about limiting instructions executed, or
throwing an error if some limit is reached. Did you mean to say that
capability is included? Can you share a specific reference?

~~~
phoddie
We don't have a document that answers your question directly but the
capabilities are all there. We're happy to help you get started - post an
issue on our repository on GitHub. The "XS in C" describes the API you'll use
from your C/C++ code to interact with XS (created a VM, implement native
functions callable from JavaScript, etc). Most of the limits can be set using
the manifest, which defines the virtual machine build. For example, to limit
the memory used by a script or the modules available to a script (e.g. what
classes and functions it can call), use the manifest's "creation" object which
indicates the maximum number of bytes the VM can allocate. Here's the base
manifest all our examples include, which define the VM size in the creation as
32 KB - [https://github.com/Moddable-
OpenSource/moddable/blob/public/...](https://github.com/Moddable-
OpenSource/moddable/blob/public/examples/manifest_base.json). The manifest
also lists all the modules that are built into the virtual machine. These are
the only modules a script can use (unless you add a module that can load other
modules!). For example, manifest_net.json ([https://github.com/Moddable-
OpenSource/moddable/blob/public/...](https://github.com/Moddable-
OpenSource/moddable/blob/public/examples/manifest_net.json)) includes a bunch
of modules related to networking (socket, sntp, wifi).

------
drzaiusx11
how does this compare to espruino (which can run on 64kB RAM)?

[http://www.espruino.com/](http://www.espruino.com/)

~~~
lprader
A few things:

\- XS7 can run in as little as 32K RAM :)

\- Espruino follows the ES5 standard (released in 2009), whereas XS7 follows
the ECMAScript 2017 standard.

\- The Espruino debugger is more like gdb, the XS7 debugger has a GUI.

We have a couple of posts on our website with more information about XS7:
[http://blog.moddable.tech/blog/moddable-tech-presentation-
to...](http://blog.moddable.tech/blog/moddable-tech-presentation-to-tc-39/)
[http://www.moddable.com/XS7-TC-39](http://www.moddable.com/XS7-TC-39)

------
megous
Is there some documentation on how to run code from a string in C. I guess I
can setup a getter for a buffer and then call fxParseScript? Is that all?

~~~
phoddie
FWIW - we usually don't parse scripts on the MCU because that takes time and
memory. Instead, we compile on the development machine using xsc and link
using xsl. This leaves more memory free for scripts to use for data, and
allows scripts to start running almost instantly.

~~~
megous
I understand, though I meant to use xs engine separately on bigger platforms,
where this is not an issue.

------
olouv
Is there a tutorial somewhere to get started with an ESP32? Is it a supported
platform?

~~~
phoddie
Instructions for building XS for ESP32 are in our GitHub repository. There are
separate sections for building on macOS, Windows, and Linux.
[https://github.com/Moddable-
OpenSource/moddable/blob/public/...](https://github.com/Moddable-
OpenSource/moddable/blob/public/documentation/Moddable%20SDK%20–%20Getting%20Started.md#esp32-setup)

------
abritinthebay
Are there any micro-controller style boards that run this (for example -
something espruino-like)?

Would be very interesting to play with in that context.

~~~
phoddie
Any NodeMCU compatible ESP8266 board should work. Moddable Zero starts with a
NodeMCU board and adds a color touch screen for $20 (and they are handmade to
order in California). [http://www.moddable.com/moddable-
zero.php](http://www.moddable.com/moddable-zero.php)

~~~
abritinthebay
I saw that _just_ before you posted. Ordered one! Excited to try it out.

