3 ms·

I think this technique is really cool but I thought I should point out that although continuous rAF makes it easy (you can set state directly), on but FF and Ch

I think this technique is really cool but I thought I should point out that although continuous rAF makes it easy (you can set state directly), on but FF and Chrome on my machine, even when your page appears to be completely static it's consuming 10-20% of CPU constantly. That's got a couple of issues. 1. It eats my battery 2. It DoSes my machine (10-20% not available for other things) So, please don't do that. Set a `dirty` flag, call a `setState` or something that requests just 1 rAF or queues a task to re-render or something and then go back to sleep.

jlongster 12y ago
It's really not meant to be something to use in production. It was fun to run with it, but you're absolutely right. In fact, if you look at my Cortex example I do just that. You will most likely want to use a data structure that knows when something's changed anyway. But it was a neat way to go from something very simple to more complex.
userbinator 12y ago
it's consuming 10-20% of CPU constantly It appears you're using a multicore machine with between 5-10 cores. A continuous loop is basically going to keep one core at 100%, which is only a bit of an annoyance with a multicore, but on a single or even dualcore machine (e.g. low-end mobiles), it will make everything else slow to a crawl. It's interesting to note that, were this done several years ago or earlier, it would only make people complain about how your site froze their browser, but now we barely notice a single core running at full load unless we're observant... Please use computing resources responsibly.
- nitrogen 12y ago
  A continuous loop is basically going to keep one core at 100%, which is only a bit of an annoyance with a multicore, but on a single or even dualcore machine (e.g. low-end mobiles), it will make everything else slow to a crawl. Not to mention that, even on a high-end laptop, that will drain the battery very quickly and burn your lap in the process.
- greggman 12y ago
  It's not really using 100%. rAF means they do their work, then it goes to sleep until the next vblank. They then get their rAF event, check if they want to make any changes to the DOM, queue another rAF and then go back to sleep. So it really is only 10-20%. But it's still 10-20% :-( I would be curious why it's at 10-20% though. If they don't touch the DOM and their checks are quick (just a pointer as the article says) then there's some crazy serious overhead in the browser or somewhere just to call into JS once every 16-17ms and have it go back to sleep. It would be interesting to look into where 10-20% is going. It seems like in a perfect impl, a mostly no-op rAF should take 0.001% or something along those lines.

jlongster 12y ago

It's really not meant to be something to use in production. It was fun to run with it, but you're absolutely right. In fact, if you look at my Cortex example I do just that. You will most likely want to use a data structure that knows when something's changed anyway. But it was a neat way to go from something very simple to more complex.

userbinator 12y ago

it's consuming 10-20% of CPU constantly It appears you're using a multicore machine with between 5-10 cores. A continuous loop is basically going to keep one core at 100%, which is only a bit of an annoyance with a multicore, but on a single or even dualcore machine (e.g. low-end mobiles), it will make everything else slow to a crawl. It's interesting to note that, were this done several years ago or earlier, it would only make people complain about how your site froze their browser, but now we barely notice a single core running at full load unless we're observant... Please use computing resources responsibly.

nitrogen 12y ago
A continuous loop is basically going to keep one core at 100%, which is only a bit of an annoyance with a multicore, but on a single or even dualcore machine (e.g. low-end mobiles), it will make everything else slow to a crawl. Not to mention that, even on a high-end laptop, that will drain the battery very quickly and burn your lap in the process.
greggman 12y ago
It's not really using 100%. rAF means they do their work, then it goes to sleep until the next vblank. They then get their rAF event, check if they want to make any changes to the DOM, queue another rAF and then go back to sleep. So it really is only 10-20%. But it's still 10-20% :-( I would be curious why it's at 10-20% though. If they don't touch the DOM and their checks are quick (just a pointer as the article says) then there's some crazy serious overhead in the browser or somewhere just to call into JS once every 16-17ms and have it go back to sleep. It would be interesting to look into where 10-20% is going. It seems like in a perfect impl, a mostly no-op rAF should take 0.001% or something along those lines.