The issue has been closed
posted by fregante about 5 years ago 
// eslint-disable-next-line no-await-in-loop
What if instead of using await we use old-fashioned promise handlers?
I don't understand. How would you rewrite that loop with "promise handlers"?
What I probably meant is promise chaining. I don't know the terminology too well.
But await is gonna slow down that loop for sure.
Await isn’t slower than promise chains. The lint rule is because await stops the loop and some users don’t realize that.
I found the problem of this issue: the feature is currently wrapping each individual character into its own DocumentFragment and then appending the whole thing back. The line in the middle is 200k characters long so you can see how that might take forever to finish.
I’m rewriting the feature to be a lot more efficient and I’ll probably also add a line length limit for these cases
The lint rule is because await stops the loop and some users don’t realize that.
Right, I just figured stopping the loop is what was slowing the whole thing down.
Sorry for sticking my nose in this, though; I'm trying to get more involved in OSS but haven't found something that works for me.
I’m rewriting the feature to be a lot more efficient
Fixed without adding limits, but it needs a little more work: https://github.com/sindresorhus/refined-github/pull/2737
Right, I just figured stopping the loop is what was slowing the whole thing down.
You got it the other way: await setTimeout was there specifically to avoid freezing the browser.
Loops will freeze the browser until they finish. In this case, the loop was doing thousands of operations that probably took minutes in Firefox, without letting the browser breathe.
await setTimeout was there specifically to pause the loop so Firefox could do other operations, like interacting with mouse clicks. But this code only checked once per line. In this extreme example, one line was enough to freeze the browser for minutes so it never reached await
IssueHunt