5 ms·

Cool, thank you! For a smoother animation, you may want to replace the setInterval() with: const anim = () => { drawRipple(); requestAnimationFrame(a

Cool, thank you! For a smoother animation, you may want to replace the setInterval() with: const anim = () => { drawRipple(); requestAnimationFrame(anim); } anim();

beebeepka 5y ago
Also, setTimeout is more reliable for loops and such. As a fallback to requestAnimationFrame Edit: I wonder why was this downvoted. Is setTimeout not more reliable time wise than setInterval?
- franciscop 5y ago
  Probably because requestAnimationFrame is much better than setTimeout, AND requestAnimationFrame is supported even by IE10 so there's absolutely no need for a fallback. Also no, setTimeout is not more reliable than setInterval in many situations.
  - qweqwweqwe-90i 5y ago
    No one should bother supporting IE now.
    - forgotmypw17 5y ago
      I strongly disagree. If you can't be bothered to write resilient code, that's your choice, but don't speak for me on what I should and shouldn't support.
      - tomxor 5y ago
        Supporting IE !== "writing resilient code" If anything your code will be much worse for it and likely to contain more bugs.
        forgotmypw17 5y ago
        Your code could also just be simpler and not include bug-prone ways of writing. For each browser you add support for, x more browsers and access limitations you've never even heard of also become supported.
    - franciscop 5y ago
      At 2.3% in Japan, and a much higher percentage in some specific industries there like healthcare, some people probably might be bothered supporting IE. Not me or most people though: https://twitter.com/FPresencia/status/1428359948182818836 https://twitter.com/FPresencia/status/1428359948182818836
  - beebeepka 5y ago
    Did I not day FALLBACK? Oh, I did but I am getting downvoted and mansplained for pointing that out a simple fact. RAF also stops executing when tab is inactive. Sometimes we don't want our loop halted and that's where setTimeout comes in as the better alternative to setInterval.
    - franciscop 5y ago
      This is the perfect example of why it says not to ask why you were downvoted in the FAQ, and the last time I try to help. You literally asked, I just tried to give a plausible explanation. Instead you rant back, scream and insult those literally answering your question. Not the right behavior for HN.
      - beebeepka 5y ago
        I provided a real world example that you haven't considered before. Your condescending responses are hardly genuine attempts at finding a plausible explanation for me being downvoted by people who can't think that pointing out thing A is better than thing B even though thing C exists and is the correct approach most of the time.
- jsf01 5y ago
  Absolutely. setInterval with a very tight interval runs the risk that your code execution time eventually catches up with the interval duration itself. Using setTimeout and raf recursively avoid this problem, but they do add a bit of baggage themselves by growing the call stack via many many recursive calls. Edit: looking into this some more, it seems like the recursive methods might not actually grow the call stack due to being asynchronous. Their only added baggage is the extra closure which would be negligible. Anyone know if this is actually the case?
  - fenomas 5y ago
    There's no recursion involved with RAF or looping with setTimeout. In either case the "anim" function doesn't invoke itself, it calls a scheduling function and passes itself as an argument.
  - beebeepka 5y ago
    Hey hey, a guy that can read and not jump into conclusions because he failed reading my post. I think the added baggage is negligible. I've used this approach on super low end embedded devices running heavy duty browser code
- fenomas 5y ago
  requestAnimationFrame is much better here. If you're just drawing into a canvas, there's no reason to do that every N milliseconds - you want to do it once per screen refresh, which is what RAF is for. There's also the added benefit that RAF won't fire when the document isn't visible, so you don't waste cycles drawing to a canvas that's in a background tab, etc.
  - tomxor 5y ago
    > there's no reason to do that every N milliseconds Usually if you want to do any kind of posteriori procedural animation i.e real-time physics, you need a constant interval, and RAF does not give you this... RAF usually runs at 60FPS but it can drop to 30 or increase to 120 depending on the browser, hardware and power saving modes - Which means whatever you are running in that function can get called at drastically different intervals for different users. In this case the animation is a priori, meaning we don't have to simulate intermediate steps, so it's possible to correct for this inside the RAF alone by using Date.now() as the time parameter for shifting the sine wave... however this is not always the case. And in those cases setInterval can be far simpler when timing is important, but if you want to continue using RAF ultimately you would need to decouple rendering from "physics" or any timing related code that cannot be calculated a priori, and run the latter at a constant interval.
    - fenomas 5y ago
      I think a few topics are conflated here. The part of the code that draws pixels into a canvas (or tells webgl to draw) should always be called from RAF - there's never a reason to do that more often than the screen refreshes. And since TFA does basically nothing except set canvas pixels, RAF is clearly the thing to use. OTOH whether you want your animation to advance in real time is a separate issue, regardless of whether the animation is interpolated. If you do want real-time animations, and you're using an interpolated physics engine or similar, there really aren't any good options besides decoupling the interpolation from the rendering. And if you've done that, then it doesn't matter much whether the interpolation is called from RAF or setInterval (personally I use both, so that physics ticks can happen between RAF events if the CPU load is heavy). But as a footnote, setInterval definitely does not give you a "constant" interval. Besides the normal variance, browsers will throttle the events (e.g. if the document is in a background tab).
bryanbraun 5y ago
Agreed, just trying to keep the tutorial simple for now. My other web-animation/education project (https://sparkbox.github.io/bouncy-ball https://sparkbox.github.io/bouncy-ball) uses requestAnimationFrame more heavily. Now that I think of it, it might be worth adding an asterisk and footnote about requestAnimationFrame to the post.

Cool, thank you! For a smoother animation, you may want to replace the setInterval() with: const anim = () => { drawRipple(); requestAnimationFrame(anim); } anim();

beebeepka 5y ago

Also, setTimeout is more reliable for loops and such. As a fallback to requestAnimationFrame Edit: I wonder why was this downvoted. Is setTimeout not more reliable time wise than setInterval?

franciscop 5y ago
Probably because requestAnimationFrame is much better than setTimeout, AND requestAnimationFrame is supported even by IE10 so there's absolutely no need for a fallback. Also no, setTimeout is not more reliable than setInterval in many situations.
- qweqwweqwe-90i 5y ago
  No one should bother supporting IE now.
  - forgotmypw17 5y ago
    I strongly disagree. If you can't be bothered to write resilient code, that's your choice, but don't speak for me on what I should and shouldn't support.
    - tomxor 5y ago
      Supporting IE !== "writing resilient code" If anything your code will be much worse for it and likely to contain more bugs.
      - forgotmypw17 5y ago
        Your code could also just be simpler and not include bug-prone ways of writing. For each browser you add support for, x more browsers and access limitations you've never even heard of also become supported.
  - franciscop 5y ago
    At 2.3% in Japan, and a much higher percentage in some specific industries there like healthcare, some people probably might be bothered supporting IE. Not me or most people though: https://twitter.com/FPresencia/status/1428359948182818836 https://twitter.com/FPresencia/status/1428359948182818836
- beebeepka 5y ago
  Did I not day FALLBACK? Oh, I did but I am getting downvoted and mansplained for pointing that out a simple fact. RAF also stops executing when tab is inactive. Sometimes we don't want our loop halted and that's where setTimeout comes in as the better alternative to setInterval.
  - franciscop 5y ago
    This is the perfect example of why it says not to ask why you were downvoted in the FAQ, and the last time I try to help. You literally asked, I just tried to give a plausible explanation. Instead you rant back, scream and insult those literally answering your question. Not the right behavior for HN.
    - beebeepka 5y ago
      I provided a real world example that you haven't considered before. Your condescending responses are hardly genuine attempts at finding a plausible explanation for me being downvoted by people who can't think that pointing out thing A is better than thing B even though thing C exists and is the correct approach most of the time.
jsf01 5y ago
Absolutely. setInterval with a very tight interval runs the risk that your code execution time eventually catches up with the interval duration itself. Using setTimeout and raf recursively avoid this problem, but they do add a bit of baggage themselves by growing the call stack via many many recursive calls. Edit: looking into this some more, it seems like the recursive methods might not actually grow the call stack due to being asynchronous. Their only added baggage is the extra closure which would be negligible. Anyone know if this is actually the case?
- fenomas 5y ago
  There's no recursion involved with RAF or looping with setTimeout. In either case the "anim" function doesn't invoke itself, it calls a scheduling function and passes itself as an argument.
- beebeepka 5y ago
  Hey hey, a guy that can read and not jump into conclusions because he failed reading my post. I think the added baggage is negligible. I've used this approach on super low end embedded devices running heavy duty browser code
fenomas 5y ago
requestAnimationFrame is much better here. If you're just drawing into a canvas, there's no reason to do that every N milliseconds - you want to do it once per screen refresh, which is what RAF is for. There's also the added benefit that RAF won't fire when the document isn't visible, so you don't waste cycles drawing to a canvas that's in a background tab, etc.
- tomxor 5y ago
  > there's no reason to do that every N milliseconds Usually if you want to do any kind of posteriori procedural animation i.e real-time physics, you need a constant interval, and RAF does not give you this... RAF usually runs at 60FPS but it can drop to 30 or increase to 120 depending on the browser, hardware and power saving modes - Which means whatever you are running in that function can get called at drastically different intervals for different users. In this case the animation is a priori, meaning we don't have to simulate intermediate steps, so it's possible to correct for this inside the RAF alone by using Date.now() as the time parameter for shifting the sine wave... however this is not always the case. And in those cases setInterval can be far simpler when timing is important, but if you want to continue using RAF ultimately you would need to decouple rendering from "physics" or any timing related code that cannot be calculated a priori, and run the latter at a constant interval.
  - fenomas 5y ago
    I think a few topics are conflated here. The part of the code that draws pixels into a canvas (or tells webgl to draw) should always be called from RAF - there's never a reason to do that more often than the screen refreshes. And since TFA does basically nothing except set canvas pixels, RAF is clearly the thing to use. OTOH whether you want your animation to advance in real time is a separate issue, regardless of whether the animation is interpolated. If you do want real-time animations, and you're using an interpolated physics engine or similar, there really aren't any good options besides decoupling the interpolation from the rendering. And if you've done that, then it doesn't matter much whether the interpolation is called from RAF or setInterval (personally I use both, so that physics ticks can happen between RAF events if the CPU load is heavy). But as a footnote, setInterval definitely does not give you a "constant" interval. Besides the normal variance, browsers will throttle the events (e.g. if the document is in a background tab).

bryanbraun 5y ago

Agreed, just trying to keep the tutorial simple for now. My other web-animation/education project (https://sparkbox.github.io/bouncy-ball https://sparkbox.github.io/bouncy-ball) uses requestAnimationFrame more heavily. Now that I think of it, it might be worth adding an asterisk and footnote about requestAnimationFrame to the post.