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.
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....
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.
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.
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.
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.
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.
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.
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.
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.
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/...
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.
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).
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.
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
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!
