3 ms·

Maybe I'm missing something, but how would this prevent you from using setTimeout/setInterval? But I agree that these projects often work great in small use cas

by numpad 2y ago

Maybe I'm missing something, but how would this prevent you from using setTimeout/setInterval? But I agree that these projects often work great in small use cases, but quickly crumble under "real world" scenarios.

novocantico 2y ago
I admit that the two most complex "interactive apps" I've built with this are not that complex according to many standards: * https://www.immaculatalibrary.com/books.html https://www.immaculatalibrary.com/books.html (src = https://github.com/sdegutis/immaculatalibrary.com/blob/main/site/scripts/books-page.tsx https://github.com/sdegutis/immaculatalibrary.com/blob/main/...) * https://www.immaculatalibrary.com/prayers/ https://www.immaculatalibrary.com/prayers/ (src = https://github.com/sdegutis/immaculatalibrary.com/blob/main/site/prayers/client.tsx https://github.com/sdegutis/immaculatalibrary.com/blob/main/...)
_heimdall 2y ago
I'd be hesitant to run something like a 30fps render loop in a web app. Its been years since I last saw or tried that in a real world app but it didn't end well for performance. Your best bet would be to queue up specific UI changes that need to be made as diff's rather than checking the entire UI state. At that point, though, you might as well run them immediately as the change is needed. If that was still a perf problem you would end up chasing a very complex solution like react fiber to partially update the UI on a loop while periodically pausing for user events.
sophiebits 2y ago
Sure, if you blow away the entire app on every state change. But that would lose not only state defined in components (like `i` in ClickMe) but also all state implicitly stored in DOM elements (selection, focus, scroll position, input value, media playback).
throwitaway1123 2y ago
I would almost certainly never implement a UI as a render loop, but if you wanted to go down that path requestAnimationFrame is a much more idiomatic way to do it if you want to match the user's display refresh rate.

by numpad 2y ago

novocantico 2y ago

I admit that the two most complex "interactive apps" I've built with this are not that complex according to many standards: * https://www.immaculatalibrary.com/books.html https://www.immaculatalibrary.com/books.html (src = https://github.com/sdegutis/immaculatalibrary.com/blob/main/site/scripts/books-page.tsx https://github.com/sdegutis/immaculatalibrary.com/blob/main/...) * https://www.immaculatalibrary.com/prayers/ https://www.immaculatalibrary.com/prayers/ (src = https://github.com/sdegutis/immaculatalibrary.com/blob/main/site/prayers/client.tsx https://github.com/sdegutis/immaculatalibrary.com/blob/main/...)

_heimdall 2y ago

I'd be hesitant to run something like a 30fps render loop in a web app. Its been years since I last saw or tried that in a real world app but it didn't end well for performance. Your best bet would be to queue up specific UI changes that need to be made as diff's rather than checking the entire UI state. At that point, though, you might as well run them immediately as the change is needed. If that was still a perf problem you would end up chasing a very complex solution like react fiber to partially update the UI on a loop while periodically pausing for user events.

sophiebits 2y ago

Sure, if you blow away the entire app on every state change. But that would lose not only state defined in components (like `i` in ClickMe) but also all state implicitly stored in DOM elements (selection, focus, scroll position, input value, media playback).

throwitaway1123 2y ago

I would almost certainly never implement a UI as a render loop, but if you wanted to go down that path requestAnimationFrame is a much more idiomatic way to do it if you want to match the user's display refresh rate.