Proposal: JavaScript Structs

Original Article ↗ Hacker News Discussion ↗

Purpose and potential benefits

  • Many see structs as a way to:
    • Raise the performance ceiling for hot code by giving engines fixed-layout, less-dynamic objects.
    • Make shared-memory multithreading in JS more practical than today’s SharedArrayBuffer + manual layout.
    • Improve interop with WebAssembly and low-level APIs (WebGPU, FFI), where packed, predictable layouts matter.
  • Some note this aligns with optimizations engines already do (hidden classes), but with explicit guarantees that simplify optimization and debugging (e.g., heap dumps with meaningful struct names).

Shared structs, unsafe blocks, and memory model

  • Shared structs plus locks/atomics are framed as JS’s analogue to WASM threads: racy but sandboxed, so they can’t crash the browser/OS, only corrupt their own data.
  • Several commenters are uneasy about exposing “unsafe” blocks in a language used to run untrusted code; they fear data races and misuse, even if sandboxed.
  • Others argue unordered, non-atomic operations are essential for performance on modern weak memory architectures, and fully atomic-only designs would be too slow.
  • It’s noted that SharedArrayBuffer already permits data races on the web; structs would formalize and structure patterns built on top of that.

Layout, typing, and serialization

  • Debate over whether fields should be explicitly typed to allow packing (1/2/4-byte ints) vs. generic “any” fields that likely force 8‑byte slots.
  • Concerns that if constructors can define varying fields, you lose the main advantage of predictable layout.
  • Some want first-class ways to map structs to ArrayBuffers or a “StructArray” type for compact arrays, rather than ad‑hoc libraries.

Language complexity and design philosophy

  • Strong current of worry that JS (and TS/C#) are becoming bloated with overlapping constructs (classes, records/tuples, now structs), raising the barrier to entry and harming readability.
  • Others counter that:
    • You don’t have to use every feature; most complexity lands in library code, benefiting application developers indirectly.
    • A “stricter, faster subset” like unshared structs is desirable, and performance-focused features are a legitimate direction.

Relation to other proposals and alternatives

  • Several compare structs to the stalled Records & Tuples proposal:
    • Records/tuples were about identity-free, immutable composite values with deep equality.
    • Structs are about fixed layout and shared-memory semantics; not a direct replacement.
  • ShadowRealms/SES concerns previously constrained R&T (e.g., what counts as “deeply immutable”), and some fear similar ecosystem friction here.
  • A faction argues serious multithreaded or low-level work should move to WASM/Rust/Go instead of further complicating JS; others reply that JS remains unavoidable in browsers, and better primitives are needed where it’s already used.