UEFI Bindings for JavaScript

Original Article ↗ Hacker News Discussion ↗

Overall reaction

  • Many describe the project as “cursed” or “blursed” but also hilarious and impressive.
  • A lot of commenters clearly enjoy the sheer audacity: “everything rewritten in JS,” “it begins,” references to “The Birth and Death of JavaScript,” etc.
  • Several people quote the “your scientists/developers were so preoccupied with whether they could…” line, reflecting both admiration and discomfort.

Intended purpose and potential uses

  • Author’s stated goal (per comments) is a bootloader customizable via HTML/CSS/JS, not just a random stunt.
  • People joke about DOM support, CSS splash animations, and React/Ink-based UEFI TUIs; some note this might even improve current “gamer” firmware UIs.
  • A few imagine using the UEFI network stack for JS-based boot scripting or package loading.
  • There’s speculative interest in going further: JS inside coreboot, browser support for UEFI, etc. (often tongue‑in‑cheek).

Security, stability, and threat model

  • One camp sees this as dangerous: an unnecessary new attack surface at a critical layer.
  • Another camp argues UEFI already runs arbitrary code; the real risk is bad JS, not the interpreter itself, and that’s comparable to C/C++ UEFI code.
  • Some celebrate it as “more ways to jailbreak stuff.”
  • Longer subthread on whether a JS (or GC’d) kernel is viable: concerns about GC pauses, out‑of‑memory behavior, and historical attempts (.NET/Longhorn), versus claims that GC in kernels is hard but technically possible.

JS as OS / systems language

  • Clarification: this uses C to embed a JS engine and expose UEFI protocols; once bootstrapped, you could in principle implement “OS-like” logic in JS, but you still need low‑level code (interrupts, page tables, etc.).
  • Debate over how much of an OS could be written in JS alone versus needing C/asm or a meta‑circular VM.
  • Examples mentioned: JS/asm.js attempts at kernels, Linux compiled to asm.js, and MicroPython‑style projects in other languages.

Technical details and language choices

  • Choice of Duktape is praised: small, embeddable, works in freestanding environments; heavyweight engines like V8/SpiderMonkey would be painful at boot time.
  • Interesting design point: raw UEFI services (graphics, filesystem, network) are exposed directly to JS rather than wrapped in a heavy abstraction layer.
  • Floats are reported to work; someone notes Linux historically avoided FP in kernel to skip saving/restoring FP registers.

Broader JavaScript discussion

  • Philosophical split: JS “should stay in the browser” vs “JS as a general‑purpose language.”
  • Some emphasize that bloaty Electron apps are more about Electron and npm stacks than about JS itself.
  • Others mention using Deno/Node/Bun for scripting and system tasks as evidence that JS is already a practical general‑purpose language.

Educational and novelty value

  • Multiple comments frame this as a great “silly experiment” and learning tool rather than something production‑ready.
  • Several say it’s a striking demonstration of control over the machine and a fun playground for low‑level + JS enthusiasts.