We went from “Yes but only if the perf improvement is massive” to something like “Yes and we also will rewrite the entire API”.
Breaking back compat once means extra work, right? Breaking the guarantee of back compat itself means even more wokr because now I need to guard against that. I have seen code out their using Babylon. I did not see unit tests in the repos. I also noticed calls to the Babylon api all over (no middle layer). If there is no TypeScript either, these repos are blind to breaking changes. Sure eventually it is a matter of trade-off: what do I get and what is the cost of extra work? So for sth like Houdini (aww could you imagine ) I probably would be willing to rewrite half of my code. But risking a runtime error for a change in some namespace?
Switching around a boolean default? This would be an absolute nightmare. How would I detect this (in a test; that I need to write now)?
Speaking of extra work: there also is someone on the Babylon team having to do that - rather than working on the critical bug fix or the next cool feature.
FYI, I deliberately wrote this post from a devil’s advocate perspective given the majority vote on yes. Personally, I mostly don’t care.
Yes! At least someone is with me!! I totally aligned with that view:) (Am I the devil??:))
Maybe most of the people do not realize that changing half of the engine will take the team offline for months but this will also be a freaking shitshow for a lot of users. I’ve already seen several here not even being aware of the methods we already flagged as deprecated.
I’m not ready to change the core engine for the sake of making it more pleasing to the eye:) if I do a change it has to be a fair trade off for everyone time: it has to come with a massive improvement.
Haha, my guy, if the intention was to inform people of the risks then you wrote the blogpost wrong To me this seemed like something that you guys have been carefully considering and now see an opportunity to try out. Doing this poll (with two ‘yes’ options and one ‘no’, also indicating you’re more positive than negative) to warn people in advance that it’s happening and why you are doing it.
If you’d described it in the blogpost as ‘a freaking shitshow’ I would not have voted yes
I read this as a Blender 2.8 kind of situation, where changes would be uncomfortable to get used to at first, but overall a big step forward.
It COULD be a shitshow:) it you are using TS, a linter or have a tons of tests that should be fine.
But I know the web developers:) every time we change a tiny thing we end up with a lot of questions even though everything is documented:)
Hence why I will be extremely cautious if we decide to break backward compatibility. Because I already know it will be a lot of work for us here in the forum and a lot of work for a lot of users on their codebase
I appreciate your perspective and we do need opposing views to think critically about the change.
I don’t think it was “we” (plural) that agrees with changing the API for non-performance reasons and I don’t agree with the entire API changing. Simply one person’s opinion only - and also not the entire API, but if we get to reimagine the API and throwaway the things that didn’t work out so well then I was simply saying that it’s an opportunity to do more than only performance improvements. Making the API friendlier and more intuitive for newcomers would be great. Lots of the API was also designed on a moving target like a changing XR spec and WebGPU didn’t exist when the API was created. Definitely if the API is holding back performance or growth even more reason.
Yes this is definitely an option. But I also wonder if we should not start fresh. Like we have a version 9 which is our LTS that we keep maintaining for bugs and we have a fresh new Babylon X with all the new features and a non-backward compatible API.
This way people can either stick wih the LTS and decide when they want to jump into the new pool.
There are times where things will break backwards compatibility especially if it enables WebGPU or 6dof video (e.g. spacetime Gaussian Splat and NERFs).
FTR, broken GLTF skeletons caused me tremendous waste of time. Took me a year to fix inverse kinematics, I’ve skipped the entire version 5 because of it.
There’s no drop-in code replacement, everything that used bones had to be changed to use transform nodes instead. Not even a readme that made sense.
From where I stand, your promise is long time broken.
But this effort is an actual improvement. Yes please, announce and discuss intended breaking changes, and/or provide old->new code snippets.
First thing is I didn’t want @Deltakosh to be alone voting ‘no’ . Although I believe I can suspect the reason why he did .
…and then the Second (which for me, is likely this exact same reason I suspected ) :
Backwards compatibility and overal ‘inclusivity’ and ‘reliability’ over time is a PILLAR of the framework. It’s part of the DNA . Means when touching these pillars that are the base for the building of ‘solid grounds’ for all the rest of it, One needs to be VERY CAREFUL …
Yet, I’m not saying: 10 years is a hell of lot in this first emerging and next growing tech. At some point, there are some milestones and hard decisions to be made. I only want to make sure we are not giving up on the philosophy while making this (necessary) adjustments to 1) remain competitive 2) expand and conquer.
Of course, as always, my opinion only … and until then, take care and have a great day
) I probably would be willing to rewrite half of my code. But risking a runtime error for a change in some namespace?
To me this seemed like something that you guys have been carefully considering and now see an opportunity to try out. Doing this poll (with two ‘yes’ options and one ‘no’, also indicating you’re more positive than negative) to warn people in advance that it’s happening and why you are doing it.
)
. Although I believe I can suspect the reason why he did 
.
) :
. Means when touching these pillars that are the base for the building of ‘solid grounds’ for all the rest of it, One needs to be VERY CAREFUL 
…
… and until then, take care and have a great day 
