3 ms·

Having used both QuickJS and Duktape, I have to say that QuickJS is a lot better. Mostly because it's faster and has newer language features. QuickJS has full s

Having used both QuickJS and Duktape, I have to say that QuickJS is a lot better. Mostly because it's faster and has newer language features. QuickJS has full support for ES2020, whereas Duktape is on ES2015. I guess Duktape is a little smaller, but that's the only advantage I found.

Rochus 4y ago
> Duktape is a little smaller, but that's the only advantage I found. It's not actually smaller; Duktape is about 4MB source files while QuickJS is about 2.7 MB. But Duktape has a nice C API similar to Lua. And QuickJS requires a recent C compiler whereas Duktape is happy with C89.
- deleted 4y ago
  [deleted]
- atwood22 4y ago
  For some reason I remember the compiled size for Duktape being smaller, but I could be misremembering. It's been a few years since I've used both libraries.
  - melissalobos 4y ago
    > For some reason I remember the compiled size for Duktape being smaller For any C library this is HEAVILY dependent on the compiler, compilation, and linking options used.
  - Rochus 4y ago
    Bellard has an evaluation on his website where the executable size of QuickJS is bigger than Duktape: https://bellard.org/quickjs/bench.html https://bellard.org/quickjs/bench.html. Both were compiler with gcc 4.9.2. I don't know the reason for the difference (both have large unicode tables etc.).
    - mananaysiempre 4y ago
      > large unicode tables I’ve spent quite some time recently wrangling Unicode tables, so a quick note: unless you consciously go for performance over size (e.g. the Windows SBCS code pages use a 65536-entry lookup table for encoding, each), Unicode property tables are not that large. With general category, a basic[1] set of properties, and canonical normalization, you can get away with about 30K for the whole lot without much of a problem, and probably less than that if you use a sorted inversion list instead of a trie for binary properties (both Plan 9 / libutf and Duktape do this IIRC, while QuickJS does something trickier I haven’t grokked yet, but it’s obviously not trying to be a speed demon there either). Compatibility decompositions are more problematic (so. many. ideographs), I’m still at 20K for those, and I expect default casing and case folding will cost about that much as well. Maybe you also want some other properties (breaks? bidi class? script?). So let’s say 60K at best, 90K at worst, total. Overall, a considerable but not catastrophic contribution to Duktape’s 330K (as quoted in your link) and even less of a problem for QuickJS’s 620K. And that is for tables that you can run against—if you’re willing to sacrifice runtime memory consumption for disk / wire size, you can do substantially better[2]. (These were rough estimates from experience. The actual figure for QuickJS turns out to be 37K, so I was a bit too pessimistic; I can’t compile Duktape right now, but it’s probably smaller given it can’t even normalize[3].) Character names, collation, or locales / tailoring would multiply the size severalfold, but I think none of the small engines here do any of that (although an engine that wanted ECMA-402 internationalization would need all of it and more). [1] https://www.unicode.org/reports/tr18/#RL1.2 https://www.unicode.org/reports/tr18/#RL1.2 [2] https://devlog.hexops.com/2021/unicode-data-file-compression/ https://devlog.hexops.com/2021/unicode-data-file-compression... [3] https://github.com/svaarala/duktape/issues/1718 https://github.com/svaarala/duktape/issues/1718
      - Rochus 4y ago
        That's interesting, thanks. I'm currently using the trie and properties table from https://github.com/rochus-keller/Qt-4.8.7/blob/master/src/corelib/tools/qunicodetables.cpp https://github.com/rochus-keller/Qt-4.8.7/blob/master/src/co... for a new open source project of mine; the source file is 204k and the compiler produces an 68k object file from it.
jalino23 4y ago
whats the use case of quick js compared to node?
- atwood22 4y ago
  It’s really good as an embedded JS engine. Like let’s say you want to make an iOS app that executed JS. If you use V8 (Node’s JS engine), then you’re app is at a minimum 28M in size just from V8. If you use QuickJS, your app size increases by less than 1M.
  - skybrian 4y ago
    On iOS, why wouldn't you use WebKit? (Genuine question; I'm not an iOS developer.)
    - atwood22 4y ago
      I don’t think you can create native bindings in WebKit. You can only interact with something like WKWebView using serializable messages. QuickJS let’s you create native objects and expose them directly to the JS API. QuickJS also let’s you get JS variables natively and control how and when things get executed.
      - deleted 4y ago
        [deleted]
      - saurik 4y ago
        You would use JavaScriptCore, not WebKit.
        atwood22 4y ago
        Ah yea that’s right. Now I remember why we didn’t use JSCore. We had a cross-platform C++ library for both Android and iOS so it was better to use a single JS Engine.
