godotengine
Add a built-in JavaScript runtime for non-web builds to make JavaScriptBridge functional on all platforms
Describe the project you are working on
I'm hacking on a game where the game-core is written in NodeJS/custom-web-runtime. It's relying heavily on Godot's JavaScriptBridge for game-state and multiplayer networking.
Describe the problem or limitation you are having in your project
JSBridge dosen't work unless the project is running in a web environment.
I cannot test the game through F5 (Run Project) / F6 (Run Current Scene), so i have to do a web-export every time i do a change. I would also like to release the game as native/mobile, but would need an godot owned JS-runtime for that.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Optionally bundle a minimal JS-runtime so bridge works on mobile/desktop builds.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
When starting Godot JavaScriptBridge, if runtime is not available, then boot node.js or a bundled bare thread.
If this enhancement will not be used often, can it be worked around with a few lines of script?
I have abstracted/stubbed out most JSBridge calls with hardcoded return values but i walked past the warning signs of spaghetti 700 lines ago.
Is there a reason why this should be core and not an add-on in the asset library?
I cannot answer this, please help?
This would improve the iteration time of web exports relying on JS a lot! However, is there absolutely no way that the JS could be rewritten in GDScript instead for this project?
@btarg no. not at the moment I am afraid.
Sidenote:
I started piecing together an godot-bare extension but quickly realized that I was out of my depth,
does anyone know if it's even be possible to hook existing JSBridge into a custom prebooted runtime via cpp GDExtension?
Like for WebViews, I really feel this should be an add-on as bundling a JavaScript runtime in core would increase binary size a fair bit and increase the attack surface for security vulnerabilities.
Besides, it won't work with everything you can do in JavaScriptBridge as it's not a web browser environment (think of it as Node.js versus the browser).
@Calinou yes a js runtime with node-api's, not browser. I understand it's a very powerful addition and i suppose the full weight of including such a plugin in your project would be ~50MB plus user-sources, i don't think it should be enabled by default.
my usecase
I've built a non-traditional multiplayer game that uses DHT/Swarm for connections and world state processing.
I use Godot to drive the core logic and alter the world state, mostly because I enjoy working with godot.
Currently the only runtime that supports the full game features is pears/keet but as i mentioned previously, the wasm compilation + patching makes development painfully slow. I could ditch godot and pears in favour of a terminal-ui and run vanilla node-js, but that's like the last way out.
If I could toggle the JSBridge to bridge to something like bare/bun/node/deno in standard builds, I'd be able to cut iteration time and release native builds for desktop and even mobile. Again I'm mentioning 'bare' because it's cross device compatible/embeddable and somewhat minimal.
I'm afraid i can't accomplish this myself, suggestions appreciated.
Could a system web-view be used for this instead of packaging a runtime? The majority of operating systems provide external browsers you can pull up and embed into native apps. It shouldn't affect security, as a huge amount of apps use these for logins (including the Bitwarden password manager). (Letting users add web views into their games could also be handy but thats beyond the scope of my comment)
- Windows 10 and 11 have web-views built into the OS via Edge, allowing apps to pull up a web browser (for logins, etc) without including a web browser in their binary.
- Mac and iOS most definitely support it via Safari.
- Linux supports it as well but I'd imagine it's a bit more tricky.
- Android has an entire web browser process specifically made for web views (Android System WebView)
Some frameworks such as Tauri implement web-views as a way to replace integrating browsers in apps (Electron 🤮), and Tauri works on all desktop and mobile platforms.
Maybe a new "run web" button could be added? If the platform you're running the Godot editor on doesn't support web-views the editor could just gray it out.
@FlooferLand Um. thank you for the input.. But the system web-view does not have node-api's, I would like to plug Godot's Javascript Bridge into a headless runtime when godot is running natively (not in browser) instead of the bridge just being disconnected.
Like this proposal is about adding a runtime (backend) not a webview (frontend). :/