It's always useful to check last edit date on StackOverflow—some answers are so upvoted they stay on top forever even when they get irrelevant, since whoever finds them today upvotes them again.
On a side note, why does Blogger have such terrible UX and why won't they fix it? On the desktop, they show spinning wheels while loading a simple text blog entry, on the mobile they override swipe left/right, completely screwing native browser navigation gestures.
To be fair, at least in iOS, the edge swipe wasn't implemented until iOS 7. Imgur has the same problem, annoying as hell, but that might be a reason to why they haven't fixed it. (Even though iOS 7 is soon a year old)
I'm running iOS 6 and it is insanely infuriating here as well: I keep ending up moving between articles while trying to look at the graphs, as I end up scrolling left/right "too far" expecting it to rubberband. (Note that when using iOS 7 I have no trouble navigating Safari with the new native gestures.)
JsPerf is really well known, but unfortunately, it also very poorly suited for this kind of performance comparison:
1. JSperf doesn't encourage any kind of validation that the various snippets actually do the same thing. I'm not kidding when I say that almost all jsperfs I read are buggy. This one is too; it reuses the same pre-cached nodes without cloning them, and those aren't semantics you want and aren't comparable with innerHTML.
2. JSperf's scaling is terrible. It's showing ops/sec rather than sec/ops, when the latter is much more interesting. Almost always you're interested in keeping UI latency low, not in somehow repeating as many operations per second; the ops/sec display emphasizes tiny differences that don't matter over very large differences that do. A difference in 0.01s vs 0.011s will appear just as large as (say) 0.1s vs. 1s, and that's not helpful. A logarithmic scale might be nice too.
3. JSperf's semantics are surprising enough to cause bugs. For instance, the benchmark setup/teardown aren't called for every test, nor are they merely called before the first and after the last test - but something utterly useless in between. Tests aren't isolated from each other, so cruft left from one test can impact a later test easily. Actually, tests are run in the jsperf document itself, so trivial stuff like how many comments or versions a benchmark has could conceivably impact DOM performance.
It can still be a useful tool - but be aware that most jsperfs out there are quite misleading because they don't test what they claim.
6 comments
[ 3.1 ms ] story [ 27.0 ms ] threadOn a side note, why does Blogger have such terrible UX and why won't they fix it? On the desktop, they show spinning wheels while loading a simple text blog entry, on the mobile they override swipe left/right, completely screwing native browser navigation gestures.
http://jsperf.com/appendchild-vs-documentfragment-vs-innerht... (scroll down for the comparison chart!)
1. JSperf doesn't encourage any kind of validation that the various snippets actually do the same thing. I'm not kidding when I say that almost all jsperfs I read are buggy. This one is too; it reuses the same pre-cached nodes without cloning them, and those aren't semantics you want and aren't comparable with innerHTML.
2. JSperf's scaling is terrible. It's showing ops/sec rather than sec/ops, when the latter is much more interesting. Almost always you're interested in keeping UI latency low, not in somehow repeating as many operations per second; the ops/sec display emphasizes tiny differences that don't matter over very large differences that do. A difference in 0.01s vs 0.011s will appear just as large as (say) 0.1s vs. 1s, and that's not helpful. A logarithmic scale might be nice too.
3. JSperf's semantics are surprising enough to cause bugs. For instance, the benchmark setup/teardown aren't called for every test, nor are they merely called before the first and after the last test - but something utterly useless in between. Tests aren't isolated from each other, so cruft left from one test can impact a later test easily. Actually, tests are run in the jsperf document itself, so trivial stuff like how many comments or versions a benchmark has could conceivably impact DOM performance.
It can still be a useful tool - but be aware that most jsperfs out there are quite misleading because they don't test what they claim.
...unless you fall into second delays because of this. but if that is the case, you are doing lots of things wrong. Lots.