Greasy Fork镜像

Out of curiosity, why not using MutationObserver instead of setInterval? 🤔 MutationObserver is more efficient and for things like these is perfect.

MutationObserver requires using subtree, which won’t necessarily offer better performance.
Also, since Twitch is an SPA that switches between the live list and the live stream page, you’d still have to manage the registration and disposal of MutationObservers, making the implementation no simpler than using setInterval.

I get what you mean, but wouldn’t MutationObserver still be more efficient than polling, since it only reacts when something actually changes? 🤔 I didn't mean to be rude or anything like that.

In terms of real-time responsiveness, MutationObserver is indeed more immediate. For this simple feature, I think both approaches work, but I chose performance over immediacy, so I went with the simpler setInterval approach. Thanks for your reply — I also enjoy discussing these things.

You're right that both options work, but I’d still recommend a scoped MutationObserver for performance:
- It only runs when something actually changes, unlike setInterval, which runs all the time.
- It catches quick DOM changes that intervals might miss.
- The browser groups changes efficiently, so you usually get just one callback per animation frame.
- It doesn’t need to scan the whole DOM — the browser already keeps track of changes, and you can limit what you're watching.
- For single-page apps (SPAs), it's not harder to manage — one observer on body, and you disconnect it when you're done, just like you'd clear an interval.

It should use less CPU when idle and avoid unnecessary DOM lookups. 😊

I appreciate the technical insights, but for this simple Tampermonkey script, I prioritize readability over theoretical efficiency.
The setInterval approach keeps everything in ~180 lines vs 280+ with MutationObserver. (Rewrite generated by Claude)
Since Tampermonkey scripts are single-file and often shared/modified by others, having all the logic in one clear place is more valuable than micro-optimizations.
For a feature that runs once per second to claim points every few minutes, the performance difference is negligible, but the maintainability difference is huge. Sometimes "good enough" is actually better when it means other people can easily understand and modify the code.
Simple scripts should stay simple! 😊

I asked Claude to refactor the observer-based version, which you can see here: https://github.com/iml885203/helper_scripts/blob/master/tampermonkey/twitch_auto_channel_points_250813.js

The rewritten code became significantly more complex—over 100 lines compared to just 20—without offering meaningful benefits.
It introduced timing dependencies, debouncing logic, and unnecessary edge case handling.
Debugging also became more difficult due to the complexities of DOM events. Reliability suffered as well, since it now depends on accurate DOM change detection instead of predictable polling.
For a simple task like claiming points every few minutes, a 1-second delay from setInterval is perfectly acceptable. The added complexity is simply unjustified over-engineering.

Remember the KISS principle: Keep It Simple, Stupid. 😊

I don't know what you mean by “readability.” Most likely, it’s a matter of personal choice and aesthetics. 🤔

I don’t believe in “ugly code” — only code that is either not well-structured or not structured in a way that suits your needs.

Well, I have something like this: https://pastebin.com/raw/P7y0883v

Of course, my script is much simpler than yours. For me, the code is perfectly readable.

I prefer the getElement* methods; they’re usually faster than querySelector/querySelectorAll.

I noticed that you remove the clicked element. In my case, I just mark it by adding a new class to it. I prefer to let Twitch handle the removal of the element after it’s clicked.

It works pretty well — even in an idle tab. And the fact that I don’t use active polling is a pretty big win, in my opinion. No wasted resources. 😊