Maybe the default in Vuo could be that everything that isn't hooked to a "Fire On Start" or "Fire Periodically", gets an evaluation style of "Fire On Display Refresh" by default.
In this concept, a node that isn't hooked to "Fire On Start" or "Fire Periodically" could still opt to have not every part of the code refreshed every frame (a node could be made to only re-evaluate when a port value changes…an idle patch, basically).
My reasoning behind this suggestion is that when designing a composition, I am finding that many nodes connect to either "Fire Periodically", "requestedFrame"(window output), or "Fire On Display Refresh". Overwhelmingly more than not. If it bears out that this is the case for the majority of graphs, it may make sense for that to be implicit, and for things like "Fire On Start" or "Fire Periodically" to be the exception to the rule, hooked to the minority of nodes in the graph. When designing the composition, at the end one would optimize it, by introducing the Fire On Start/Periodically as needed.
It seems more natural, for a "realtime visual" type environment to have a port update immediately cause a node to update by default.
I would like to add that this comment may be wrong.
I do see the value in what has been done, and it seems workable. I like it! I find that I use "requestedFrame" output of windows quite a bit, which results in feedback loop looking graphs. I don't really have a problem with it, but it occurs to me that I've observed QC users have great problems conceptualizing feedback type loops in the past.
In fact, I'm less motivated to make this comment on my behalf, than I make it out of a hunch that other users (especially those coming from background in using QC) would find it more natural, and graphs to be visually simpler looking, while essentially retaining the same Vuo function set. I can see value in the current approach as well.