Machine readable API description

Hey folks, babylonjs noob here. I have a complex golang program to which i am adding a web graphical front end. I have made some progress using the bindings here: GitHub - gmlewis/go-babylonjs: Experimental Go binding to Babylon.js using WebAssembly. and using golang’s ability to compile to wasm. The author of those, however, has stopped developing them, and I would like to make some changes (improvements with luck) including bringing them up-to-date.
I was wondering if there is a machine-readable version of the api docs somewhere I could use to regenerate bindings? The linked bindings use web scraping, which I would prefer not to rely on.
Thanks in advance,

Hello and welcome to the Babylon community! Pinging @RaananW

Hey! Welcome to the forum :slight_smile:

Are you referring to the Babylon API docs? What exactly do you need? a json of babylon’s core package’s codedoc?

Yes a json file with the same content as the auto-generated API website would be great! :slight_smile:

The code here: go-babylonjs/cmd/docs2go at master · gmlewis/go-babylonjs · GitHub currently parses html (from ? – looks like it has moved) to get that data, so a direct json would be very helpful.


Andy :slight_smile:

We generate HTML, because this is what we serve. The same pass we run can be executed locally - we un tsdocs on our declaration file for the UMD package(s). So this can be done locally, systematically without the need to parse HTML. If you want the parameters used I will be happy to provide them!

1 Like

Yes please! The script and params would be most helpful! :slight_smile: Or point me to them in the repo if there :slight_smile:

Sure! this is the function that generates our docs (for now) - Documentation/typedoc.utils.ts at master · BabylonJS/Documentation (

Awesome :sunglasses: thanks!

1 Like

What about using the typings file? I use that to generate a renderer. I’m using another project that generates code if you are interested

This function is downloading the typings file and generate typedoc using it. I am just not 100% sure what the use-case is, so i’m just happy to answer questions :slight_smile:

Typings file – sure (?) I want to generate a complete set of bindings for golang, so need api, params, types etc :slight_smile: Also constants. :slight_smile:

I don’t know which way would be best way forward, but you can from the typings certainly generate JSON as a potentially intermediate step. I haven’t worked professionally in golang for a few years now - I know the marshaling/unmarshaling can be a bit of effort for passing around dynamic args - whereas javascript is quite forgiving.

This is the file I use to parse the @babylonjs/core and @babylonjs/gui libraries.
react-babylonjs/generate-code.ts at master · brianzinn/react-babylonjs (

In v4 (next major version) I will be splitting out the way things are currently working and switching to a dynamic registration to help with tree shaking and to do that will switch even more towards JSON structures and dynamically generating the diff logic in the client. Not a concern for you that last part, but maybe we could split off a shared side project that generates a consumable JSON? I’ve already considered that and that’s what I will do when I add support for other @babylonjs/* libraries via dynamic registration. I think I’ll need to add the class prototype to support dynamic creation, but anyway that’s one way your interests would likely differ in the creation of a shared library.

That project is already generating some JSON - here you can see, for example, the constructor parameters (CreateInfo static prop) for the TransformNode ( react-babylonjs/generatedCode.ts at master · brianzinn/react-babylonjs (

 * A TransformNode is an object that is not rendered but can be used as a center of transformation. This can decrease memory usage and increase rendering speed compared to using an empty mesh as a parent and is less complicated than using a pivot matrix.
 * This code has been generated
export class FiberTransformNode implements HasPropsHandlers<FiberNodeProps> {
  private propsHandlers: PropsHandler<FiberNodeProps>[]

  constructor() {
    this.propsHandlers = [new FiberTransformNodePropsHandler(), new FiberNodePropsHandler()]

  getPropsHandlers(): PropsHandler<FiberNodeProps>[] {
    return this.propsHandlers

  addPropsHandler(propHandler: PropsHandler<FiberNodeProps>): void {

  public static readonly CreateInfo = {
    creationType: 'Constructor',
    libraryLocation: 'TransformNode',
    namespace: '@babylonjs/core',
    parameters: [
        name: 'name',
        type: 'string',
        optional: false,
        name: 'scene',
        type: 'BabylonjsCoreScene',
        optional: true,
        name: 'isPure',
        type: 'boolean',
        optional: true,
  public static readonly Metadata: CreatedInstanceMetadata = {
    isNode: true,
    className: 'FiberTransformNode',

The important part about the constructor is that I have the arguments ordering and if they are required.
For example - I’ll get something like this:

  <transformNode name='node-name' ... />

I’ll take in that name parameter and new up the instance:

// I take the 'scene' that I track and pass it in as well.
... = new TransformNode('node-name', scene, undefined);

I’d have to look more at the project you are referring to, but anyway that’s one way at least to get to JSON from the typings.

Hi Brian, I would certainly be interested in contributing in a small way to a side project to produce JSON api specs as a basis for generating language bindings. I would also be happy to contribute any (worthwhile) golang bindings I generate for my own use, though I can’t guarantee much since the focus of my effort is on the resulting app, not only the bindings.
For now, I’ll try cloning the repos and running the tools you mention.
Andy :slight_smile:

Can you describe a structure in JSON for you to generate bindings - I can use that as a starting point. I have all the constructors in JSON, while the properties I have generated code/methods to update their diffs (so i send through primitives, Vector3, Color3, callbacks, etc), but I can describe those in another way - probably purely in JSON, but it may be helpful to see props as types. ie: instead of { x: number, y: number, z: number} - it will be helpful to know it’s a Vector3?

One important thing is the class hierarchy of babylon.js class dictates inherited properties/methods - not represented as easily in JSON.