Reactivity Proposal: In-place Reaction systems

[cart]

I've been experimenting with an alternative approach to reactivity that doesn't use "ghost nodes", "multiple interconnected hierarchies", or "templates". It looks like this:

#[derive(Component)]
struct MyList {
    entries: usize,
    title: String,
}

fn my_list() -> impl Bundle {
    (
        MyList {
            entries: 2,
            title: "My List".to_string(),
        },
        Node {
            flex_direction: FlexDirection::Column,
            ..default()
        },
        reactions![Reaction::new(
            |list: Com<MyList>, children: Com<Children>, mut query: Query<&mut Text>| {
                query.get_mut(children[0]).unwrap().0 = list.title.to_string();
            }
        )],
        children![
            Text::default(),
            for_each(
                |list: Com<MyList>| { 0..list.entries },
                |i| list_item(format!("index {i}"))
            ),
        ],
    )
}

fn list_item(text: String) -> impl Bundle {
    (
        Node {
            padding: UiRect::all(Val::Px(5.0)),
            ..default()
        },
        BackgroundColor(Color::srgb(0.4, 0.4, 0.8)),
        children![
            Text::new(text)
        ],
    )
}

Everything above has been implemented. Here is a video of for_each being used in practice. Note that I've added normal Bevy ECS logic to track and display the "elapsed time" of each list item to illustrate the lifetime (and statefulness) of a given entity / illustrate when it has been replaced:

2025-02-17.14-18-34.mp4

In broad strokes:

• Reactivity is driven by the Reaction component (which contains a "reactive system"). Reactions live on their own entity that relates to a "reaction target" entity using either the new ReactionTo/Reactions relationship (for reactions that react directly to the target entity) or the existing ChildOf relationship (for reactions that need to care about their position in the children collection)
• System has been extended to support "reactive systems"
• I've added generic functions that return Reactions that do specific things, such as for_each. for_each uses a reactive system to return an iterator over keys and a function that takes that key and returns a Bundle). for_each internally finds where it is in the parent's Children, and assumes the entities directly after it are its entities. When it comes time to update, it will only consider that slice of entities.

Pros and Cons

First, the reasons why I like this (these are also the reasons I've been hesitant to embrace other proposals):

1. It builds directly on the Bevy data model we already have without introducing too many new concepts. Entities/Components are data, relationships connect that data together, systems define behaviors on that data, we use the standard Children relationship, etc. Everything feels unified and crisp.
2. What you see is exactly what you get. No unexpected entities are created under the hood. No template system is needed to define these things. Things that look like components are components. The hierarchy definition data model and the user facing hierarchy access model are the same. There is no need to know details like "this input hierarchy produces this output hierarchy" or "I need to visit the children of entities with a GhostNode component when traversing a hierarchy").
3. By being restricted / principled about "reaction targets", and by using our System infrastructure, we make reading and writing data about as ergonomic as it can possibly be in raw rust.
4. Reactivity works seamlessly with normal Bevy code. If there is a "checkbox widget" that uses an is_checked boolean to determine if it is checked, you can directly mutate Checkbox::is_checked and see the results. I believe this property is extremely valuable.

Of course there are also downsides:

1. By default with this model, changes need to propagate entity-by-entity down the hierarchy. Each "step" is very ergonomic, but the more steps you need, the more laborious and costly it is. This is not inherent to the system (you can in theory write a reaction that reaches "down" the hierarchy). Its just that right now "reaching down" isn't particularly fun. Reactions do run after the initial hierarchy is constructed, meaning we can use identities to reach down the tree in a reaction (ex: an EntityPath, querying for a specific name, a specific component, a custom identity system, etc). We can build query tools that make it easier to resolve these identities. A templating system (such as BSN) could aid in defining (and maybe even directly resolving) these identities. For example, a template could see something like CheckBox { is_checked: #root->MyCheckBox::is_checked } and resolve it to a Reaction that lives on the #root entity, reacts to MyCheckBox changes, queries for CheckBox on the current nested entity, and assigns the value of MyCheckBox::is_checked. Not saying we need to use that API ... just an example.
2. Implementing in-place-child-entity-generating reactions like for_each requires more work / is more error prone, as it is essentially layering its own concept of hierarchy on top. I think this is the correct place to eat this complexity, as the alternative is foisting it upon people spawning or accessing entities. We will probably be able to count the number of these built-in implementations on one or two hands. We will likely also be able to count the number of users writing their own implementions on one or two hands.
3. It is possible to invalidate in-place-child-entity-generating reactions like for_each by inserting or removing entities in a spot that it "owns". In practice, I don't think this will be hit often as the "easy" way of spawning new children appends to the end of the list (which cannot invalidate anything). We can also build guard rails (ex: label owned entities with marker components so we can detect entities that are manually inserted in an owned position), and every implementation we are considering suffers from this category of problem to an extent (it is the nature of implementating reactivity in "userspace Bevy ECS").

