The Babylon Chronicles: A Babylon Podcast

Hey everyone! We’ve been quietly working on something behind the scenes that we’re incredibly excited to unveil to everyone.

We’ve officially started a Podcast!!! Yup that’s right! @Deltakosh and I will be hosting a regular podcast dedicated to taking a look at the inner workings, discussions, and shenanigans involved with making this incredible platform.

Our hope is that this podcast will serve as a fun and engaging inside look at the day to day of what it takes to bring Babylon.js to life. We also hope it can serve as another platform to help get the word out about the incredible work being done by all of you in the community.

You can listen to the inaugural episode on Spotify and Apple Podcasts or even watch the video version on YouTube.

It is our sincere hope that you enjoy this new inside look at the making of Babylon.js and that this serves as a better chance to get to know more about the team of people that dedicate their time and effort to bring it life.

We’d love to hear your ideas of topics you’d like to hear about in future episodes, so reply with ideas!

As always, you all rock!


Nice!!! Love it.


That was really fun. I had an awesome time watching this. :smiley: To hear about the story of the debut and deltakosh’s redemption and revival was very entertaining but also a learning for those who (like I eventually did at some point in my career) take their small success with a little bit too much arrogance. :stuck_out_tongue_winking_eye:
I had to do my own redemption so this kind of rings a bell for me :wink: You (and I) can laugh today when you think back… but at the moment, you must have had a hard time.

Else, this ‘intimate’ podcast format is really pleasant, I think. It kind of makes me (us, the community) feel even closer to you Guys. Last, I gotta say, that @pirateJC your speaker skills continue to impress me. Keeping with that rythm and pace for 30min just perfectly. Congrats (to both of you). A very nice first entry for what I hope will become a ‘must-see’ serie. :clapper: Personally, I’m eagerly awaiting episode two. GJ,


Ok. I have one ‘high level’ for you that I think could be interesting for episode 2. I’d like to extend the ‘discussion’ on one of the pillars of BJS: Backwards compatibility. There have been some discussion in this very forum about where to set the limit between compatibility and innovation. Read tech improvement but also consistency and following ‘norms’ (for devs and eng). There are people (essentially software devs/eng) who stated that BJS is becoming somewhat ‘disorganized’ and is eventually lacking ‘simplicity’ (their vision of ‘simplicity’) partly related (I think) to backwards compatibility but also (I think) community project building. Where obviously, simplicity is yet another pillar of BJS (in my opinion). I believe it’s hard to keep with this balance and I (personally) would love to hear about your thoughts on that. As always, my opinion only and a simple suggestion. Meanwhile, have a great day :sunglasses:

Thanks Gents :wink:

I watched it on youtube as im not using apple or spotify so thanks for making it available there for us older guys haha

Great to hear the origin story of the engine and I look forward to hearing more from the team.

1 Like

I watched it on Youtube also - loved it!

You will probably like this blog post from @RaananW:


Thanks for the link. Indeed, liked the reading :clap: Looks like this is pretty much all said here. So, we’ll have to find another topic for episode 2 :thinking:

…May be the normal continuity of this could be synergies and dependencies? How BJS sees the future in the MS-ecosystem? We’ve had a first experience with Havok and it looks like Frames is also becoming a closer ‘friend’ or ‘sister’ to BJS. And then, there’s also the relation to/with the less-friendly (essentially browsers) partners. Note that I didn’t mention any name :wink: Typically, I believe the case of the audio topic is a very comprehensive example that impacts quite a number of devs and users - Alongside the more general topic of browser’s ‘policies’, also extending to UX. Read the marketing-side of UX.

Yet just another simple suggestion of mine. Take it or leave it. I’ll be back if I can think of something else suitable for episode 2. Meanwhile, have a great day :sunglasses:

1 Like

Loved it and I love the idea! Great work @PirateJC and @Deltakosh :sunglasses::+1:

I would love to get examples of that. What backward compatibility things are not helping with simplicity? Because as we open the road to ESM, it could be great see how we can shape the ESM API to be simpler

1 Like

Thank you guys for this. Loved it!

Every time I hear @Deltakosh referring to backwards compatibility I get goosebumps. This was for me, the absolute argument that made me start to use this wonderful tech.

As a solo game dev with code first approach ( I am definitively not a Unity, or in the web, a PlayCanvas target user). I do love to code and use beautiful code that can be reused as much as possible. And this, I can find here at ‘Home’ :heart: in the BabylonJS city!

Kudos to you all!

1 Like

Function signatures with a bazillion arguments :laughing:

1 Like

Do you feel there is a difference with objects instead of arguments? (Thing that we are doing now to be more future proof)

yes because with arguments every value is order dependent , so you have to explicitly pass in null values for arguments you dont want to set or use ( or to let the code trigger the default internally ) , also this order cant be changed for backward compatibility obviously. So then when you perhaps want to add something extra to the arguments , you are forced to have to add them to the end.

With a single options object , you only set what you want , null values will be null by proxy of not declaring them , so you not forced to set null. Order doesnt matter and adding extra values to the object in the future doesnt affect this logic at all and is backward compatible.

lets take the RawTexture constructor as example , with 11 arguments :

new RawTexture(data: Nullable, width: number, height: number, format: number, sceneOrEngine: Nullable<Scene | ThinEngine>, generateMipMaps?: boolean, invertY?: boolean, samplingMode?: number, type?: number, creationFlags?: number,
useSRGBBuffer?: boolean): RawTexture

the last 6 arguments are optional , but if you wanted to only perhaps explicity set the 11th argument , you are forced to have to pass in a bunch of null values to trigger the default behaviors of their optional nature , however those optional values are handled , or you have to know the defaults and set them if you wanted it to look better than having loads of nulls in there.


Completely aligned:)


:+1: :+1:

I spent most of last weekend helping my son run Minecraft mods. So got to experience the pain of no backwards compatibility recently. Where we needed to download the exact version and point number to run with a specific point number version of mc and then uninstall / reinstall each time we had a new mod. Which then worked only 20% of the time. it brings to light not having that worry with Babylon…

1 Like

I can go either way, but when there are a bunch of optional / default-able things, prefer interface typed options arg at the end. This argument can of course be optional as well.

1 Like