5 ms·

Just keep in mind that performance is abysmal (order of magnitude of 1% vs what you are used to in a browser for the same amount of cpu time spent), which might

by jupp0r 7y ago

Just keep in mind that performance is abysmal (order of magnitude of 1% vs what you are used to in a browser for the same amount of cpu time spent), which might be ok for your use case, just keep in mind that many libraries assume a somewhat performant runtime. Another down point is that you are stuck with ES5.

CharlesW 7y ago
For anyone who needs a performant "JavaScript for embedded" runtime that also fully supports ECMAScript 2018, Moddable's XS is a great choice.[1] 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. [1] https://www.moddable.com/faq.php#comparison https://www.moddable.com/faq.php#comparison
- amelius 7y ago
  How difficult would it be to port Firefox's javascript engine to embedded platforms?
  - andoma 7y ago
    In my experience (having embedded both spidermonkey and duktape) is that if embedding is not a primary use case for the engine it can get messy and complicated to update (lots of api breakage etc). This was the reason I switched from spidermonkey to duktape for my app. That said, it was probably five or six years ago. Perhaps things have changed since. I guess the takeaway is just that. If the engine isn’t maintained for embedding. Don’t use it as such.
    - amelius 7y ago
      Yeah, I guess JIT compilation to native code can also be a difficult issue.
  - hajile 7y ago
    I've never tried, but Mozilla's example doesn't look that hard. https://github.com/mozilla-spidermonkey/spidermonkey-embedding-examples 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.
    - X-Istence 7y ago
      It's a giant pain in the behind, if you can even get it to compile correctly.
  - jupp0r 7y ago
    I have not tried SpiderMonkey, but embedding V8 is pretty easy.
- jupp0r 7y ago
  Moddable is GPL though, which might be problematic for some use cases.
  - paulddraper 7y ago
    ? It's MIT https://github.com/svaarala/duktape/blob/master/LICENSE.txt https://github.com/svaarala/duktape/blob/master/LICENSE.txt
    - ksherlock 7y ago
      duktape is MIT. moddable is GPL and LGPL.
    - X-Istence 7y ago
      Moddable isn't: https://github.com/Moddable-OpenSource/moddable/tree/public/licenses https://github.com/Moddable-OpenSource/moddable/tree/public/...
  - CharlesW 7y ago
    Yes, it's well worth understanding the licensing before trying it. 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 https://www.moddable.com/license
hajile 7y ago
If you're embedding, you have C/C++ right there if you need real calculation work done. 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.
- herbstein 7y ago
  > Duktape also supports proper tail calls which v8 and spidermonkey refuse to support What are the reasons given for not supporting tail calls?
  - hajile 7y ago
    v8 used to support them behind a flag. Chakra and spidermonkey teams said implementing was hard. v8 team put forward a plan to replace automatic PTC with syntactic PTC. The proposal has been essentially dead and v8 removed their PTC support completely. 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.
    - nosianu 7y ago
      Just an aside regarding stacktraces: 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.
ojosilva 7y ago
Typescript compiles perfecly to Duktape and the code is quite performant. We've used Duktape in production systems without any hickups for 2yrs+, first with Babel and now with TS. It serves us well as an intermediate migration platform for non-evented code, as part of a rewrite that can run alongside legacy code. Once the code is all in TS we will adapt it to Node's evented style.
- jupp0r 7y ago
  YMMV, we tried to use Duktape to share some code between native and web and abandoned it im favor of V8 because performance just didn’t work out. It really depends on what you are doing inside.

by jupp0r 7y ago

CharlesW 7y ago

For anyone who needs a performant "JavaScript for embedded" runtime that also fully supports ECMAScript 2018, Moddable's XS is a great choice.[1] 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. [1] https://www.moddable.com/faq.php#comparison https://www.moddable.com/faq.php#comparison

amelius 7y ago
How difficult would it be to port Firefox's javascript engine to embedded platforms?
- andoma 7y ago
  In my experience (having embedded both spidermonkey and duktape) is that if embedding is not a primary use case for the engine it can get messy and complicated to update (lots of api breakage etc). This was the reason I switched from spidermonkey to duktape for my app. That said, it was probably five or six years ago. Perhaps things have changed since. I guess the takeaway is just that. If the engine isn’t maintained for embedding. Don’t use it as such.
  - amelius 7y ago
    Yeah, I guess JIT compilation to native code can also be a difficult issue.
- hajile 7y ago
  I've never tried, but Mozilla's example doesn't look that hard. https://github.com/mozilla-spidermonkey/spidermonkey-embedding-examples 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.
  - X-Istence 7y ago
    It's a giant pain in the behind, if you can even get it to compile correctly.
- jupp0r 7y ago
  I have not tried SpiderMonkey, but embedding V8 is pretty easy.
jupp0r 7y ago
Moddable is GPL though, which might be problematic for some use cases.
- paulddraper 7y ago
  ? It's MIT https://github.com/svaarala/duktape/blob/master/LICENSE.txt https://github.com/svaarala/duktape/blob/master/LICENSE.txt
  - ksherlock 7y ago
    duktape is MIT. moddable is GPL and LGPL.
  - X-Istence 7y ago
    Moddable isn't: https://github.com/Moddable-OpenSource/moddable/tree/public/licenses https://github.com/Moddable-OpenSource/moddable/tree/public/...
- CharlesW 7y ago
  Yes, it's well worth understanding the licensing before trying it. 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 https://www.moddable.com/license

hajile 7y ago

If you're embedding, you have C/C++ right there if you need real calculation work done. 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.

herbstein 7y ago
> Duktape also supports proper tail calls which v8 and spidermonkey refuse to support What are the reasons given for not supporting tail calls?
- hajile 7y ago
  v8 used to support them behind a flag. Chakra and spidermonkey teams said implementing was hard. v8 team put forward a plan to replace automatic PTC with syntactic PTC. The proposal has been essentially dead and v8 removed their PTC support completely. 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.
  - nosianu 7y ago
    Just an aside regarding stacktraces: 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.

ojosilva 7y ago

Typescript compiles perfecly to Duktape and the code is quite performant. We've used Duktape in production systems without any hickups for 2yrs+, first with Babel and now with TS. It serves us well as an intermediate migration platform for non-evented code, as part of a rewrite that can run alongside legacy code. Once the code is all in TS we will adapt it to Node's evented style.

jupp0r 7y ago
YMMV, we tried to use Duktape to share some code between native and web and abandoned it im favor of V8 because performance just didn’t work out. It really depends on what you are doing inside.