I don't disagree, but Bevy has something going for it that most other frameworks don't - modularity. Not just in concept, but something that's proven to actuall

I don't disagree, but Bevy has something going for it that most other frameworks don't - modularity. Not just in concept, but something that's proven to actually work out well in practice. Tiny glade is a game that uses bevy_ecs, but doesn't use bevy's rendering crates at all. Personally I have several WIP PRs that implement alternative rendering paths (raytracing, GPU-driven meshlet + visibility buffer rendering) and nothing internal to Bevy really changes. For users, again nothing really changes, they just add a FeatureFooPlugin to their app and then use FooComponent or whatever and it all works. While individual crates/plugins might get bloated, Bevy as a whole will be fine. Users can choose to ignore those plugins, and use something else that works better for them. I would also like to point out that this is a game engine - by definition, they're bloated and complex beasts, and absorb every feature under the sun because _someone_ will have a use case for some kind of game. The key is how the feature bloat affects ergonomics. It's totally fine to have 1000 features, as long as you don't _need_ to interact with most of them unless you want to.