I am a novice in this area, so forgive me if I am missing something, but I have some questions regarding the two approaches in the article, specifically if ther

I am a novice in this area, so forgive me if I am missing something, but I have some questions regarding the two approaches in the article, specifically if there is a performance trade-off being made between them. To my untrained eye, the initial version seems to be doing a minimal set of updates based on the input it receives, whereas the latter version will call the monolithic render procedure no matter how small a change is made to the state. Does each of the sub-procedures in renderTodo! check internally if the state actually changed (by keeping a copy of the previous state?), or do they just unconditionally re-render the entire UI? If the latter is true, then doesn't this supposedly better way of structuring code come with a large performance penalty? Or is it simply the case that this penalty is outweighed by the added test-ability and improved consistency of the state? I believe that React and similar frameworks run a diffing procedure to find out which parts of the UI actually need to be updated (so a more minimal set of updates is actually applied). In the first version, however, it seems like the same diff occurred naturally as part of the code's structure - only a subset of the render* functions are called - and therefore the diff does not need to be computed at run-time. Is this something worth being concerned about, or is letting the framework compute the diff on every state change not that big of a deal?