Stop writing milliseconds and hating JavaScript's setTimeout & setInterval | Hacker News Reader

Stop writing milliseconds and hating JavaScript's setTimeout & setInterval

github.com

21 pointsavk25 comments

Why would I add 1.8K of possibly buggy minified code, compiled from 247 lines of possibly buggy un-minified code, to my web app, just in order to avoid having to write

    function after(seconds, fn) { return setTimeout(fn, seconds * 1000); }
    function every(seconds, fn) { return setInterval(fn, seconds * 1000); }
    var MINUTE = 60, HOUR = 3600;

in my program?

I do like the naming and argument order better than the standard functions, but the cost-to-benefit ratio of this library seems off by two orders of magnitude, given the ability to get the same benefit in two or three lines of code instead of 200 or 300.

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.

milliseconds 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.

You 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.

And 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).

If 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.

Sure, 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.

I'm sorry but if you can't immediately realize upon reading that 5 * 60 * 1000 is five minutes, you probebly shouldn't be trying to use window.setTimeout and definitely not window.setInterval.

Not every single thing needs to be wrapped in a jQuery "helper". Doing that just makes the developer using it more reliant on jQuery and less experienced/knowledgeable about straight JavaScript.

Clearly any semi-decent programmer can mentally translate 5 * 60 * 1000 into 5 minutes. So what? This is nonetheless a more intuitive and less error prone way to write times. This is about making readers of your code spend less cognitive effort figuring out what your code does, decreasing the chances of bugs (oops, I missed a 0 or screwed up a conversion factor), and making your code easier to modify. You seem to think this is a plugin for programmers too dumb to use milliseconds; it's not. Stop making excuses for bad code.

That said, sure, this isn't exactly a huge issue that's plaguing the javascript community. I probably won't use this plugin.

I'm not disagreeing with your general point, but this does seem a little overkill when you could achieve a similar effect with a few constants:

  5 * MINUTE
  3.5 * HOUR

etc.

Where are you getting these constants in JavaScript? You can't even trust the built-in "undefined" to actually contain "undefined".

(My point is: a library may be more appropriate in the JavaScript case, because of the lack of constants.)

is mytimelibrary.MINUTE what you're getting at?

For the small benefit of making timeout calls slightly prettier, I incur the small-but-probably-net-greater risk that there is some bug, subtle or otherwise, in this code, along with a motley assortment of other issues I usually gloss over but start being significant when we're talking about such small benefits, like adding a dependency and having to worry about the licensing situation. (Even just having to worry about something that turns out to be "public domain" is something to judge.) Net net I'd personally judge it a loss; YMMV, no sarcasm. I would generally analyze any NIH solution that solves such a small problem in the same way. It is, perhaps, one place where NIH is appropriate.

Each use of a non standard library makes code less "portable" - both in the sense that you need to include another library to support it, and in that it will be a speed bump to other developers reading and using your code.

So I generally have a non trivial minimum bar for using a library in my code - it has to do more than just a little syntactic sugar.

I don't agree with your argument. The purpose of all programming languages and tools is to abstract away lower level behavior—not to make people lazier or dumber, but to make them more productive. Sure, it's never bad to know more about the lower levels, but that doesn't mean higher levels of abstraction are "dumbing down" things.

Programming is about solving problems, and if someone else has already solved a problem in a generalized and reusable way, at the end of the day you haven't created value by insisting on recreating that solution yourself. Please note that I'm referring to getting things done, specifically in industry; I'm not arguing that also understanding the lower levels is a bad thing. For example, I would love to thoroughly understand x86 assembly, and it would probably make me a better programmer (it couldn't hurt), but that doesn't mean I would refuse to use a high level language.

Being "reliant" on jQuery and its plugins isn't a bad thing if you're a web programmer that will always be able to use those tools. You can always go down another level and call someone "reliant." If you use pure JavaScript, then you're "reliant" on the browser's implementation. If you wrote the browser's JavaScript implementation in C++, you're "reliant" on the C++ compiler. Perhaps by the end of the day you're an x86 assembly expert, but now you're "reliant" on the assembler until you memorize the bit strings of all the hundreds of instruction.

But jQuery is a library, not a programming language. A web developer should not depend on jQuery precisely because it is not available in every javascript environment.

Where does plain old code reusability (which everyone in the software industry agrees is good) end and "libraries" begin? The jQuery library is just a bunch of open source JavaScript code. If you can distribute your own JavaScript code with your web creations, then you can distribute jQuery, and even if the jQuery team breaks things you can keep using an old version. Are you suggesting it shouldn't be relied upon because someone else wrote it, or are you against code reuse in general?

No, you can't always distribute jQuery - if a project is already using another library, it's not really acceptable to include jQuery.

Code re-use is great, when it makes sense. Requiring jQuery and a ~250 line script, so you can use "5 minutes" instead of (5 * 60 * 1000) is ridiculous, and any developer who does that would get a bollocking if they reported to me.

I was excited about this, not for a different way of notating time, but because setTimeout and setInterval make me hate life trying to deal with it's idiosyncrasies. Maybe I'm not that great at JavaScript or I had worse resources available, but last time I tried to use them, it was a very frustrating experience.

The 2 * 60 * 1000 idiom for two minutes doesn't bother me.

underscore.js has a nice alternative for setTimeout() and several functions that probably should be used instead of setInterval() in most cases where setInterval() is used:

http://documentcloud.github.com/underscore/#delay

Thanks for sharing. I haven't worked with underscore yet. What about delay do you find superior to setTimeout() ?

Author here. Very open to feedback & criticism. Thanks!

I could see this being really useful if it could message a javascript event bus. Maybe use it for deciding when to synch browser data with server data or to modulate the messaging between different users browsers. The statelessness of http creates many timing related problems.

On a side note: when is one of these big companies going to release a really advanced "jquery for webkit" that forgets about the browser incompatibilities and focuses on building a virtual operating system in the browser? Google, Apple, Netflix? Anyone?

Thanks for the idea but that's definitely much more complex than what I had in mind: just encouraging people to use more readable JS timers.

Feel free to build on top of my code though!

I use Jquery Timers to accomplish a similar goal. http://plugins.jquery.com/project/timers

Reply on news.ycombinator.com