It's funny, I'm actually writing an article about how fragment is more myth than fact, only being faster in Firefox and SLOWER in chrome than LIVE DOM changes so long as you're not doing anything (like innerHTML or getComputedProperties) that forces a reflow... and found in testing that if you use an Element instead of a fragment it's faster when you append it in since it doesn't have to redo/recopy every blasted child. Thus having the scripting-only #container in the markup is actually hurting you!

Not that scripting only elements belong in the markup in the first place.

I cannot believe you actually advocate the headache driven GARBAGE of event delegation, given that you end up with the overhead of matching in the event, the lack of a proper currentTarget, the overhead of extra cascade on the intercept... Your "good practice" isn't. At all. THE OPPOSITE IN FACT.

But then I say the same about foreach with the "callback for nothing" stuff.

That you'd say it reduces overhead makes it even more comically tragic. I don't know where you got that malarkey, but it's completely bass-wackards from how things work. Though if some "expert" out there is claiming that's somehow magically better, well it explains why I've seen so many bloated, slow, train wrecks pulling that stunt of late. I mean claiming to be making it faster, but then adding the overhead on every blasted click of checking classList? No.

Though your examples are all short. I've seen way too many cases of trying to handle it the way your saying where it ends up two to ten times the code needed to do the job when the event triggers.

I mean hell, event.target? You start putting span inside those buttons, or attach it to more complex structures, and see what happens!

That said, good examples of debounce and throttle.