XS7 – A compact JavaScript engine for embedded applications(moddable.com)
moddable.com
XS7 – A compact JavaScript engine for embedded applications
http://www.moddable.com/XS7-TC-39
51 comments
Tessel (https://tessel.io/) also runs JavaScript on embedded. It cleverly used Lua as an intermediate language.
That makes it sound they're running Lua on embedded. In that case, is the JS-to-Lua transpiling done on-device as well?
Any benchmarks available? Would love to know how it compares to Duktape (http://duktape.org/).
We can run our helloworld sample (https://github.com/Moddable-OpenSource/moddable/tree/public/...) 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...
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...
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....
I though many of the options in duktape could be turned off to reduce the memory footprint.
Similar projects
https://github.com/cesanta/v7
And https://github.com/cesanta/mjs
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.
In fact I am looking on something like XS7 for my Sciter (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.
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.
Sciter is awesome.
I found it too hard to start writing something with TIScript, maybe if there was some step-by-step tutorial it could be easier.
> So "yes", mini-electron is feasible and exists already I would say.
I believe you could became big player in "web to desktop" market if only sciter had JS & DOM support. That would give you access to existing code and make sciter almost drop in replacement for nw.js or electron.
//edit: formatting mistake
I found it too hard to start writing something with TIScript, maybe if there was some step-by-step tutorial it could be easier.
> So "yes", mini-electron is feasible and exists already I would say.
I believe you could became big player in "web to desktop" market if only sciter had JS & DOM support. That would give you access to existing code and make sciter almost drop in replacement for nw.js or electron.
//edit: formatting mistake
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.
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.
Yet, I am not that good in "legaleze" language, GPL vs BSD vs paid options, etc.
Pls seek help and capitalise on the current situation in desktop apps. We need low memory consuming apps seriously
[deleted]
Yeah, that would be interesting. Right now the Moddable SDK comes with the Piu application framework, which has cascading styles, inspired by CSS. You can read all about that here: https://github.com/Moddable-OpenSource/moddable/blob/public/...
I'd hardly consider networking support to be irrelevant to a desktop app.
I meant in the context of the GUI, then all data would be exchanged through the native bindings.
> security contexts and everything else which would be irrelevant for desktop apps
There's a lot of web browser security features which are only relevant when the code is untrusted, when assets are fetched over http/https instead of bundled locally, etc.
GP is likely overestimating how much "bloat" could actually be dropped but your comment is uninformed.
GP is likely overestimating how much "bloat" could actually be dropped but your comment is uninformed.
ALL code is untrusted
That's... somewhat hardcore for most applications.
Also it's also not what most people mean by "untrusted". From a low level hardware standpoint though... assuming user-land code isn't trustworthy IS a good guideline.
Also it's also not what most people mean by "untrusted". From a low level hardware standpoint though... assuming user-land code isn't trustworthy IS a good guideline.
Purposefully misunderstanding what people write in an effort to be a smartass is a sure-fire way of creating security issues.
No, "ALL" code is not untrusted. There's varying degrees of trust. I'd encourage you to stop trying to win the argument through platitudes and do some research instead, but I'm not sure you're interested.
No, "ALL" code is not untrusted. There's varying degrees of trust. I'd encourage you to stop trying to win the argument through platitudes and do some research instead, but I'm not sure you're interested.
[deleted]
this + light-weight OSS browser = mini-electron ?!
Any technical barriers to this ?
Any technical barriers to this ?
Well, implementing all of HTML and CSS and the DOM in something light-weight might be difficult.
Perhaps something like bindings for QT or GTK would be preferred.
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.
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.
What was the backlash specifically?
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
You can get a taste from the comments there. Here's some meta-commentary:
https://www.reddit.com/r/javascript/comments/17w0z5/javascri...
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.)
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
You can get a taste from the comments there. Here's some meta-commentary:
https://www.reddit.com/r/javascript/comments/17w0z5/javascri...
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.)
JavaScriptCore is already running on WASM, https://github.com/mbbill/JSC.js so all you need is a WASM execution context and you get a great ECMAScript engine.
XS6's ECMAScript 6 compatibility: 95%[1]
[1] https://kangax.github.io/compat-table/es6/#xs6
[1] https://kangax.github.io/compat-table/es6/#xs6
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/...
Cool, congratulations!
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?
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/...
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/...
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?
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/.... 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/...) includes a bunch of modules related to networking (socket, sntp, wifi).
Is there a way to do that with anything else out there?
how does this compare to espruino (which can run on 64kB RAM)?
http://www.espruino.com/
http://www.espruino.com/
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://www.moddable.com/XS7-TC-39
- 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://www.moddable.com/XS7-TC-39
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?
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.
I understand, though I meant to use xs engine separately on bigger platforms, where this is not an issue.
Ah, I found some nice example in fx_agent_start_aux() function. :)
Is there a tutorial somewhere to get started with an ESP32? Is it a supported platform?
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/...
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.
Would be very interesting to play with in that context.
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
I saw that just before you posted. Ordered one! Excited to try it out.
Looks like this thing is derived from the work by Kinoma[1], who has/had a $25 micro with networking. The link to their retailer is dead, though.
1. http://kinoma.com/buy/
1. http://kinoma.com/buy/
Yeah, but Kinoma is basically dead and all their products discontinued.
It looks like there's nothing out-of-the-box but they do recommend ESP8266 based boards[1] on their site. Which is interesting as I thought that was just a wifi chip...
edit - It does look like they're producing their own board[2] as a demo/hacking platform which is pretty great!
1. https://www.amazon.com/HiLetgo-Internet-Development-Wireless...
2. http://www.moddable.com/moddable-zero.php
It looks like there's nothing out-of-the-box but they do recommend ESP8266 based boards[1] on their site. Which is interesting as I thought that was just a wifi chip...
edit - It does look like they're producing their own board[2] as a demo/hacking platform which is pretty great!
1. https://www.amazon.com/HiLetgo-Internet-Development-Wireless...
2. http://www.moddable.com/moddable-zero.php