HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
WebAssembly
js-string-builtins
WebAssembly2023–2025
WebAssembly / js-string-builtins

js-string-builtins

JS String Builtins

Web Development
Explore on GitHubRead Hacker News discussions
7Distinct people
8Mentions
0Explicit recommenders
25GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

JS String Builtins

GitHub

Where it is used

No documented product use has been verified yet.

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, 1:49:46 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 month8 dated mentions

Observed mentions: 2023-10-04 15:05:17 UTC to 2025-08-09 05:57:59 UTC.

01232023-10-01 00:00:00 UTC to 2023-11-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 commentsOct 20232023-11-01 00:00:00 UTC to 2023-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-12-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2024-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-02-01 00:00:00 UTC to 2024-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-03-01 00:00:00 UTC to 2024-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-04-01 00:00:00 UTC to 2024-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-05-01 00:00:00 UTC to 2024-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-06-01 00:00:00 UTC to 2024-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-07-01 00:00:00 UTC to 2024-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-08-01 00:00:00 UTC to 2024-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-09-01 00:00:00 UTC to 2024-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsSep 20242024-10-01 00:00:00 UTC to 2024-11-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-11-01 00:00:00 UTC to 2024-12-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-12-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2025-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-02-01 00:00:00 UTC to 2025-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-03-01 00:00:00 UTC to 2025-04-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-04-01 00:00:00 UTC to 2025-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-01 00:00:00 UTC to 2025-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-01 00:00:00 UTC to 2025-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-07-01 00:00:00 UTC to 2025-08-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-08-01 00:00:00 UTC to 2025-09-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsAug 2025

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
Oct 20232023-10-01 00:00:00 UTC2023-11-01 00:00:00 UTC303
Nov 20232023-11-01 00:00:00 UTC2023-12-01 00:00:00 UTC000
Dec 20232023-12-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
Jan 20242024-01-01 00:00:00 UTC2024-02-01 00:00:00 UTC000
Feb 20242024-02-01 00:00:00 UTC2024-03-01 00:00:00 UTC000
Mar 20242024-03-01 00:00:00 UTC2024-04-01 00:00:00 UTC000
Apr 20242024-04-01 00:00:00 UTC2024-05-01 00:00:00 UTC000
May 20242024-05-01 00:00:00 UTC2024-06-01 00:00:00 UTC000
Jun 20242024-06-01 00:00:00 UTC2024-07-01 00:00:00 UTC000
Jul 20242024-07-01 00:00:00 UTC2024-08-01 00:00:00 UTC000
Aug 20242024-08-01 00:00:00 UTC2024-09-01 00:00:00 UTC000
Sep 20242024-09-01 00:00:00 UTC2024-10-01 00:00:00 UTC000
Oct 20242024-10-01 00:00:00 UTC2024-11-01 00:00:00 UTC101
Nov 20242024-11-01 00:00:00 UTC2024-12-01 00:00:00 UTC101
Dec 20242024-12-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
Jan 20252025-01-01 00:00:00 UTC2025-02-01 00:00:00 UTC000
Feb 20252025-02-01 00:00:00 UTC2025-03-01 00:00:00 UTC000
Mar 20252025-03-01 00:00:00 UTC2025-04-01 00:00:00 UTC101
Apr 20252025-04-01 00:00:00 UTC2025-05-01 00:00:00 UTC000
May 20252025-05-01 00:00:00 UTC2025-06-01 00:00:00 UTC000
Jun 20252025-06-01 00:00:00 UTC2025-07-01 00:00:00 UTC000
Jul 20252025-07-01 00:00:00 UTC2025-08-01 00:00:00 UTC101
Aug 20252025-08-01 00:00:00 UTC2025-09-01 00:00:00 UTC101

What Hacker News says

