3 ms·
That has been my experience as well, in fact, I believe the native DocumentFragment code should be slower than the jQuery innerHTML-based code.
by laughinghan 13y ago
That has been my experience as well, in fact, I believe the native DocumentFragment code should be slower than the jQuery innerHTML-based code.
- ivanca 13y agoIs not crappy because is slower, is crappy because it destroys all the eventListeners and custom properties of all their childNodes.
- brokenparser 13y agoIt's crappy because it's not just slow, it manages to freeze Firefox 22 on a 2,8GHz CPU. http://jsperf.com/leebrimelow-native-methods-jquery-dom http://jsperf.com/leebrimelow-native-methods-jquery-dom
- deleted 13y ago[deleted]
- ivanca 13y agoAt least we agree is crappy. BTW sorry for ruining your perfs, I really wanted to test some few things.
- brokenparser 13y agoOkay. Revision 9 adds code to remove the inserted elements, to put every test on equal footing. Is the practical equivalent yours? Because it hits a sweet spot.
- ivanca 13y agoThe one called "MUCH MORE PRACTIVAL native equivalent" is a mistake, it doesn't do anything. I didn't know documentFragment lacks the innerHTML property so is not doing any parsing like the others.
- brokenparser 13y agoAh, that explains it. I can't submit Firefox results, though. The crappy native equivalent just locks up after throwing several "unresponsive script" warnings.