Me neither. I arrived at this through trial and error running it by a few 100 of thousands of examples in our app. The last three tests in the test files are about this.

Before I inserted lines 266-284, in certain cases when a text node had changed, it would create two diffs -- first one to remove the text node and then another to add it again. Check https://github.com/johanneswilm/DOM-diff/blob/gh-pages/test.html#L112-L113

With those lines in place, it would create just one modified text node diff.

 Then another issue appeared: when there were three sibling text nodes, and the middle one would be deleted so that there would only be two sibling text nodes (or the other way round), it would modify one of those that hadn't changed instead. (see test cases https://github.com/johanneswilm/DOM-diff/blob/gh-pages/test.html#L130-L138 )

Something like --

text nodes: "A", "B", "C" --> "A", "C" 

would create diffs:

modify "B" -> "C"

remove "C"

With the while loop in place, it will instead check whether the "C" text node is further down the line and just delete the "B", creating a diff like:

remove "B"

The idea with using a while loop is to also be able to handle cases like this:

"A", "B", "C", "D", "E", "F", "G", "H", "I" -> "A", "I"

It should then delete all the inner text nodes and leave "A" and "I" alone.

Feel free to change it if you can do it in a way that doesn't break the test cases.