HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
svaarala
duktape
JavaScript2014–2026
svaarala / duktape

duktape

Duktape - embeddable Javascript engine with a focus on portability and compact footprint

Web Development
Explore on GitHubRead Hacker News discussions
14Distinct people
19Mentions
0Explicit recommenders
6.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Duktape - embeddable Javascript engine with a focus on portability and compact footprint

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year19 dated mentions

Observed mentions: 2014-12-04 20:14:24 UTC to 2026-03-28 17:56:37 UTC.

0123452014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC211
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC312
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC514
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

19 sources
MaulingMonkey·Mar 28, 2026
> One explaination for that would be stripping "out of scope" macros that the sublibrary depends on but wishes to avoid including. Another explaination would be the original source being multi-file, with the single-file variant being generated. E.g. duktape ( https://github.com/svaarala/duktape ) generates src-custom/duktape.c from src-input/*/*.c ( https://github.com/svaarala/duktape/tree/master/src-input ) via python script, as documented in the Readme: https://github.com/svaarala/duktape/tree/master?tab=readme-o...
In A single-file C allocator with explicit heaps and tuning knobs
kbolino·Apr 19, 2024
Video games do not generate large streams of data, they generate individual values on demand. Your link says, to generate 8 bytes, chacha12 on modern hardware needs 24-45 cpb. That's 192-360 cycles to generate enough bits for a pseudorandom double-precision floating-point number. Xoshiro256+ [1], a relatively high-quality generator for this purpose, can do it with 11 single-cycle ALU ops. So unoptimized xoshiro256+ should be 17 times faster than optimized chacha12 on the best hardware. This is a classic latency vs. throughput issue. Now, maybe you could optimize the use of a CSPRNG here by filling large buffer(s) and sampling values from them. Some warm-up time could go a long way. However, I fear that you would run into one or more of the following problems: - stop-the-world pause to refill the buffer (e.g. single buffer, no threading) -
Read the rest
synchronization delays from mutex locks (e.g. ring buffer refilled from a background thread) - high memory usage (e.g. rotating pool of buffers, atomically swapped) Needless to say, none of these solutions is anywhere near as simple to implement as a non-cryptographic PRNG. Now let's consider determinism. Video games generally use a lot of differently seeded instances of the same PRNG algorithm to provide random numbers in different parts of the simulation. Since each part may demand random numbers at different rates, it's hard to replace several independent PRNGs with a single PRNG without compromising determinism. In the 4096 bytes necessary to run one instance of chacha12 at its maximum efficiency, you can fit 128 instances of xoshiro256+ or 512 instances of splitmix64 [2]. [1] = https://prng.di.unimi.it/xoshiro256plus.c [2] = https://github.com/svaarala/duktape/blob/master/misc/splitmi...
In Randar: A Minecraft exploit that uses LLL lattice reduction to crack server RNG
mananaysiempre·Nov 15, 2022
You can also refer to the Unicode routines of other small JS engines[1,2], those don’t use ICU either, although the implementations are mercilessly size-optimized (to put it politely) and restricted to what the target JS version requires (e.g. Duktape does casemapping but no normalization). Still, Bellard’s in particular look like he had a small Unicode processing library lying around and just copied it into the tree, not like he was forced to write the absolute minimum to do a JS inteprerer, so they can even be compared with dedicated libraries like libgrapheme, libutf8proc or libutf. [1] https://github.com/bellard/quickjs/blob/master/libunicode.c [2] https://github.com/svaarala/duktape/blob/master/src-input/du...
In Libgrapheme: A simple freestanding C99 library for Unicode
MaulingMonkey·Sep 17, 2022
> memcpy from bytes to a NaN should work fine Signaling NaNs are explicitly undefined in C11 F.2.1.: "This specification does not define the behavior of signaling NaNs." - and in practice may be "quieted" by conversion to Quiet NaNs, changing their bit patterns, or may trigger actual signals. Fast math optimization flags will also break the hell out of your code by assuming NaNs are impossible. I want to say there are more circumstances where optimizers and compiler generated code can butcher your NaN payloads, but I'd be working off recollected hearsay and I can't find a source, so don't quote me on that. NaN boxing is common enough that, if you take the right precautions, a modern compiler should probably support it, maybe. NaN boxing is uncommon enough that, if your codebase needs to be sufficiently portable, you need an opt out for
Read the rest
when it breaks. Let's review duktape's scars: https://github.com/svaarala/duktape/blob/123d9426d5e5b36d5da... https://github.com/svaarala/duktape/blob/5252b7a50611a3cb8bf... https://github.com/svaarala/duktape/blob/224a0b89ca08a36e37e... (for context, a "packed" duk_tval involves NaN boxing) Note that "the right precautions" involve unions and proper integer types to avoid optimizer-invoked rewrites of the value and debugging when things go wrong, not simply YOLOing bytes into a double via memcpy. Note that debugging when it all goes terribly wrong can be quite painful. I've personally had the misfortune of being forced to debug duktape being built with fast math optimizatoins enabled on one "rare" platform + build configuration that wasn't caught by duktape's #if defined(__FAST_MATH__) checks linked above (wasn't Clang nor GCC, so go figure it didn't make the same #define)
In NaN Boxing (2020)
mananaysiempre·Jul 8, 2022
> 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
Read the rest
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 [2] https://devlog.hexops.com/2021/unicode-data-file-compression... [3] https://github.com/svaarala/duktape/issues/1718
In Duktape is an embeddable JavaScript engine
MaulingMonkey·Oct 20, 2021
JavaScript's parseInt and parseFloat return NaN on something as benign as "well, that wasn't a number". var jsonish = "..."; var number = parseFloat(jsonish); if (!isNaN(number)) { // deserialized a number } else { // ...try deserializing as a boolean or string next... } Fast math optimizations can break code like this by breaking isNaN. I was porting a C++ project to a certain platform - and that platform enabled a -ffast-math equivalent by default in Release (but not Debug) builds! This broke duktape, a JS engine said project embedded, in some nasty and subtle ways. Instead of storing a number/pointer/??? (8 bytes) + type tag (4? bytes) for each dynamically typed JS value, duktape can bit-pack values into a single 8 byte "double" value by storing object/string handles as NaN values - this isn't an
Read the rest
uncommon trick for dynamically typed scripting stuff: https://github.com/svaarala/duktape/blob/c3722054ea4a4e50f48... Naturally, the -ffast-math equivalent broke isNaN checks, which caused random object/string handles to be mistakenly reinterpreted as "numbers" - but only in Release builds, for this one particular platform, in one rarely taken branch, so neither QA nor CI caught it, leading to hours of manufacturing a repro case, stepping through an absurd amount of code, and then finally looking at the default build rules and facepalming. Cursing the platform vendor under my breath, I overrode the defaults to align with the defaults of every other config x platform combination we already had: no fast math. If you want those optimizations, use SSE-friendly NaN-avoiding intrinsics - or, if you must use the compiler flags, ensure you do so consistently across build configs and platforms, perhaps limited to a few TUs or modules if possible. This allows you to have a chance at using your Debug builds to debug the resulting "optimizations".
In Optimizations Enabled by -ffast-Math
dazhbog·Oct 15, 2020
Moddable and Espruino have a slightly more restrictive license for when u want to maybe monetize your project. Duktape and Jerryscript are way bigger open-source projects (on github at least). I used almost all of the interpreters to do a hello world on a microcontroller. They all work great! I found Duk to have a slightly cleaner API for bindings, for example writing to the serial port from JS land. https://github.com/svaarala/duktape https://github.com/jerryscript-project/jerryscript
In Espruino: JavaScript for Microcontrollers
shakna·Nov 17, 2019
From what I can see [0], the API is somewhat similar to Duktape's [1], which is good. It's an easy to use API, which gives you as much power as you ask for. (And both have slight improvement's over Lua's, in getting rid of overhead for some things.) --- Duktape uses the MIT license [2], whereas MuJS has a slightly different license [3] which is much less specific, in fact I'm not entirely certain what the license requires in a legal setting. This particular fragment: > Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted Seems to imply paid licenses for MuJS, but doesn't actually seem to require that a paid agreement be followed, providing a sort of legal escape hatch. It is just a quibble, but legal problems tend to come down to arguments over a half dozen words anyway. Th
Read the rest
at being said, I'm assuming MuJS is intended to be used as part of the GhostScript environment at some point, and they might have assumed that the two routes will be Artifex licensing + this other license. (The usual AGPL route they follow would have been my choice.) --- [0] https://mujs.com/examples.html [1] https://duktape.org/api.html [2] https://github.com/svaarala/duktape/blob/master/LICENSE.txt [3] https://mujs.com/license.html
In An embeddable JavaScript interpreter in C

Showing the 15 most recent of 19 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.