BabylonNative: the same Babylon.js JavaScript outside the browser

One JavaScript codebase, five native platforms

The stated goal is narrow and ambitious at the same time: to allow the same JavaScript that powers Babylon.js applications on the web to work identically in native applications on Windows, macOS, iOS, Android and Linux. What that buys a team is reuse. If the scenes, the glTF assets, the material setup and the XR session logic already exist in JavaScript for a browser product, the ambition is to take that code to a headset, a desktop installer or a mobile app rather than port it to a native engine's API. The project describes itself as a collection of technologies intended to bring the power and flexibility of Babylon.js to cross-platform applications beyond the browser. The audience is not a game studio starting from nothing, it is a web team with existing Babylon.js content that needs to escape the browser tab.

Where the C++ sits: Core, Plugins, Polyfills and Embedding

The repository layout shows how the work is split. Core/ holds the native runtime, Plugins/ holds the platform specific pieces, Polyfills/ holds the implementations of browser APIs that JavaScript code expects to exist, and Embedding/ holds the way the runtime is hosted inside an application. Dependencies/ carries third party code, Apps/ holds the sample applications, Install/ the installation scripts, and Documentation/ the guides the README links to. A CMakeLists.txt at the root drives the build, with .clang-format for the C++ style and nightly.yml for the nightly build definition. The polyfill layer is the conceptual heart of the project, since the whole point is that unmodified Babylon.js code expects window, document, requestAnimationFrame and a canvas, and Babylon Native has to supply something for each of them in a native process.

The support matrix is the honest part of the README

The README spends most of its length on what does not work, and that is the most useful section for an evaluator. Fully supported are the core pieces: 3D assets including glTF and OBJ, animations, behaviors, cameras, gizmos, materials, meshes, lights, physics, scenes, shaders, sprites, textures loaded from PNG or JPEG, and XR. Partially supported are environment textures with only the .env format, GUI with text rendering marked experimental, input with only single pointer support, instancing limited to thin instances, some post processing, and media devices such as webcams, which are experimental. Listed as not yet supported are audio, serializers, particles, and texture loaders such as KTX and DDS. Listed as having no plan to support are the Inspector, the Node Material Editor, the GUI Editor, the Performance Profiler and 2D Controls, because they depend on HTML features outside the scope of the project. A team whose feature set includes particles or audio has to design around that.

Eight build paths, and where the instructions live

The README does not contain a single build command, and that is not an omission so much as a pointer. All the building instructions are in BUILDING.md, which the Quick Links section breaks down by host and target combination. The list is worth reading on its own, because it shows the project is not one build but several: building on Windows 10 targeting Windows Desktop in Win32, targeting the Universal Windows Platform, targeting HoloLens 2, building on macOS targeting macOS, targeting iOS, targeting visionOS, building on Windows targeting Android, and building on Ubuntu targeting Linux. There is also a section on selecting the graphics API, which matters when your target list includes a headset and a phone. The home page for the project is at aka.ms/Bnative for an overview. Beyond building, the documentation folder carries guides on when to use Babylon Native, the components, extending it, the build system, continuous integration, Android emulator tips, debugging JavaScript on Mac and iOS, debugging iOS and macOS rendering with Xcode, and how to consume JavaScript code.

Public preview, and a contract that can still change

The Project Status section is where a decision gets made. Babylon Native is currently available as a public preview in source form only, which means there is no binary release to download and you build it yourself. The README adds two warnings that deserve to be read as constraints rather than caveats. Many features are supported and functional, but others are under active development. And the project is not at the point where updates are fully backward compatible, so the contract for consuming Babylon Native can still and probably will change. That second sentence is the one to plan around. If you intend to ship a native application on top of it, your integration surface, however small, is exposed to churn. There are no GitHub releases at all, so version tracking has to come from the source tree and from the nightly build rather than from tags.

Licence, security reporting and how the project is built

The licence is MIT, with a LICENSE.md at the root and a NOTICE.md beside it, so using the code in a commercial application carries the standard MIT obligations and nothing more unusual, though NOTICE.md is the file to read before shipping. Security issues and bugs are reported privately by email to the Microsoft Security Response Center at [email protected], with a stated response within 24 hours and a follow up request if no answer arrives. That routing reflects where the project sits inside Microsoft. The build story is visible in the badges rather than the prose: a GitHub Actions CI workflow for the repository, and a separate nightly build on Azure DevOps against the master branch. Continuous integration is documented separately, and the team stories collected in the README, including write ups on audio support, skinned mesh problems and a backstage tour of the project, give a reasonable picture of how the work is organised.

The alternative: a web view instead of a native runtime

The obvious alternative to compiling Babylon.js to native is to keep it in a web view. A native shell embeds a WebView, loads the same JavaScript and the same assets, and you get a native binary for the store or the installer without touching C++, without polyfilling browser APIs and without giving up any feature the browser already supports. The trade-off is exactly the one Babylon Native exists to remove: you are inside a browser engine again, with its own process, its own memory model and its own restrictions, and on a platform that does not ship a modern browser engine at all, that option does not exist. The native route buys a real application with its own rendering path and platform integration, at the price of building the runtime yourself and living with a preview-stage contract. For a headset or a native app on a platform without a usable WebView, only the native route remains, and for that case the README's support matrix, rather than the feature headline, is what should drive the decision.

Editorial conclusion

BabylonNative suits a team whose web product is already written in Babylon.js and now needs the same scenes, assets and shaders to run on desktop, mobile or a headset without rewriting them in a native engine. Skip it if your application needs audio, particles, texture loaders such as KTX or DDS, or the inspector and node material editor, since the README lists those as not yet supported or out of scope entirely. Before adopting, read BUILDING.md for the target combination you need, since the project supports eight distinct build paths, and plan for the preview status, because the README states the contract for consuming Babylon Native can still change.

Frequently asked questions

Official sources

1. BabylonJS/BabylonNative on GitHub
2. Issues
3. License: MIT
4. README