CARVIEW |
jeresig
(John Resig)
- You’re not logged in!
- Login
- Pricing & Signup
- Name
- John Resig
- Website/Blog
- https://ejohn.org/
- Company
- Mozilla Corporation
- Location
- Boston, MA
- Member Since
- Feb 28, 2008 (about 1 year)
Following 9 coders and watching 30 repositories view all →
Public Repositories (10)
-
sizzle
A sizzlin' hot selector engine.
Last updated Thu Feb 11 15:45:28 -0800 2010
-
processing-js
A port of the Processing visualization language to JavaScript.
Last updated Wed Feb 03 07:11:32 -0800 2010
-
dromaeo
JavaScript Performance Test Suite
Last updated Thu Dec 10 13:47:46 -0800 2009
-
testswarm
Distributed continuous integration testing for JavaScript.
Last updated Sat Dec 05 03:01:42 -0800 2009
-
retweet
A simple retweet button.
Last updated Mon Oct 05 12:17:51 -0700 2009
-
fireunit
A Firebug extension for JavaScript testing.
Last updated Sun Oct 04 18:47:58 -0700 2009
-
selectortest
A test suite for the Selectors API specification.
Last updated Mon Sep 21 18:58:31 -0700 2009
-
jeresig.github.com
A GitHub-powered web site.
Last updated Tue Dec 16 20:27:56 -0800 2008
-
env-js
A pure-JavaScript browser environment.
Last updated Sun Oct 12 08:27:10 -0700 2008
-
vote
Reddit, Hacker News, Digg voting script for Ubiquity.
Last updated Thu Sep 04 12:37:35 -0700 2008
Public Activity 
@subtleGradient: Actually, I haven't had many problems with the IE technique to speak of - I've actually had more problems with the browser's native DOMContentLoaded implementations firing too early. In that case I just make sure that document.body exists because we depend upon it in core.
@jdalton: Correct, it's never a good idea to rely upon a document.body check alone - which is why it serves as a good backup to the primary checks (DOMContentLoaded and the doscroll techniques).
I've actually written about timers extensively:
https://ejohn.org/blog/how-javascript-timers-work/
https://ejohn.org/blog/analyzing-timer-performance/ part 2: https://ejohn.org/blog/revenge-of-the-timers/
https://ejohn.org/blog/javascript-in-chrome/
https://ejohn.org/blog/timer-and-interval-offset/(This is related to the built-in time, not necessarily timers, but it's also interesting: https://ejohn.org/blog/accuracy-of-javascript-time/)
I'm not entirely sure what you mean by a failure rate - if the body doesn't exist we have to wait until it does - thus we are at the mercy of the browser here and need to use a timer to delay the execution of the callback.
That's about the maximum rate at which most browsers can update their timer. Except for Chrome, if you make it lower then it'll go as fast as it can (down to 1ms). 13ms is a pretty good time to have a consistent rate across browsers without completely decimating the CPU.
Good call - fixed in 35c379075c9feaa7cf82b4cf4c50a790e35b4d5f.