Porting my JavaScript game engine to C for no reason

Original Article ↗ Hacker News Discussion ↗

Reception & Legacy of Impact / high_impact

  • Many commenters are excited to see the old JS engine reborn in C and recall learning a lot from Impact, sometimes finishing their only completed game with it.
  • Nostalgia around Biolab Disaster, X-Type, and the fact that Impact underpinned commercial titles like CrossCode.
  • Some treat high_impact as a lean, educational scaffold rather than a feature-complete engine, which they consider a positive.

JS, C, WASM & Performance

  • Several note that modern JS engines (and JITs like V8) can optimize hot paths extremely well, sometimes approaching AOT compilers.
  • Multiple people argue that, in the browser, moving to WebGL (or shaders) yields bigger gains than just switching JS → C → WASM.
  • Others share poor experiences with heavy WASM game frameworks (e.g., slow asset loading, CPU-bound post-processing) and switch back to JS/TS for simpler integration and fewer layers.
  • There is curiosity about how a JS engine like LittleJS would compare to the C port on particle-heavy workloads.

Impact’s Original JS Engine & “End of Life”

  • The original Impact engine is described as burdened by historical browser hacks: lack of classes/modules, vendor prefixes, broken Canvas2D semantics on “retina” devices, no WebGL/WebAudio, touch non-standards, audio bugs, and custom polyfills.
  • The author notes an unreleased “Impact2” that fixed many issues with a new editor, but it stalled; high_impact is presented as a kind of redemption and a clean modern base.

Framework vs Library & Portability

  • A framework is framed as an “empty scaffold that calls you,” versus a library that you call.
  • Some still see frameworks as negative or “not playing nicely” with others, preferring composable libraries and minimal “framework core,” though they concede engines for consoles and mobile often must be more framework-like.

C Ecosystem, Toolchains & Memory

  • One commenter criticizes vendoring all dependencies as emblematic of C’s weak package-management story; others counter that distributions’ packages are the usual answer.
  • Console targets (e.g., Switch) are described as constrained by vendor toolchains; languages not directly supported (Rust, JS) must go through C/C++ or custom transpilation pipelines.
  • Several praise arena allocation and even fully static memory layouts (no dynamic allocation) for predictability and performance, citing web servers and a database built this way.

Flash, Web History & ActionScript

  • Debate on what “killed” Flash: some point to Adobe’s acquisition and product strategy, others to iOS blocking Flash, and a major Chrome release that throttled third-party Flash and broke ad impressions.
  • There’s regret that ActionScript died with Flash; some feel it’s closer to what JavaScript “should have been,” noting its influence on an abandoned ECMAScript edition.

Coin-Miner Controversy & Trust

  • A long subthread debates the past JavaScript-based crypto-miner service associated with the engine’s author.
  • One side portrays it as enabling large-scale cryptojacking and malware, claims enormous profits, and argues this history undermines trust in any new code.
  • The author responds that revenues were much smaller, that the service itself was legal client-side mining intended as a privacy-friendly ad alternative, used legitimately in beta, and only later widely abused on hacked sites; they emphasize a short period of direct involvement and deny organizing doxxing.
  • Critics counter with malware statistics, media coverage, and examples of hostile content from an associated imageboard, and maintain that the ethical damage is substantial regardless of intent.
  • Some third parties say the idea of optional mining-as-payment was clever but agree they would not fully trust new software from the same source; others separate concept (good) from misuse by “rogue actors.”