- 4y ago

Rochus 4y ago

> Duktape is a little smaller, but that's the only advantage I found. It's not actually smaller; Duktape is about 4MB source files while QuickJS is about 2.7 MB. But Duktape has a nice C API similar to Lua. And QuickJS requires a recent C compiler whereas Duktape is happy with C89.

deleted 4y ago
[deleted]
atwood22 4y ago
For some reason I remember the compiled size for Duktape being smaller, but I could be misremembering. It's been a few years since I've used both libraries.
- melissalobos 4y ago
  > For some reason I remember the compiled size for Duktape being smaller For any C library this is HEAVILY dependent on the compiler, compilation, and linking options used.
- Rochus 4y ago
  Bellard has an evaluation on his website where the executable size of QuickJS is bigger than Duktape: https://bellard.org/quickjs/bench.html https://bellard.org/quickjs/bench.html. Both were compiler with gcc 4.9.2. I don't know the reason for the difference (both have large unicode tables etc.).
  - mananaysiempre 4y ago
    > large unicode tables I’ve spent quite some time recently wrangling Unicode tables, so a quick note: unless you consciously go for performance over size (e.g. the Windows SBCS code pages use a 65536-entry lookup table for encoding, each), Unicode property tables are not that large. With general category, a basic[1] set of properties, and canonical normalization, you can get away with about 30K for the whole lot without much of a problem, and probably less than that if you use a sorted inversion list instead of a trie for binary properties (both Plan 9 / libutf and Duktape do this IIRC, while QuickJS does something trickier I haven’t grokked yet, but it’s obviously not trying to be a speed demon there either). Compatibility decompositions are more problematic (so. many. ideographs), I’m still at 20K for those, and I expect default casing and case folding will cost about that much as well. Maybe you also want some other properties (breaks? bidi class? script?). So let’s say 60K at best, 90K at worst, total. Overall, a considerable but not catastrophic contribution to Duktape’s 330K (as quoted in your link) and even less of a problem for QuickJS’s 620K. And that is for tables that you can run against—if you’re willing to sacrifice runtime memory consumption for disk / wire size, you can do substantially better[2]. (These were rough estimates from experience. The actual figure for QuickJS turns out to be 37K, so I was a bit too pessimistic; I can’t compile Duktape right now, but it’s probably smaller given it can’t even normalize[3].) Character names, collation, or locales / tailoring would multiply the size severalfold, but I think none of the small engines here do any of that (although an engine that wanted ECMA-402 internationalization would need all of it and more). [1] https://www.unicode.org/reports/tr18/#RL1.2 https://www.unicode.org/reports/tr18/#RL1.2 [2] https://devlog.hexops.com/2021/unicode-data-file-compression/ https://devlog.hexops.com/2021/unicode-data-file-compression... [3] https://github.com/svaarala/duktape/issues/1718 https://github.com/svaarala/duktape/issues/1718
    - Rochus 4y ago
      That's interesting, thanks. I'm currently using the trie and properties table from https://github.com/rochus-keller/Qt-4.8.7/blob/master/src/corelib/tools/qunicodetables.cpp https://github.com/rochus-keller/Qt-4.8.7/blob/master/src/co... for a new open source project of mine; the source file is 204k and the compiler produces an 68k object file from it.

jalino23 4y ago

whats the use case of quick js compared to node?

atwood22 4y ago
It’s really good as an embedded JS engine. Like let’s say you want to make an iOS app that executed JS. If you use V8 (Node’s JS engine), then you’re app is at a minimum 28M in size just from V8. If you use QuickJS, your app size increases by less than 1M.
- skybrian 4y ago
  On iOS, why wouldn't you use WebKit? (Genuine question; I'm not an iOS developer.)
  - atwood22 4y ago
    I don’t think you can create native bindings in WebKit. You can only interact with something like WKWebView using serializable messages. QuickJS let’s you create native objects and expose them directly to the JS API. QuickJS also let’s you get JS variables natively and control how and when things get executed.
    - deleted 4y ago
      [deleted]
    - saurik 4y ago
      You would use JavaScriptCore, not WebKit.
      - atwood22 4y ago
        Ah yea that’s right. Now I remember why we didn’t use JSCore. We had a cross-platform C++ library for both Android and iOS so it was better to use a single JS Engine.
4y ago