While these downsides are present, I believe the benefits far outweigh the downsides. I am currently biased toward this approach over other proposals, with the disclaimer that this is still early stages and I have not explored every scenario yet.

Implementation Details

This implementation is composed of the following pieces:

1. Extending Bevy ECS Systems with optional additional metadata (source entity and target entity)
2. Adding some new system params that make accessing data on these entities possible:
   • Com<C>: returns a component C on the target entity (if one is configured).
   • Entity: this will be set to the "target entity" (if one is configured)
   • SourceEntity: this will be set to the "source entity" (if one is configured)
3. Extending SystemParam to include SystemParam::is_changed (and piping that into the new System::is_changed), allowing us to poll if a system (ex: one of its parameters) has changed since its last run.
4. Adding a new Reaction component, which stores a reactive System. This has a ReactionIndex required component, which uses an atomically incrementing index to determine the "order" of a reaction (credit to @viridia for this idea)
5. Poll is_changed on each update, in the ReactionIndex order. If a Reaction system has changed, run it.
6. Add a new ReactionTo/Reactions relationship. This is used when a reaction is directly modifying a target entity. Reaction, in its on_add hook, will first check if ReactionTo is present. If it is, that relationship target will be the "target entity" of the system. The Reaction entity will be the "source entity". If ReactionTo is not present, it will do the same thing with the ChildOf reaction. Supporting both is a key piece!
7. Add new generic functions that return "reactive systems" built for specific purposes, such as for_each insert_when, etc.

So far none of this directly touches on why this is an alternative to things like "ghost nodes" or "multiple interconnected hierarchies".

Next Steps

