5 ms·

moddablexs and quickjs are probably better at this point, with current spec compatibility and whatnot. still a lot of respect for duktape though, it is not that

by snek 7y ago

moddablexs and quickjs are probably better at this point, with current spec compatibility and whatnot. still a lot of respect for duktape though, it is not that bad to embed.

juancampa 7y ago
QuickJS has a relevant comparison/benchmark: https://bellard.org/quickjs/bench.html https://bellard.org/quickjs/bench.html
- hajile 7y ago
  600kb or 1.2mb are way larger than 330kb and makes them much less suitable for smaller embedded applications which Duktape seems to target (it can get way smaller than 330kb). 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.
  - zamadatix 7y ago
    Another thing to consider (and probably part of the size difference) is QuickJS carries with it about 5 years newer JS standards support than Duktape.
    - hajile 7y ago
      I suspect these two things are related. ES2015 more than doubled the size of the spec and each spec since then has continued adding loads of things that take precious kb to implement. 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).
vortico 7y ago
We switched from Duktape to QuickJS for https://vcvrack.com/Prototype https://vcvrack.com/Prototype, where performance on x86_64 is a huge concern. Both are incredibly easy to embed compared to most other scripting language interpreters, but QuickJS required us to fork the project and hack 3-4 features/fixes into its codebase, but after that, it was a drop-in replacement. In our use case, QuickJS was ~2x faster than Duktape for lots of math. We still keep the Duktape implementation up-to-date but disabled as a reference for new script engines, since its API is the easiest to read.

by snek 7y ago

moddablexs and quickjs are probably better at this point, with current spec compatibility and whatnot. still a lot of respect for duktape though, it is not that bad to embed.

juancampa 7y ago

QuickJS has a relevant comparison/benchmark: https://bellard.org/quickjs/bench.html https://bellard.org/quickjs/bench.html

hajile 7y ago
600kb or 1.2mb are way larger than 330kb and makes them much less suitable for smaller embedded applications which Duktape seems to target (it can get way smaller than 330kb). 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.
- zamadatix 7y ago
  Another thing to consider (and probably part of the size difference) is QuickJS carries with it about 5 years newer JS standards support than Duktape.
  - hajile 7y ago
    I suspect these two things are related. ES2015 more than doubled the size of the spec and each spec since then has continued adding loads of things that take precious kb to implement. 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).

vortico 7y ago

We switched from Duktape to QuickJS for https://vcvrack.com/Prototype https://vcvrack.com/Prototype, where performance on x86_64 is a huge concern. Both are incredibly easy to embed compared to most other scripting language interpreters, but QuickJS required us to fork the project and hack 3-4 features/fixes into its codebase, but after that, it was a drop-in replacement. In our use case, QuickJS was ~2x faster than Duktape for lots of math. We still keep the Duktape implementation up-to-date but disabled as a reference for new script engines, since its API is the easiest to read.