"The" Bevy Editor should not exist

Alternative title: towards a multiplicity of Bevy editors.

Bevy needs editing tools, but the assumption that this means building "The Bevy Editor" risks constraining our thinking and leading us to anticipate problems of the most maximalist integrated editor before we even ship any useful tools. A monolithic editor pattern emerges from specific architectural decisions: managed runtimes, controlled type systems, clear engine/userspace boundaries. Bevy made fundamentally different choices here: focus on ECS-driven design from top to bottom. These choices don't just suggest but demand a different approach to tooling.

The distributable editor trap

The requirement for a distributable executable creates cascading architectural problems. Other engines ship editors because they control both the type system and runtime, relying heavily on dynamic reflection and scripting. Bevy has specifically rejected scripting as a default pattern, instead favoring focusing on building the most productive ECS patterns possible.

Bevy does have excellent reflection in bevy_reflect, but it requires that types must exist at compile time to be reflected. We also have been developing the BRP which allows introspection and interaction with remote processes. These are both good tools that we should lean on and develop further. But there's a big difference between slowly opening up tooling so that it's able to be used remotely and designing an editor from first principles that is totally process isolated.

Ideally, developers shouldn't use "the" editor, they should compose their editor from the capabilities they need. This kind of modular design is what makes Bevy so great in the first place. In practice, we will likely have a "default" distribution of the editor to get people started, but this should be a starting point, a template and jumping off point to explore their own customizations of the editor.

Your editor configuration should be code in your repository. For example, the editor itself could be configured via BSN rather than opaque state of the last time the application ran and what panels you had open. Version control becomes meaningful when your editor is code. New team members build the exact same tools.

Not all games have the same needs for editing. While scene building is a major weak point in Bevy, there are some games that don't require this at all! Especially while we are in the early process of building out the editor, we should embrace experimentation.

ECS first

Starting with an in-process architecture for tools is the right approach. Your compiled game with editor plugins is your editor. This gives immediate access to all reflection data, direct component modification, and zero serialization overhead. More importantly, it uses the same patterns for writing editor code that we use in the rest of our applications.

This may not be enough for some games. Process isolation absolutely has tons of value: crash resilience, hot reloading boundaries, even running on different machines. These are totally real benefits worth pursuing! But starting there means solving complex distributed systems problems before we even know what tools we need. Over time, the BRP can enable out-of-process tools, and some tool authors may choose to start from that point.

But ECS-first editing tools require genuine research, not just implementation. We should not map hierarchical object models onto compositional systems. With full relations, ECS is closer to a logic programming system, essentially Prolog with entities and components (see Flecs). So instead, we should be asking questions like: What would a Prolog database explorer for games look like? How do you visualize queries over entity relationships? How do you debug system execution when systems are just functions over queries? These aren't implementation details... they're fundamental research questions we don't have answers to yet.

This research can't happen in a monolithic editor project. It needs experimentation, failed attempts, departures from convention, and most importantly time in the laboritory to cook. 👩‍🍳👩‍🔬

Conclusion: The pragmatist's path

We should ship tools incrementally that the deliver value, without worrying to much about the architecture for an editor monolith. For example, as a first step we should ship a world inspector plugin that will provide immense value to our users. We should focus on building bevy_ui and the bevy_feathers framework independently without getting too focused on specific use cases.

We should be empiricists and focus on incremental development over speculative design. We don't know what ECS-first editing really looks like yet and our users don't either. Pretending we do risks leading to committee-driven development that produce tools that at best are immature versions of our competetors and at worse fail to take advantage of the ECS-first paradigm.

My goal here is not to diminish the importance of contributors who are less comfortable writing code, especially Rust. It's deeply important to me that inclusive technology pedagogy consider these contributors when doing UX. But there must be a practical recognition that what differentiates Bevy is precisely it's focus on minimal code-first approach through the ECS. We shouldn't be gatekeepers but let's always keep in mind why we work on Bevy in the first place.

So while, from the perspective of community values, we should discard the arrogance that leads developers to imagine they are superior to artists, we should do that by embracing the ethos that we can draw in those artists and other contributors who want to deepen their relationship to the kinds of values we have as a community.

I strongly believe that Bevy can be a productive engine that appeals to multiple levels of technical skill and provide tools to support teams with less technical members, but we should be honest that those whose singular concern is to achieve low-code productivity should probably pick another engine better suited to that workflow, at least for now.