Even frontend is pure JS instead of Wasm. It really is ironic...
e comparison isn't quite apples to apples.
Launcher vs Game Engine: A launcher is a native desktop application that needs to handle system-level operations (file management, updates, process spawning). For that use case, Tauri/Rust provides a smaller binary, better memory footprint, and native performance - all important for something that runs alongside your game. Electron bundles an entire Chromium instance just to show a download button.
Why Node.js for the server? Because for a
game server, the bottleneck isn't CPU-bound computation - it's I/O operations (network packets, database queries, real-time connections). Node.js excels at this with its event-driven, non-blocking architecture. It's the same reason Discord, Trello, and many real-time applications use it.
Why vanilla JS on the frontend instead of Wasm? Because the rendering is done via HTML5 Canvas, which is already hardware-accelerated. WebAssembly shines when you need heavy computation (physics engines, video encoding). For a 2D sprite-based game with tile rendering, vanilla JS performs just fine at 60fps. Adding Wasm would introduce complexity without meaningful performance gains for this specific use case.
It's not about "Rust good, JS bad" - it's about choosing the right tool for each specific problem.
Just to remind you, this was an existing project; I wasn't going to redo it because there's no need.
Over the last few years I've worked on an open source NodeJS OT Server and HTML5 client. Everything is written from scratch and relies a custom protocol based on websockets, so it is not compatible with any existing servers or clients. It remains a work in progress that will most likely never be completed. The source code is available here and instructions on how to run the server are included in the README:
GitHub - Inconcessus/Tibia74-JS-Engine (https://github.com/Inconcessus/Tibia74-JS-Engine).
Currently the server loads the 7.4 map that is released
here. Many features are...