8 sources
jauntywundrkind·Aug 9, 2025
There is a JS strings spec for wasm underway. https://github.com/WebAssembly/js-string-builtins This feels so much like one of those cases where perfect is the enemy of the good. Node.js spent a decade being wrapped about the axle, convinced that cjs and esm could never work together. Ignoring that it worked great in standard-things/esm. But eventually Bun came around and that somehow made the case that all the hemming & hawing was nonsense all along, that doing nothing was worse than letting Fear Uncertainty and Doubt reign. It just seems so unlikely that much of JS really matters for webidl. WebIDL specifies mostly structures and routes. It throws some exceptions but that doesn't seem particularly incompatible with wasm. WebIDL has promises, which is already pretty well solved by https://github.com/WebAssembly/js-string-builtins (which
Read the rest
alas only Chrome seems to be moving on). GC is also in wasm now. I just don't get the defeatism. Fear Uncertainty and Doubt can be so seductive, anti-belief can be so fierce, and it sucks when things aren't perfect or when there's warts, but the paralysis here & anti-will seems so wildly disproportionately strong.
In HTML-in-Canvas
bakkoting·Mar 26, 2025
JavaScript is being developed with the assumption that wasm will continue to exist. For example, JS is unlikely to get SIMD support because wasm can do SIMD in a cleaner way than JS can. (I am one of the people developing JavaScript.) Rather, what we're likely to see is work which makes integration between wasm and JS easier - see, for example, the wasm string builtins proposal [1], the proposal for native support for importing wasm from JS [2], or the proposal for fixed-layout JS objects which would allow directly reflecting wasm-GC objects in JS [3]. [1] https://github.com/WebAssembly/js-string-builtins/blob/main/... [2] https://github.com/WebAssembly/esm-integration/tree/main/pro... [3] https://github.com/tc39/proposal-structs?tab=readme-ov-file#...
In Hyperlight WASM: Fast, secure, and OS-free
peutetre·Nov 21, 2024
Eventually by using the component model which will expose the DOM API. It will get to direct wasm to WebIDL calls one day: https://github.com/WebAssembly/component-model The component model is being used for the WebAssembly System Interface (WASI). WASI provides operating system integration for wasm applications outside the browser: https://github.com/WebAssembly/WASI/tree/main In the meantime you can use JavaScript glue code auto-generated by your toolchain to access the DOM. This will be made better with builtins like the js-string-builtins proposal: https://github.com/WebAssembly/js-string-builtins/blob/main/... You can call JavaScript functions and DOM methods from wasm like this example from Hoot, which is a Scheme to wasm compiler: https://spritely.institute/news/building-interactive-web-pag...
In Ask HN: What are some unpopular opinions you got?
singularity2001·Oct 26, 2024
From the new official WASM proposal: https://github.com/WebAssembly/js-string-builtins/blob/main/... "the overhead of importing glue code is prohibitive for primitives such as String, ArrayBuffer, RegExp, Map, and BigInt where the desired overhead of operations is a tight sequence of inline instructions, not an indirect function call" I guess the more elegant and universal stringref proposal is DEAD now !? https://github.com/WebAssembly/stringref/blob/main/proposals... I don't really mind, as it keeps the wasm bytecode cleaner.
In Should JavaScript be split into two languages?
haberman·Oct 20, 2023
> They can't really be done as libraries. It's definitely the case that you can't implement a string type in WASM and have it interoperate with JavaScript strings. But there is no reason that JavaScript strings can't be a "special" kind of import that provides functionality implemented by the engine. In other words, #include <wasm/wtf16string.h> could provide an API for the built-in JavaScript string, much like #include <ruby.h> provides access to the native Ruby string in Ruby extensions. I believe this is how the counter-proposal works: https://github.com/WebAssembly/js-string-builtins/blob/main/... For engines that do not have a built-in JavaScript-like string type, the wasm/wtf16string.h library could be implemented in WASM as a polyfill. In that case, there is no native string to interoperate with, so no disadvantage to implementin
Read the rest
g directly in WASM (except perhaps a bit of speed penalty).
In Requiem for a stringref
haberman·Oct 19, 2023
I really have trouble understanding the push to provide higher-level features as intrinsic types and instructions. AIUI, the main alternative to stringref (linked in the article: https://github.com/WebAssembly/js-string-builtins/blob/main/...) is to provide string types via WebAssembly's normal "import" mechanism. This alternative makes more sense to me. When you write extension modules for languages like Python, Ruby, PHP, or even JavaScript (via V8 or JavaScriptCore), you are always importing APIs like strings (eg. #include <ruby.h>). It seems natural to me that WebAssembly would be the same way. Now ideally a WebAssembly module wouldn't be specific to one particular embedding environment. You would want to standardize this string API, so that a single API can be used efficiently with multiple host languages. So you'd want somethin
Read the rest
g more like #include <wasm/wtf16string.h>. But if it's an import, it also leaves open the possibility that such an API can evolve over time, or that a competing API could supplant it as the landscape of language engines changes. By putting it directly into the instruction set, you'd be baking in assumptions about how JS engines in 2023 function, even though those assumptions can (and hopefully will) change over time. It's true that wasm/wtf16string.h probably won't be available in environments that don't have JS-style strings. But that seems for the best. I'd rather have a leaner WebAssembly than make every WebAssembly engine provide JS-style strings. In the case that the host environment doesn't already have a JS-style string that you are trying to interoperate with, why not just have Java implement its string type directly in WebAssembly? Or once shared libraries are available, wasm/wtf16string.h could be provided via some third-party library, shared across multiple modules, leaving open the possibility of passing strings around between modules. I guess, to the article's point, why shouldn't memcpy() be an import also? What is gained by making it part of the instruction set? I assume that a WebAssembly implementation could recognize special imports, and optimize them the same as if it were a built-in instruction.
In Requiem for a stringref
davexunit·Oct 4, 2023
I'm working on a WASM project[0] with Andy, the stringref champion, and unfortunately the future for stringref is uncertain. There is now a new proposed alternative called "JS string builtins"[1]. The way we intend to ship support for strings currently is to just use JS string builtins, because it is just a set of imported functions, not new instructions. Those imports can either be provided by efficient, native compiled functions (currently behind a V8 feature flag, not sure if other JS engines support it) or from a JS polyfill. It's not an ideal situation but this will allow for shipping strings that work in all browsers with default settings. [0] https://gitlab.com/spritely/guile-hoot [1] https://github.com/WebAssembly/js-string-builtins/blob/main/...
In Extism makes WebAssembly easy

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.