Mirror of forum.nim-lang.org

13363 :: JS Backend Support For Nimony

• Niminem (orginal) [2025-08-28T02:54:11+02:00] view original

  Now that we are getting closer and closer to the finish line for Nimony, I'd like to start a thread here for the js backend.

  We need it (IMO). It's one of the features that drew me in about Nim ;)

  I personally don't have the time to help, but I do have some coin and I'm happy to support commercially.

  Curious to hear everyone else's thoughts about having js integrated and maybe discuss assembling a task force for this lol?

---

• Araq (orginal) [2025-08-28T08:45:17+02:00] view original

  I sent you an email.

---

• ASVI (orginal) [2025-09-02T17:10:13+02:00] view original

  I completely agree, javascript frontend is really important thing and I hope that nimony will have it. But besides it, I would like to have wasm backend as a separate backend and as used inside js backend:

  
  proc jsProc
  proc wasmProc {.wasm.}
  proc myCoolAlgorithm*() {.wasm.} =
    jsProc()
    wasmProc()
  Run

  This will speed up some algorithms. In addition, you can add

  
  import foo {.wasm.}
  Run

  Because annotating each procedure in the foo module can be annoying. By the way, the wasm backend is useful in itself, for example, a situation may arise when you need to run someone else's (not always safe) code in a sandbox. And wasm copes with this and at the same time works quite fast with its jit

---

• nimaoth (orginal) [2025-09-02T17:45:22+02:00] view original

  I would also really like a builtin wasm backend. I started working on one a while ago, but haven't continued in the last few weeks, and it's very bare bones still. I might continue on that later this year, or maybe it can be used as a starting point for someone else ^^

---

• elcritch (orginal) [2025-09-02T18:22:33+02:00] view original

  That'd be next level. Nimony would be perfect for JS/WASM web apps. @nimaoth awesome, the hardest piece would probably be the re-looper algorithm. Though probably not too bad with NIF blocks.

---

• Araq (orginal) [2025-09-02T23:41:33+02:00] view original

  I started working on one a while ago ...

  This is awesome!

---

• stisa (orginal) [2025-09-08T21:07:29+02:00] view original

  nice! I gave it a try some years ago (nwasm) but didn't have the time to get it past a proof of concept. I'd love to see this happen!

---

• Gschnuuferi (orginal) [2025-09-09T20:52:34+02:00] view original

  That is what I thought too. Actually, kind of took it for granted that it would come after the main idiomatic design choices for Nim 3.0 are ironed out. Nim→JS is quite popular indeed. There was another discussion where the topic was touched on: https://forum.nim-lang.org/t/8727

  I was of the impression from Araq's reply that this wasn't something that Nimony would do, at least to start with, but a separate pipeline that wouldn't need to depend on Nimony.

  Not something I would be particularly worried about either way. However, if Nimony with NIF, NIFC, and LLVM target subsequently, were to unleash Futhark-ish capabilities for wrapping C++, that's a bigger win.

---

• Araq (orginal) [2025-09-09T21:34:20+02:00] view original

  I was of the impression from Araq's reply that this wasn't something that Nimony would do, at least to start with, but a separate pipeline that wouldn't need to depend on Nimony.

  No, most of the pipeline would be and will be re-used.

---

• AmjadBHD (orginal) [2026-01-08T11:35:50+01:00] view original

  Should the JS backend use NIFC or NJ ?

---

• Araq (orginal) [2026-01-08T11:59:21+01:00] view original

  It should use NJ.

---

• AmjadBHD (orginal) [2026-01-08T20:44:19+01:00] view original

  Can .passive functions be supported or the native JS async functions should be used?

---

• Araq (orginal) [2026-01-09T09:02:52+01:00] view original

  The .passive functions would naturally be supported but interop with JS's async might cause problems, I haven't thought it through...

---

• AmjadBHD (orginal) [2026-01-28T20:37:40+01:00] view original

  Should Nim's type system map to ArrayBuffers and DataViews or to regular JS objects like it is currently?

---

• Araq (orginal) [2026-01-28T21:05:29+01:00] view original

  Keeping the existing interop is more important than speed, so it should be "regular JS objects".

---

• AmjadBHD (orginal) [2026-01-28T22:03:57+01:00] view original

  This is not only about speed and memory efficiency, although that's a great deal for a plethora of applications. Nim, being a systems language, is easier to map to an ArrayBuffer-based code, without tons of when defined(js) and compilation errors.

  Interoperability should well be preserved with proxies for exported types, we shouldn't worry about code out there that relies on internal implementation details. Interoperability with existing backends (c, c++) and a possible wasm backend is a big win.

---

• Araq (orginal) [2026-01-29T08:10:15+01:00] view original

  Nim, being a systems language, is easier to map to an ArrayBuffer-based code, without tons of when defined(js) and compilation errors.

  Maybe, I don't know. It's very risky, I see the value in Nim's current scheme powering Karax, I don't see the value in:

  • can't use the DOM easily, Nim's objects are byte buffers
  • so we now emulate alloc and dealloc too
  • so now cast works for your fwrite call
  • except that you don't have fwrite as it's the freaking browser which doesn't give you a filesystem to speak of. All of Posix (threads?!) is gone too.

---