3 ms·
Author here. Point taken. Please use whatever works best for you. I mostly wanted to encourage people to write more readable JS timers. Ideally, after() and eve
by avk 15y ago
Author here. Point taken. Please use whatever works best for you. I mostly wanted to encourage people to write more readable JS timers. Ideally, after() and every() would make it into ECMAScript in some optimized form so you wouldn't need my code :)
By the way, the argument order and flexibility is what contributes to most of those lines.
- kqueue 15y agomilliseconds is pretty readable. What's not readable is "9.7" and 100 because I am not sure if that's in seconds, milliseconds unless I know the default.
- kragen 15y agoYou might have a point if we were talking about mass (is that 9.7 grams or 9.7 kilograms?) or length (9.7 feet or 9.7 meters?), but if you're talking about voltage or current or power or time, and using floating-point numbers, there's really only one reasonable default unit you could be using in each case. And the millisecond it is not.
- nitrogen 15y agoAnd the millisecond it is not. ...unless you're talking about computer programming instead of physics, in which case one uses counts of milliseconds, microseconds, or nanoseconds. Also remember that integers are valid floating point numbers, so after(100) is ambiguous in the context of computer programming (as pointed out by the prior poster).
- kragen 15y agoIf you have floating-point numbers, there's no reason to use milliseconds, microseconds, or nanoseconds instead of seconds, except to deliberately obfuscate your code, or if you need more than 53 bits of precision.
- nitrogen 15y agoSure, if you're running JavaScript on a CPU with a beefy FPU there's no reason now, but you're still going against decades of ingrained behavior and potentially affecting performance on embedded systems.