By program flow I mean something like:
Let’s take a look how is this change executed in classical software and Tickator.
On this image you can see typical propagation of change in classical software:
Change propagates by “depth-first” method because there is no simple way how to split execution on branches. You can use threads for this but then you face bunch of threading synchronization issues.
In our UI sample above this would mean, that UI is layouted twice - in step 3. and 8. Also component 4 is handled later than component 8, despite it is much closer to source of change. I find hard to work on programs like this.
In Tickator is change spread in waves:
As you can see change propagates by “breadth-first” method. Information flows splits if necessary - and no explicit action is required!
In out sample above that means tha UI is layouted once - information reach component 8 from 2 branches simultaneously. In real case it is bit harder to have such nice timing, but it is much easier than in classical software.