Support JavaScript

[paulocoutinhox]

Hi,

I believe Axmol should consider moving away from Lua and adopting JavaScript as its primary scripting language.

While Lua has been used in several engines and platforms (for example Roblox), JavaScript is far more widespread and has an undeniably larger developer community. It is much easier to find developers who already know JavaScript compared to Lua, which would immediately lower the entry barrier for new users and attract a broader audience to Axmol.

Another important factor is the massive ecosystem of JavaScript libraries and frameworks. With the widespread adoption of Node.js and the modern JavaScript community, developers already have access to millions of open-source packages that solve common problems — from networking and physics to AI and advanced UI features. By supporting JavaScript, Axmol could leverage this huge ecosystem and allow developers to integrate existing solutions directly into their projects, instead of reinventing the wheel.

This also means better collaboration with the broader tech world, since JavaScript is one of the most used languages globally, across web, mobile, and desktop development. It would enable Axmol projects to be more flexible, future-proof, and easier to integrate with external tools and services.

We can’t really compare the number of people who know JavaScript versus Lua — JavaScript simply dominates in adoption and developer availability. Instead of just adding JavaScript alongside Lua, my opinion is that Axmol should definitively migrate to JavaScript. This would not only modernize the engine but also ensure its relevance in the broader developer landscape.

[grif-on]

Personally , i would like to have JS instead of LUA out of the box in axmol .

But i think deprecating LUA in favor of JS would be too radical . (While maintaining them both is too tedious for axmol core maintainers .)
First of all - amount of work that such replacement/addition would take is quite huge .
Second - LUA was been part of axmol/cocos2d-x community for a long time . There is definetely a good amount of peoples in axmol and cocos2d-x communities who prefer LUA despite its drawbacks .

Imo , the best way is to make an unoficial fork of axmol with JS support . Gather all interested in it ussage/development peoples "under it" . And when it gets to actual "out of box" quality , add mention of it in axmols wiki/readme as "thirdparty scripting bindings" .

We already have one enthusiast who tried to make a fork with JS bindings https://github.com/remtori/axmol-js (WIP) .

[antn9x]

Great, I am waiting for runnable version of axmol-js.

[antn9x]

@remtori can you continue this work, I can help to test.

[paulocoutinhox]

With JavaScript support we can use libraries like Colyseus to make multiplayer games:
https://colyseus.io/

We can understand how many people use LUA with Axmol, maybe is fewer people.

[antn9x]

I also want to use js over lua because of its ecosystem. It would help axmol's user base significantly if it could be combined with js.

[aismann]

Perhaps this will help you achieve initial results more quickly (not tested):
Building a Game with React Native and Axmol Engine

It would be great if someone could show a working example.

[paulocoutinhox]

Cocos2d-X already have JavaScript support, we cannot bring it?

Ref: https://www.cocos.com/en/cocos2d-x

[aismann]

Cocos2d-X already have JavaScript support, we cannot bring it?
Ref: https://www.cocos.com/en/cocos2d-x

Here is "another" repository:
https://github.com/cocos2d/cocos2d-html5

[antn9x]

I still used cocos html5 and write my own types d.ts: https://github.com/Safe-engine/cocos-html5-ts

[antn9x]

Can we make a simple binding with QuickJS? https://github.com/bellard/quickjs

[paulocoutinhox]

Here are the key V8 vs QuickJS differences specifically for using JavaScript as an external scripting language in the Axmol game engine 🎮

Build size and footprint
• QuickJS 🐜: tiny runtime, very small binary and RAM usage. Great for mobile builds and faster CI.
• V8 🐘: large binary, extra deps (ICU, snapshots), higher RAM. Heavier app downloads.

Startup and hot reload
• QuickJS ⚡️: very fast startup; great for hot-reloading scripts during dev.
• V8 🔥: slower cold start (initialization, snapshots). Shines after warmup.

Performance profile
• V8 🏎️: JIT + optimizers = best throughput for CPU-heavy gameplay logic (AI loops, pathfinding).
• QuickJS 🚗: interpreter speed; fine for gameplay glue, entity scripts, UI logic. Not ideal for super-hot loops.

