Babylon 10 Poll

Announcements
1

Hey team!

Please read that blog and come back here to vote :slight_smile:

Should we break back compat in Babylon 10

  • Yes but only if the perf improvement is massive
  • No this is important for me or my team to keep protecting it
  • Don’t care
0 voters
9 Likes
2

I am going off of the assumption that the “yes” option has the clause of being massively beneficial in general. That could include performance, as well as bundle size, maintainability / complexity, etc.

3 Likes
3

I vote yes but admittedly if Safari never picks up webgpu that’s the one thing that could make it tough for Frame. Otherwise - absolutely yes. It does seem like Safari is getting the webgpu wheels turning a bit though…

1 Like
4

I am for. If it can reduce file size and improve performance, I see no reason to object to it. Performance matters.

1 Like
5

I voted “I don’t care” because I honestly think that breaking changes every ten years is really acceptable. In fact, it’s a great idea!
Secondly, I will ALWAYS welcome performance improvements, even if it means changing a bit of code. Bundle size is just as important, I know from several threads I’ve started here on the forum that my compiled code could be much lighter but it can’t be because of backwards compatibility. So it would be a great relief :wink:

5 Likes
6

I voted “I don’t care” only because it’s one time in 10 years :sweat_smile: but I really care and I think it’s one of the strongest advantage of Babylon…I accept the fact that Babylon’s team has to do it at one point and I will make the ‘effort’ to update my code base too !

7

So far we are only thinking about it and I want to present to the community a CLEAR and engaging reasoning behind each breaking change

6 Likes
8

I have absolutely no doubt about that ! It’s just amazing you did not break anything in 10 years :exploding_head:

9

IMHO it’s ample warning, is needed, and if well documented, it’ll be of potential huge benefit to the community and project going forward. Dare I say it … “Babylon TNG” - apologies to @Deltakosh for mixing my sci-fi metaphors :wink:

1 Like
10

I voted yes,
It would be great for the engine to be cleaned up a bit, deprecated/moved functions for example, all leave unnecessary bloat and complexity over time.

11

Can’t agree more!!

12

The poll and blog is a little vague. I’m curious as to what is meant by:

a) moving to a webgpu centric design? Are we assuming that webgpu is the de-facto standard going forward? In other words, all webgl based visuals will now reside along webgpu versions in parallel? Or are you providing webgl as an automatic fallback when webgpu is not supported, ie, BABY10 auto-detects user device and the dev does not need to code 2 versions of visuals?

My concern here is that webgpu is not as flexible as webgl visuals, at least as of writing. So depending on BABY10 architecture, I would like to maintain back compat to keep as much of my user-base as possible. (case in pt: I have been mulling over upgrading to http3 for over a yr now for the same reason)

b) if you are breaking back compat as part of code cleanup/deprecations, due to necessary improvements/better security/perf etc, there won’t be complaints. But if you are breaking because of a shift in advancements, its an endless race. ES6 was a huge rewrite. Webgpu is overkill for mundane applications. Come webgpu2/<insert another tech up, say, AIWebGPU> and we’d be breaking again.

3 Likes
13

I voted “don’t care”, but not because I don’t. I don’t think it should only be done for performance. There are even sensible defaults that are not defaults - to support backwards compatibility.

I love the one I discovered this week as an engine option loseContextOnDisposeSearch. The comment in the documentation:

It's false by default for backward compatibility, but you should probably pass true

From a perspective of defaults alone (like even antialias) I would make a version that’s not backwards compatible.

Many of the functions could be cleaned up a lot, because the “options” parameter was added after and the methods are overloaded.

To be fair - the team has done an outstanding effort and job with extending the API, but that was being constrained by maintaining backwards compatibility. I’ve had a few PRs to maintain backwards compatibility - it’s really important for external NPM libraries that use babylon.js. I fully support an occasional breaking changes version as you describe in your medium post. :smile:

3 Likes
14

I agree. Technology needs to be advanced and experimented. Babylon’s package is too large and needs to be cleaned up

15

Voted yes. I’m a huge fan of your backward compatibility, but I think this is very reasonable and framed absolutely in the best way possible. Performance and loading speed is more important than ever. 3D experiences will become more and more prevalent in the coming years and requirements are going to evolve dramatically, so you need to the able to steer the engine in the right direction. DX for the core team and contributors should also be taken as an advantage in the future proofing of the engine. And last but not least: you have been excellent in taking the helm of this community and have clearly earned our trust. I will continue to trust your best judgement.

1 Like
16

Yes, yes, yes, please do this :fire:

1 Like
17

My only concern is that there are too many great Playgrounds created so far; it would be great to select the version (probably 7.0) before the new major release. Besides that, I support this and voted “Yes.”

18

Great if some performance improvements come with that change, but for me the biggest opportunity would be to address the quirks of the current API (e.g. the Frenglish :slight_smile: :fr:), which would eventually improve developer experience and further facilitate adoption by new devs.

Thanks for all the great work!

19

I was going to vote no, because I really think the backwards compatibility is such a beautiful thing :smiley: It’s also a pretty common to think “I will just remake it all and it will be better” only for it to have flaws in other places (I think everyone has fallen into that trap before).
But having read the blogpost, just breaking it for the move to webgpu, and only if there’s actual massive benefits. That seems like it would be worth it. And this also seems like a change that isn’t taken lightly.

I also really appreciate that we get the opportunity to weigh in, I really love this project :smiley:

1 Like
20

I voted yes but if WebGl 2 still will be supported. Because as I know on linux webgpu still doesnt work. Also dont know implementation status on headsets (Should be work because they run on Android) but I didnt check

1 Like