Subject: A Friendly Suggestion for Babylon Lite's Future Direction

[song_yu]

Hi Babylon Lite team,

First off, congratulations on shipping Babylon Lite — it’s genuinely exciting to see a WebGPU-exclusive, tree-shakable engine built from a clean slate. The performance numbers speak for themselves, and it’s clear you’ve built something special.

I’ve been following Mystral Engine (mystralengine · GitHub) closely, and I couldn’t help but notice how well it aligns with what Babylon Lite is already doing. Mystral Native is essentially a lightweight runtime that lets you run JavaScript/TypeScript games with WebGPU — no browser, no Electron, just a ~25MB native binary. It uses SDL3 for windowing and events, Dawn for WebGPU, and V8 for JS.

This got me thinking: has Babylon Lite ever considered going in a similar direction — a pure WebGPU native desktop path?

Here’s why I think this could be huge:

1. Leverage the massive frontend developer ecosystem
There are millions of frontend engineers who already know TypeScript and modern tooling. If Babylon Lite could offer a native desktop story alongside its browser story, you’d instantly tap into that talent pool. Game development would suddenly feel familiar to an entire generation of developers who’ve never touched C++ or C#.

2. Ditch the Electron bloat
Right now, shipping a web-based game as a desktop app usually means bundling a whole Chromium runtime (200MB+). Mystral Native showed that you don’t need that — you can have a lightweight native runtime that gives you the same Web APIs (WebGPU, Canvas 2D, Web Audio, fetch) but outputs a real native application. Babylon Lite, with its clean WebGPU-first architecture, seems perfectly positioned to do the same — or even better.

3. Compete where it matters
Three.js has been the default choice for web 3D for years. But Babylon Lite is already different — it’s WebGPU-exclusive, built for performance, and has no legacy baggage. With a native runtime, Babylon Lite wouldn’t just be competing with Three.js on the web — it could go head-to-head with Unity and Godot on desktop, and eventually Steam and beyond. And honestly? The web-first approach with TypeScript is so much more approachable for indie developers and small teams.

4. Future-proof with AI
AI is already changing how we build games. A lightweight, developer-friendly engine that runs everywhere — browser and native — with the same codebase seems like the perfect foundation for AI-driven content creation. Imagine AI agents generating Babylon Lite scenes that work seamlessly across all platforms. That’s the kind of ecosystem that could become the default for 3D content.

I know this is a big ask, and I totally understand that Babylon Lite’s current focus is on being the best WebGPU engine for the browser. But I also saw that the team is already working on Babylon Lite with Babylon Native and React Native, which tells me you’re already thinking about native platforms to some degree. Maybe a standalone native runtime — inspired by what Mystral Native is doing — could be a natural next step?

I’m just a fan of the project sharing a thought. Whatever direction you choose, I’m excited to see where Babylon Lite goes. Keep up the great work!

Best regards,
A Babylon Lite enthusiast

[Deltakosh]

This is clearly where we want to go with Babylon Lite Native
cc @BabylonNative

[bghgary]

Thanks for taking the time to write this. David’s short answer is exactly right: this is very close to where we want to go with Babylon Lite Native, and we are genuinely excited about how we plan to approach it.

The plan is broader than simply getting Lite to render in a native window. We are pursuing complementary paths: Dawn as the broad WebGPU reference, a projected-to-JavaScript path that can retain JavaScript application logic, and a pure-native path aimed at maximum performance with a familiar Babylon Lite API. The possibility of keeping one Babylon Lite architecture across the web, Babylon Native, and Babylon React Native without wrapping Chromium or maintaining a separate engine design for every platform is what makes this direction especially exciting to us.

There is already good evidence behind the Dawn path: Babylon Lite scene code has run through Babylon Native’s Dawn-backed WebGPU host on desktop and mobile. The pure-native solution still needs to be proven. We intend to build and measure it rather than assume that its performance, footprint, maintainability, and feature coverage will work out.

I also took a closer look at Mystral Native rather than treating it as a name-check. Its current early-alpha architecture has meaningful overlap with this direction: native JavaScript runtimes, Dawn or wgpu-native, SDL3, TypeScript transpilation, and headless capture. The current Windows QuickJS + Dawn executable is about 23 MiB, close to the figure you cited, while the V8 + Dawn executable is about 43 MiB, so the footprint depends substantially on the runtime configuration. It is a useful concrete example of this class of native host, although our work has different goals around the Babylon Lite API, renderer, and shared behavior across web and native.

For any path we eventually recommend, shared web/native visual validation and testing on real devices are requirements. We have not committed to recreating every browser API, a final platform list, distribution methods, AI-specific tooling, or a compatibility and release timeline. Those decisions need to follow measured results, and Lite’s size and performance priorities will continue to shape what belongs in the native host.

The work is still early. We plan to share a broader community update once both the Dawn route and a pure-native slice have enough public, reproducible evidence to explain the direction clearly. Thanks again for the thoughtful suggestion. It lines up closely with the future we are working toward.