mirror of
https://github.com/anomalyco/opentui.git
synced 2026-04-25 04:55:58 +03:00
[GH-ISSUE #2] Support Node/Deno (NAPI instead of bun:ffi) #3
Labels
No labels
bug
core
documentation
feature
good first issue
help wanted
pull-request
question
react
solid
tmux
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/opentui#3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @remorses on GitHub (Jul 29, 2025).
Original GitHub issue: https://github.com/anomalyco/opentui/issues/2
Have you thought about using NAPI to make the project run both in Bun and Node?
There is this package to create automatic NAPI bindings from Zig code https://github.com/cztomsik/napigen
@kommander commented on GitHub (Jul 29, 2025):
I am open to it. FFI was just really convenient and is faster than NAPI, but yes I gave it some thought already. Might happen at some point, just not priority for now on my side. A lot to be figured out for the actual API and then probably some stabilization needed.
@jlucaso1 commented on GitHub (Jul 29, 2025):
wasm (free standing or wasi) can be considered too?
@kommander commented on GitHub (Jul 29, 2025):
@jlucaso1 I considered it in the beginning, but it being a lib for terminal UIs it's not a blocker to load native libs and wasm has some overhead with its vm.
@esatterwhite commented on GitHub (Nov 12, 2025):
I've only just stumbled onto this project and rather excited by its goals. But, I am confused as to the target run time. Does this only run on bun?
@esatterwhite commented on GitHub (Nov 12, 2025):
Deno also has an FFI interface as well for what its worth.
@kommander commented on GitHub (Nov 12, 2025):
It currently only runs on bun exclusively. There are no plans to support other runtimes, though I am open to it.
@esatterwhite commented on GitHub (Nov 13, 2025):
Can we make plans? 😃
@kommander commented on GitHub (Nov 13, 2025):
Sure, the
zig.tsexports aRenderLibinterface and aresolveRenderLibfunction, both is used throughout the codebase. It also eagerly loads the native lib to reduce startup time.So to provide a NAPI module one Just™ would have to solve this incomplete list:
lib.zigc abi to build.nodemodules, using the static libs from then next stepRenderLibcompatible interfaceresolveRenderLiband for the eager loading if !bun return the napi libzig.tsneeds to be conditional and for non-bun dynamically import theRenderLibcompatible.nodemodule instead of the native ffi libbuild.zigto also build static versionscore/scripts/build.ts.nodemodules as a step.nodemodules to the respective binary npm packages.nodemodules to artifactsbuild.ymlrelease.ymlAnd the napi needs to be maintained to stay in sync with the native interface, which is far from stable and changes almost daily, so something generated would work best if possible, so it can be regenerated when the native interface changes.
Note: this does not consider the whole 3D part which currently also uses an FFI lib, which needs to be switched out to some napi webgpu module as well. Deno has its own webgpu bindings. All of the webgpu interfaces should be mostly compatible though.
@remorses commented on GitHub (Nov 13, 2025):
It would be easier to wait for Node.js to add something like Bun ffi into core: https://github.com/nodejs/node/pull/57761
@kommander commented on GitHub (Nov 14, 2025):
Probably, would have to check how compatible the interfaces are, as ffi != ffi, so it likely still needs a compat layer for different runtimes.
@esatterwhite commented on GitHub (Nov 15, 2025):
Maybe support for deno first, node later when the playing field is a bit more level?
@kommander commented on GitHub (Nov 15, 2025):
That could be more realistic than NAPI I think
@esatterwhite commented on GitHub (Nov 16, 2025):
Out of curiosity, Why does this project need access to the gpu? Wouldn't it make more sense to leave that up to user to install gpu accelerated terminals if that is what they want?
It seems a bit outside the scope of what a tui framework should care about. But 🤷 I don't have a leg to stand on here.
@kommander commented on GitHub (Nov 16, 2025):
It doesn't need it for anything non-3D, the threejs stuff is completely optional for the core, just a fun gimmick currently. It doesn't load the 3D module if it's Not explicitly imported, so it could be made a separate package. I was just mentioning it for completeness.
@joshuaboys commented on GitHub (Dec 29, 2025):
I am commenting here so I remember to keep checking in... was pretty excited to use opentui but will have to use ink for now so I can actually ship the product.. but I have added "move to opentui when they support Node or I support Bun"
Keep up the great work though! Looks awesome
@remorses commented on GitHub (Dec 29, 2025):
Another benefit of using NAPI is easier porting to other high level languages without writing too much code: you can create a NAPI runtime for that language and load the addon with support for classes, async, objects, callbacks, etc
For example here I loaded the node-canvas npm package in Python!
https://github.com/remorses/napi-python/blob/main/examples/canvas-draw.py
@5hubham5ingh commented on GitHub (Jan 15, 2026):
Hi, stumbled here while looking for ways to use the lib in txiki.js and I got it to work, miserably I must add :-)
So, a compat layer would be awesome. Something like:
Using txiki.js to build and distribute compiled bytecode or binary would be great and a big advantage over other runtimes consuming memory and having binary sizes in the range of triple-digit mbs compared to a couple of mbs for txiki.js.