iOS and JIT constraints
• QuickJS 🍏: no JIT required, works smoothly on iOS codesigning/sandbox rules.
• V8 🧩: needs jitless mode on iOS or special entitlements; adds complexity and may reduce the perf advantage.

Android and toolchains
• QuickJS 🤝: easy to cross-compile for arm64/x86_64; fewer build steps.
• V8 🛠️: complex GN/depot_tools build; larger NDK output, longer CI times.

Embedding in Axmol (C/C++ API)
• QuickJS 🧷: simple C API; straightforward to expose Axmol objects (nodes, input, audio) as JS functions/objects.
• V8 🧶: powerful C++ API (Isolate/Context/Handles); more boilerplate to bind Axmol types, but great control and safety patterns.

Bytecode and packaging
• QuickJS 📦: can precompile JS to bytecode and ship as assets for faster load and obfuscation.
• V8 🧊: uses snapshots and cached data; setup is stronger but more involved.

GC behavior and frame time
• QuickJS ⏱️: smaller heaps, shorter collections; easier to keep GC pauses under frame budget if scripts are light.
• V8 🧮: advanced GC with tuning, but bigger heaps can mean noticeable pauses if not configured; requires profiling.

Determinism and scripting model
• QuickJS 🎯: single-threaded runtime is simple; easier to reason about frame determinism.
• V8 🧵: isolates and worker contexts enable parallelism; great, but more moving parts.

Debugging and tooling
• V8 🧰: mature DevTools protocol, profilers, heap snapshots; excellent for performance hunts.
• QuickJS 🔎: basic debugging; you’ll rely on custom logs/asserts and lightweight bridges.

Ecosystem surface
• V8 🌐: closer to browser/Node semantics (though you’ll still implement your own Axmol API).
• QuickJS 🧭: clean ES spec support without Node extras; you control the host APIs tightly.

Licensing and maintenance
• QuickJS 📜: MIT, minimal maintenance burden for a game team.
• V8 📜: BSD-style; larger maintenance/upgrade effort across platforms.

Security/sandboxing
• Both 🔐: you’ll sandbox by controlling what Axmol exposes. V8 has mature context isolation; QuickJS keeps it simple by default.

What this means for Axmol use cases

Pick QuickJS if… 🪶
• you target iOS and Android and want painless builds
• you need small APK/IPA size and fast startup
• your JS drives gameplay glue, state machines, cutscenes, UI, tweens
• you want easy hot-reload during iteration

Pick V8 if… 🚀
• your JS will run hot paths (heavy AI, physics helpers, ECS loops)
• you need deep tooling (profilers, heap snapshots) to squeeze perf
• you accept larger binaries and more complex multi-platform builds

Practical tips for Axmol integration

QuickJS workflow 🧩
• precompile scripts to QuickJS bytecode at build time and load from Axmol assets 📦
• keep one JS runtime per scene or game instance; expose a minimal Axmol API surface (timers, input, node transform, audio, resources)
• schedule GC after loading screens or during calm frames to avoid hitches ⏳
• implement hot-reload by reloading modules and re-binding entity scripts on the next frame 🔁

V8 workflow 🧱
• use a single Isolate with per-scene Contexts; precreate a snapshot with your bindings to cut startup time 🧊
• enable jitless on iOS and tune flags on Android; profile with DevTools to pin down hot functions 🧯
• batch object creation and minimize cross-boundary calls between C++ and JS in tight loops 📉

Rule of thumb for most Axmol mobile games 📱
• QuickJS is usually the sweet spot: tiny, fast to boot, easy to ship, great for scripting layers.
• Switch to V8 when profiling shows JS is the bottleneck and you truly need JIT-level speed.

[lee-eojin]

I think Lua's lightweight footprint and ease of embedding still make it better suited for game engines where mobile performance is critical. A full migration would mean losing all existing Lua users and consuming massive dev resources. I'd argue a phased approach is probably more practical than a complete switch.

[paulocoutinhox]

Yes, Lua was created for this. As embedded language, it is fantastic.

The JavaScript is more a way to bring more developers and be easy to create games with all JS libraries created.