Duktape is an embeddable JavaScript engine, with a focus on portability
duktape.org
duktape.org
Moddable is the only embedded engine provider in the Ecma TC39 JavaScript language committee, so they tend to be really aggressive in supporting new JavaScript features.
Their commercial license is 25¢/unit (no minimum), and their FOSS license is LGPL for the runtime, GPL for the development tools, and Creative Commons for their example code.
For anyone interested in XS specifically or embedded software licensing in general, they do a good job of explaining their rationale here: https://www.moddable.com/license
moddable is GPL and LGPL.
https://github.com/mozilla-spidermonkey/spidermonkey-embeddi...
The big issue (like with v8) is binary size. Double-digit megabytes before you even start running code is unacceptable in a lot of environments.
Duktape supports some ES6 features (26% according to kangex for version 2.4). I'd note that Duktape also supports proper tail calls which v8 and spidermonkey refuse to support (JSC in Safari does though). Support for typed arrays is nice (especially when interacting with C).
If you have room for a larger binary, QuickJS and XS are both faster and both have support for newer specs.
Sure, but in my use case this would have completely negated the desired benefits (code sharing between web + native) I was aiming for in the first place.
YMMV, often times a factor 100 performance degradation is perfectly acceptable, sometimes it’s not. Just wanted to let folks know.
What are the reasons given for not supporting tail calls?
A big complaint was "no stack traces". This doesn't matter (IMO) because shadow stacks have been prove to work well in Safari and in several Scheme implementations (you seldom need more than the first few stacks and the last few stacks with a rolling window). We've had way worse than that for decades now as you lose your whole stack every time the event loop goes to the next event. Safari has about 30% of the total JS marketshare including mobile. They've been running PTC on websites for a couple years without complaints, so the whole "we'll break the web" concerns seem overblown.
My understanding of the politics is that both the Safari and spidermonkey/v8 members on the consortium refuse to budge so there isn't consensus to move forward. This still seems a non-issue to me though. If you view PTC as an optional enhancement, then you could still add a non-optional syntactic PTC variant.
In all somewhat recent V8 using engines such as Chrome or node.js you get a "zero-cost" full asynchronous stacktrace these days. That's independent of the async. stacktrace provided through the dev.tools for a long time and "always on" for free.
The condition: You must use async/await. Even if you return a promise from a function, for that function to be included in the stacktrace is that you "return await thePromise;". Because of the await the context of the function calling an asynchronous function remains available and can be (and now is) used to create the stacktrace.
The Firefox JS engine does not have that feature (yet?) last time I checked.
Part of the issue is I needed a scripting engine, but I didn’t NEED JS. It was also a pain that the code/script was in ASCII which had to go to base64 and none of this was as good as compiled for efficiency.
I wasn’t going to let users run their own code, so that’s probably a big reason people use this.
Tcl's philosophy is to keep the core lean and extend functionality via loadable libraries.
EDIT: Not too bad actually. I'll take a look and compare to Lua. I'm not ::crazy::about:TCL's syntax, but it's not that bad.
I'm surprised with v8 though. I assumed they'd have a separate binary available so you could run jitless without having to carry all the binary bloat.
That said, it seems like there are serious code savings to be had with some things like destructuring, template strings, and arrow functions. Generators are probably complex to add, but also don't transpile well (that is, debugging the resulting code is a horrible experience).