• Get my branch ready for others to play with (currently it is homed on a branch literred with other experiments)
• Implement more built-in Reaction-generating functions
• Port observers to relationships so we can experiment with UI interactions in this context
• Build out more widget types / use in more contexts to test the viablility and limits of this approach.
• Experiment with interfacing reactions with observable events (ex: Reaction::new(|checkbox: Com<Checkbox>, on_click: Triggered<Pointer<Click>>| {}).
• Consider making the ReactionTo relationship more general / sharing it with observers.
• Reactions and Observers could potentially be unified (either in part or in whole). There is certainly value in being able to send an entity-targeted-event and use Com to access a targeted component in the Observer. However Observers currently require Trigger<E>, which isn't something we want for reactions.
• Make "path resolution" / "reaching down the hiearchy" easier
• Investigate ways for a component to "require" a function that returns a Bundle. It would be very nice if we could auto-spawn the whole tree whenever some Widget component is spawned. This has obvious limitations, such as not supporting default-value overrides.

  #[derive(Component)]
  #[require_bundle(my_checkbox)]
  struct MyCheckbox {
      is_checked: bool,
  }
  
  fn my_checkbox() -> impl Bundle {
      (
          Node::default(),
          BackgroundColor(BACKGROUND_COLOR)
          children![
              insert_when(
                  |my_checkbox: Com<MyCheckbox>| my_checkbox.is_checked,
                  Node {
                      width: Val::Percent(100.0),
                      height: Val::Percent(100.0),
                      padding: UiRect::all(Val::Percent(5.)),
                      ..default()
                  },
                  BackgroundColor(CHECKED_COLOR)
              )
          ]
      )
  }

[alice-i-cecile]

I think both the name of Com and the use of Entity here are confusing. That can be revised though. On vacation but just leaving a quick note so I don't forget!

[cart]

I think Com has reasonable parity with Res, but I'm open to suggestions. I would like to consider something that uses Fetch / supports anything Query would, to avoid a bunch of individual Com<T> wrappers.

[viridia]

Random suggestions: This<T>, Me<T>.

[villor]

Maybe Dep<T> as in reactive dependency.

[CooCooCaCha]

Dep<T> seems a bit too general IMO.

Conceptually Com -> Component is pretty straightforward.

[viridia]

First, there's a lot to like here, but for the sake of brevity I'm not going to list all the things I am in favor of (although change detection on systems is a pleasant surprise), instead I'll get right to the critiques:

• I think that having for_each own all the entities after it is too limiting. Now, it's true that in the vast majority of cases a list box of, say, saved games will only contain iterated list rows - possibly with a special entry at the top for "new save". But I can't guarantee this will be true in all cases.
  • As an alternative, you could have bracketed entities: for_each_begin and for_each_end.
  • This is especially important in the case of if-statements. A common pattern is to have an inline "error alert" which only appears when you've made some error in an input form. This means that when an error is present, the if-statement has 1 child, if there's no error then there are zero children. There are many other cases where rows or columns within a flexbox are shown conditionally. Such conditions change the child indices of subsequent items. What happens if you have two if-statements sequentially? Or with a non-conditional node between them?
  • My editor in particular requires a "tab panel" layout, where the number of children may vary depending on which tab is selected.
• I was actually considering the option of having reactions take some equivalent of Trigger. This would just be an In param.
• I really think we need something better than function calls for template-like functionality, but that's orthogonal to this discussion I think. (Button has 10 parameters, too many for positional params. Worse, 50% of buttons only use one of those params, the rest are default). Also, like React components, it's very common in my framework for widgets/templates to do some initial housekeeping before setting up the actual visible output of the template.

More comments later as I think of them.

[viridia]

Admittedly an if or loop nested in a loop will be rare, but this won't be the case for nested ifs:

children![
    cond(
        |state: Res<State<GameState>>| state.0 == GameState::Paused,
        || cond(
            |saving: Res<IsSaving>| saving.0,
            || (
                Spawn(Text("Not Saving")),
                Spawn(CancelButton)
            )
            || Spawn(Text("Not Saving"))
        ),
        || ()
]

The outer if will have 0, 1 or 2 children, depending on the state of two resources. We can't assume that the number of contained entities won't change unpredictably.

We could get around this by having an explicit "end" marker. The "if" spawns two bracketing entities, one at the beginning and one at the end, where the first one contains the id of the second. The contents of the if goes between the markers. We can then do a find operation to get the index of both. This is slightly less efficient but I guess it's ok.

We're also going to need to expand the methods for manipulating related entities.

[viridia]

Thinking about this more (sorry for so many responses): I actually think your model breaks down with incrementally-updated for loops. The way iteration works in React and Solid is that it is able to preserve child hierarchies whose corresponding array elements didn't change - so if my input array goes from [1, 2, 3] to [1, 2, 3, 4] it doesn't regenerate all the children, it only inserts/removes/replaces the children corresponding to the changed array element.

However, my model doesn't assume the following things:

• That each iteration of the loop produces a single child entity.
• That each iteration of the loop produces the same number of children as other rows.
• That the number of children produced for each iteration is static - in other words, the individual rows can themselves contain dynamic control-flow nodes.

The way I solve this is by making not only the foreach loop a ghost node, but also making each individual row a ghost node as well. This allows the foreach to tear down and re-create individual rows without disturbing the content of other rows.

We can't simply store the child indices in the foreach component, because those indices may change. Ghost nodes, once generated, have entirely stable child indices, but their contents might not - nor will the "flattened" output have stable indices.

To do this using the marker/sibling approach we would have to bracket each output row with a begin/end marker, and then determine the child index via search. This quickly turns into an N^2 problem.

[cart]

I do agree that scenarios like nesting ifs inside of for_each are necessary and important. I think for this approach to be viable we'd need an answer to that. The "terminator sibling" does seem viable, although it does also imply even more scanning, which I don't love. I'll give this some thought.

Instead, what we'd like to react to is the boolean flip, rather than the focus id, but we can only get that via a calculation.

Yup this makes sense. Memo-izing computation and making those changes "observable" does seem important. I'll give this some thought.

sorry for so many responses

No worries. I'll take as much feedback as I can get 😄

[viridia]

Well, one advantage is that the "terminator siblings" can have extra information within them.

For example, we could have an invisible marker component that is a "row separator" between each foreach row that contains the entity id of the foreach.

This means we would need to scan once O(N) instead of O(N^2): starting from the foreach loop, search for rowsep entities that have the matching entity id, and build a table of offsets until you get to the end. This gives you the spread of entities that need to be added / removed / replaced for a given row.

My thinking on memoization is that it could be optional: you have two forms of the reaction, a Reaction like your example above and MemoReaction that uses a two-callback strategy like I do.

Note that, as @villor pointed out, what you are calling a "Reaction" is what React and Solid calls an "Effect" (via use_effect() or create_effect() depending on framework), which is one particular kind of reaction. Specifically, an "effect" is a reaction that:

• Doesn't return a value.
• Whose only purpose is to produce side effects.

This is different than a "derived" or "computation" which is a reaction that produces a value - that is, it triggers downstream reactions when its output changes.

(BTW it's very interesting that I often get ideas once you commit to an approach - that is, while things are uncertain my mind is overwhelmed with possibilities, but once I know not to consider ideas outside of a certain envelope, suddenly new solutions that I didn't previously think of arise.)

[viridia]

I've had some time to mull over the "for-loop" problem. I have two thoughts on this:

First, I think that the "invisible row separator" approach might work, but it will require scanning. It's better than my previous approach, which required scanning for each row as a separate step when updating that row - this approach at least amortizes the cost over multiple rows.

Second, I recognize that the vast majority of for loops do have a single, non-dynamic, child per row (though that row may have dynamic children). I've thought about the idea of supporting a "simplified" foreach construct in which the second closure argument returns an impl Bundle instead of the more general API for creating multiple children (one where you pass a builder to the closure instead of having the closure return a value). However, as I think you would agree, that other 5% use case needs to be supported, possibly with a different and more complex foreach alternative.

However, the idea of having multiple foreach algorithms raises some concerning issues. For one thing, I think we want syntactic sugar for the most common control-flow patterns: foreach, if, and switch. That is, when writing a template, you don't normally insert an "if" component, but rather the templating language recognizes the "if" keyword in some way. However, if there are multiple flavors of "for" then now the syntax needs to know which flavor of for to use.

[Diddykonga]

Rename please, Com looks like Cow, and doesnt suggest anything about targeting. Entity by itself would make more sense if it referred to the source/system entity itself, but it doesnt, again not suggesting anything about targeting involved.

Com: returns a component C on the target entity (if one is configured).
Entity: this will be set to the "target entity" (if one is configured)
SourceEntity: this will be set to the "source entity" (if one is configured)

To:

Target<B: Bundle>: returns an Bundle B on the target entity (if one is configured).
Target<(Entity, ...): includes the target entity id with the rest of the bundle. (if one is configured).
Source<B: Bundle>: the above, but for the source/system entity. (Basically Local's)
Source<(Entity, ...): includes source/system entity id with the rest of the bundle. (would always be configured with systems as entities 😉 )

I like pretty much everything else, the use of all the new features is quite nice, and being able to poll systems for system param changes is great and how I thought this would be implemented 👍

[villor]

This makes me happy 👍.

If I understand correctly, Reaction's (or "reactive systems") are essentially effects, pieces of code that runs whenever any of their dependencies change. Looks like this design fits very well into the ECS structure, and it seems nice and modular.

The hierarchy definition data model and the user facing hierarchy access model are the same. There is no need to know details like "this input hierarchy produces this output hierarchy" or "I need to visit the children of entities with a GhostNode component when traversing a hierarchy").

Like Talin, I'm curious about the for_each, and how it would work when nesting them with more loops, or other things like conditionals.

If I understand correctly, these entities will be siblings of their "children" (in semantic terms). To me that makes them (implicit) ghost nodes (ghost entities?). They are not ghost parents, but they are siblings of entities that may belong to a UI or Transform hierarchy, meaning the index of another entity among those Children may not actually be the index it has in its own context (like layout). And if I remember correctly, before 0.15 (and ghost nodes/text rework) those would even output warnings.

If ReactionTo is not present, it will do the same thing with the ChildOf reaction. Supporting both is a key piece!

This sounds very similar to what I have been proposing for UI/Transform/Visibility as a GhostNode alternative (among other uses). If those were also their own relationships (UiChildOf, TransformChildOf etc), with the added ChildOf fallback (though traversing to nearest contextual ancestor, e.g. first ancestor With<Node> in case of UI) there would be no need for explicit ghost nodes, and the for_each stuff could use actual Children. The input hierarchy and output hierarchy would be identical (I would argue even more so when the output of a loop is nested as children of its entity). The only difference from Bevy today would be that contextual queries would need to use the contextual relationship instead of Children. It also adds the ability to (just like ReactionTo) override those relationships, which may be useful for world-space UI, or UI-space spatial stuff (canvases).

Reactions and Observers could potentially be unified...

+1. I already feel a bit confused around observers and reactions. Reactions feel like a syntax sugar of an observer that listens to "on mutate" events + conveniences to read the values of the mutated data. If there was a way to make one nice API that fits both the "event" and "reactive effect" use case that would awesome.

Investigate ways for a component to "require" a function that returns a Bundle. It would be very nice if we could auto-spawn the whole tree whenever some Widget component is spawned. This has obvious limitations, such as not supporting default-value overrides.

Yes!!

Is this not doable with an on_insert/on_add hook? This kind of pattern also becomes a lot nicer with Construct/Patch. Been experimenting with something similar over in bevy_editor_prototypes using the receipt based approach from ICBINBSN.

I can't wait to play with this ❤️

[cart]

This makes me happy 👍.

I'm glad 😄

meaning the index of another entity among those Children may not actually be the index it has in its own context

Yup this is certainly a downside. Although this feels "better" to me than ghost parents as people are naturally filtering entities down to what they want with queries anyway. I like this more than forcing people to completely change how they iterate over entities.

Like Talin, I'm curious about the for_each, and how it would work when nesting them with more loops, or other things like conditionals.

Yup this is something that must be addressed for this approach to be viable.

Is this not doable with an on_insert/on_add hook? This kind of pattern also becomes a lot nicer with Construct/Patch. Been experimenting with bevyengine/bevy_editor_prototypes#184 over in bevy_editor_prototypes using the receipt based approach from ICBINBSN.

It is, but I don't love it as it implies an unnecessary archetype move (and means that anything inserted this way is inaccessible to hooks during the initial insert)

[JMS55]

I'm not too much a fan of this design. I had explored similar designs before in #16422 and #16309, but didn't find it to be workable. Look at the TODOs for nesting, chaining, and sharing signals/reactions. I didn't have a good path towards implementing any of it.

Explicit reactions like this are not really declarative, which is what I want. This feels more like GTK property binding https://docs.gtk.org/gobject/class.Binding.html which I've used in the past.

What I really want is something fully declarative, i.e.:

fn my_ui_tree(foo: &Foo, bar: &Bar) -> UiTree {
   // ...
}

commands.spawn_automatically_updating_ui(my_ui_tree);

I really don't want to have to care about change detection or dependencies. All I want is to say given some input, return this output, and then have some system in the background figure out how to keep it up to date each frame.

Besides not being declarative, it's not clear to me how you would hoist reactive state out of the entity tree. E.g. https://github.com/bevyengine/bevy_editor_prototypes/blob/3e1dad501ed762fddc3503748464800a4d94ab23/bevy_editor_panes/bevy_properties_pane/src/lib.rs#L112-L129

Or this example in react https://react.dev/learn/tutorial-tic-tac-toe (search for "To let the players know when the game is over, you can display text such as “Winner: X” or “Winner: O”. To do that you’ll add a status section to the Board component. The status will display the winner if the game is over and if the game is ongoing you’ll display which player’s turn is next:", and look at the code diff under it).

[JMS55]

To be clear I'm strongly in favor of a templating approach for Bevy. Besides ergonomics, I'm skeptical of being able to accurately perform change detection for all forms of input a game engine might want (especially in a way that's intuitive for users and easy to make sense of if you're not an ECS expert). Diffing the output seems inevitable to me, and sidesteps a lot of complexity.

For instance, how would incrementally hot reloading scenes work with your approach? Template diffing would make it trivial.

[viridia]

@JMS55 I wanted to respond to your message in some detail, although I must state up front that I don't speak for cart so anything I say has to be taken with a grain of salt.

First, let's not confuse syntax with semantics. BSN is a templating language with syntax, this has been understood from the very first design document that was posted. However, what wasn't clear at the time was how it would actually work - what that language would translate into. That doc had a single "Reactivity" bullet point, but no detail. (That single bullet point is what caused me to spend a year coding various experiments.)

What Cart's new proposal attempts to do is flesh out how reactivity works. It does not prevent someone from building a templating system on top of this, and from my understanding, that's the plan.

It sounds like you are also lobbying for a React-style VDOM diffing approach. Cart's proposal is much closer to the Solid-style fine-grained reactivity which doesn't require a VDOM. There are advantages of both approaches. Unfortunately, comparing the two approaches involves a very complex set of trade-offs which would require a book to fully describe.

For example: one design requirement that seems very important to Cart is minimizing archetype moves on construction. This means that in most cases, the set of components and children that are added to an entity by the template need to be added together in one lump rather than incrementally. This rules out, for example, "immediate mode" approaches because they can't "look ahead" and see how many children are going to be added.

Does the React approach entail more or less archetype moves than the Solid approach? For the Solid approach, we know the answer because it's the same as normal entity spawning - the same APIs are used. For the React approach, it really depends on the details of how the VDOM is built. This means that until we have a concrete design, we can't evaluate the impact it will have on the number of archetype moves.

For example, in Quill I used nested tuples to represent the VDOM, which meant that I could compute the number of children as a compile-time constant - it was part of the type signature of the tuple, so we could know before construction how many children there were going to be. Unfortunately, it didn't do this for components, which were added one at a time. Also, Quill had the problem that the APIs for constructing the VDOM were completely separate and different from the normal Bevy APIs for working with components and children, which means yet another way to construct hierarchies that has to be learned and maintained.

With respect to hoisting reactive logic out of the template: I think this should be possible, although as with everything in Rust the fundamental problem is lifetime management. I've been going with an entity-based approach - everything that is like a signal is owned by some entity, and the parameters you are passing around are entity ids wrapped in some newtype struct that defines their behavior.

Hot reloading is really a separate problem from reactivity. I think the current plan is to treat it like most asset reloads: a teardown and re-creation of the parts of the ECS hierarchy that are generated by the asset. However, that is outside of the scope of what's being proposed here.

[JMS55]

Yeah, I'd argue for vdom-style diffing over signals. Like I said before I tried signals and struggled to get them to work well. Then again I don't have anywhere near the amount of ECS experience cart has, so maybe he'll have more luck.

I'd like to see some examples from https://docs.solidjs.com/guides/state-management ported to Bevy to show that it's viable.

With respect to hoisting reactive logic out of the template: I think this should be possible, although as with everything in Rust the fundamental problem is lifetime management. I've been going with an entity-based approach - everything that is like a signal is owned by some entity, and the parameters you are passing around are entity ids wrapped in some newtype struct that defines their behavior.

Yeah that's basically how I created signals in the two PRs I linked. struct Signal<T: Component> { entity: Entity, pd: PhantomData<T> } wrappers so that the signal is Copy, with some helpers for reading/writing, and using observers / change detection + systems to perform the reactions.

[villor]

I think we tend to mix up the reactivity system and the rendering mechanism sometimes. Sure, sometimes they are tightly coupled, but they don't necessarily have to be.

I really like the first half of this proposal, the reactivity system, i.e. Reaction (though I'd also like to see some APIs/examples for derived values aka computeds/memos). It looks similar to signals and would provide a nice foundation for reactive trees in the ECS.

However I'm not sure about the second part (for_each et al). It is more of a render mechanism than something I consider part of a reactivity solution. For example I could see myself using Reaction to drive a coarse grained rendering mechanism (like ICBINBSN templates). I would encourage anyone interested in this subject to check out how Vue does it. They are a good example here because they do use a very signals-like reactivity system, while also doing VDOM-diffing as a rendering mechanism. But since the reactivity system is subscription based, the renderer does not need to re-render as large chunks of the tree as libs like React. A change very high up in the tree won't necessarily cause a re-render of the whole tree below. Only nodes whose render effect actually has a dependency on that change is re-rendered.

[mintlu8]

What's the justification for first party reactivity? It could be useful if bevy can provide like an OnChange -> SendEvent mechanism for third party reactivity crates to take advantage of, but the core bevy crate should stay relatively easy to reason and learn. Adopting a heavily opinionated pattern is likely a mistake. Also I would argue reactivity only benefits UI library authors, not so much end users that writes UI. Since if you are allowed to write systems, they can handle reactivity reasonably well.

The rest of the proposal is great, children! is very welcome update to spawn.