3 ms·

You've solved one set of problems (and fixed the major problem that the original had no separation between library and user land code) and created some new prob

by om2 10y ago

You've solved one set of problems (and fixed the major problem that the original had no separation between library and user land code) and created some new problems: (1) A timer will fire forever, even if no progress bars are currently updating. Bye bye, battery life! (2) A progress bar can't update at 60fps, even if changes to the underlying value happen that quickly. IF you continue playing whack-a-mole with these types of problems, you might see why Custom Elements + Shadow DOM are an elegant way to avoid these issues while providing good encapsulation. (As someone else mentioned, Shadow DOM provides style scoping so it doesn't have the CSS issue you raised, even if the contents are normal built-in elements, while your example does.) I hope this helps to clarify what Web Components technologies are good for.

gambler 10y ago
>You've solved one set of problems (and fixed the major problem that the original had no separation between library and user land code) My original followed the structure outlined in the article's example. It runs the exact same library code as the second link. I did not "fix" anything, since nothing was broken in the first place. I simply split it for clarity. > A timer will fire forever, even if no progress bars are currently updating. Bye bye, battery life! You claim regarding battery life is unsubstantiated. Simple timers like that take up very little processor time as long as you don't do superfluous DOM updates in every invocation. > A progress bar can't update at 60fps, even if changes to the underlying value happen that quickly. Firstly, it can. If you set the timer to 16ms and there is nothing else loading up the browser engine. Secondly, if you think that your typical events always updates the page graphics at 60FPS, you are mistaken. But most importantly, you really don't want to update a control like this 60 times per second, because you would be wasting CPU cycles on re-calculating values that no human will ever notice.
- om2 10y ago
  > You claim regarding battery life is unsubstantiated. Simple timers like that take up very little processor time as long as you don't do superfluous DOM updates in every invocation. That seems intuitively plausible, but for modern CPUs, it is very wrong. To give a specific example: modern Intel CPUs have a wide range of power levels including idle states called C-states. C-states are very low power, but somewhat expensive to enter and leave; while in a C-state, a CPU core can't really do anything besides wake up to a higher state. A frequent timer, even if it does almost nothing, stops the CPU from being idle long enough to stay in a C state profitably. Thus, frequent timers that do almost nothing can hurt your battery life more than sharp but very infrequent spikes in CPU usage. My claim to expertise: I was heavily involved in optimizing Safari and WebKit for battery life. Most of what we had to do was not reducing average CPU usage, but rather preventing gratuitous wake from idle, or where not possible, coalescing repeated wakeups so they happened at exactly the same time instead of slightly offset. We actually measured this and it is a major effect. In fact, tuning this way is one of the major reasons that browsing in Safari delivers longer battery life than browsing with Chrome on the same hardware. I am going to bet you did not measure and your claim is based on speculation. On mobile devices it's somewhat different. The screen and radio are a much bigger portion of the total power envelope so the CPU doesn't matter quite as much. But as mobile CPUs continue to get more powerful, maintaining good idle hygiene will become more important there too. Short version, and something all web developers (and native developers should know) should know: idle timers are extremely costly in terms of battery life, when your app or webpage seems looks idle, it should actually be idle! > Secondly, if you think that your typical events always updates the page graphics at 60FPS, you are mistaken. > But most importantly, you really don't want to update a control like this 60 times per second, because you would be wasting CPU cycles on re-calculating values that no human will ever notice. When the process driving the progress bar is making material progress, it is both feasible and desirable to update the progress bar within one frame.
  - gambler 10y ago
    Since I don't know what exactly you measured, how you did it, on which devices, and for what use cases, I cannot comment on specifics of what you said. I tested various variations of this approach for extreme cases (large pages, many timers, complex CSS queries). The visual performance and CPU utilization were much, much better than I initially expected. My testing for mobile was less thorough, but I didn't notice anything horrible going on with the battery, precisely because of what you said: the browser-based drain was negligible compared to drain by screen, network and background services. I admit neglecting to test this on unplugged laptops. I will eventually get to it, but I don't think the results will be as bad as you make them sound. Regardless, notice how the conversation shifted from "this is impossible" to "this doesn't scale" to "this might be not very battery efficient in some cases". I consider it premature to dismiss this approach without knowing exact costs for battery use in real-life browsing scenarios. (After all, I'm not the only one on the web using timers, and some other things many websites do today slaughter both battery and visual performance, and people continue using them without thinking twice.) The approach has merit. In fact, it has a lot of merits that aren't obvious from such a simple example. The true benefit of timers is that they illiminate many issues related to events and inter-component interaction, thus drastically cutting down on code complexity in more dynamic, more complex pages. Custom elements are not going to address that any more than ASP components did in their heyday.

by om2 10y ago

gambler 10y ago

>You've solved one set of problems (and fixed the major problem that the original had no separation between library and user land code) My original followed the structure outlined in the article's example. It runs the exact same library code as the second link. I did not "fix" anything, since nothing was broken in the first place. I simply split it for clarity. > A timer will fire forever, even if no progress bars are currently updating. Bye bye, battery life! You claim regarding battery life is unsubstantiated. Simple timers like that take up very little processor time as long as you don't do superfluous DOM updates in every invocation. > A progress bar can't update at 60fps, even if changes to the underlying value happen that quickly. Firstly, it can. If you set the timer to 16ms and there is nothing else loading up the browser engine. Secondly, if you think that your typical events always updates the page graphics at 60FPS, you are mistaken. But most importantly, you really don't want to update a control like this 60 times per second, because you would be wasting CPU cycles on re-calculating values that no human will ever notice.

om2 10y ago
> You claim regarding battery life is unsubstantiated. Simple timers like that take up very little processor time as long as you don't do superfluous DOM updates in every invocation. That seems intuitively plausible, but for modern CPUs, it is very wrong. To give a specific example: modern Intel CPUs have a wide range of power levels including idle states called C-states. C-states are very low power, but somewhat expensive to enter and leave; while in a C-state, a CPU core can't really do anything besides wake up to a higher state. A frequent timer, even if it does almost nothing, stops the CPU from being idle long enough to stay in a C state profitably. Thus, frequent timers that do almost nothing can hurt your battery life more than sharp but very infrequent spikes in CPU usage. My claim to expertise: I was heavily involved in optimizing Safari and WebKit for battery life. Most of what we had to do was not reducing average CPU usage, but rather preventing gratuitous wake from idle, or where not possible, coalescing repeated wakeups so they happened at exactly the same time instead of slightly offset. We actually measured this and it is a major effect. In fact, tuning this way is one of the major reasons that browsing in Safari delivers longer battery life than browsing with Chrome on the same hardware. I am going to bet you did not measure and your claim is based on speculation. On mobile devices it's somewhat different. The screen and radio are a much bigger portion of the total power envelope so the CPU doesn't matter quite as much. But as mobile CPUs continue to get more powerful, maintaining good idle hygiene will become more important there too. Short version, and something all web developers (and native developers should know) should know: idle timers are extremely costly in terms of battery life, when your app or webpage seems looks idle, it should actually be idle! > Secondly, if you think that your typical events always updates the page graphics at 60FPS, you are mistaken. > But most importantly, you really don't want to update a control like this 60 times per second, because you would be wasting CPU cycles on re-calculating values that no human will ever notice. When the process driving the progress bar is making material progress, it is both feasible and desirable to update the progress bar within one frame.
- gambler 10y ago
  Since I don't know what exactly you measured, how you did it, on which devices, and for what use cases, I cannot comment on specifics of what you said. I tested various variations of this approach for extreme cases (large pages, many timers, complex CSS queries). The visual performance and CPU utilization were much, much better than I initially expected. My testing for mobile was less thorough, but I didn't notice anything horrible going on with the battery, precisely because of what you said: the browser-based drain was negligible compared to drain by screen, network and background services. I admit neglecting to test this on unplugged laptops. I will eventually get to it, but I don't think the results will be as bad as you make them sound. Regardless, notice how the conversation shifted from "this is impossible" to "this doesn't scale" to "this might be not very battery efficient in some cases". I consider it premature to dismiss this approach without knowing exact costs for battery use in real-life browsing scenarios. (After all, I'm not the only one on the web using timers, and some other things many websites do today slaughter both battery and visual performance, and people continue using them without thinking twice.) The approach has merit. In fact, it has a lot of merits that aren't obvious from such a simple example. The true benefit of timers is that they illiminate many issues related to events and inter-component interaction, thus drastically cutting down on code complexity in more dynamic, more complex pages. Custom elements are not going to address that any more than ASP components did in their heyday.