4 ms·

> Given the gulf between Safari vs Chrome battery performance, I'm not all that convinced that the declarative api is pure downside like HN cynicism and Twitter

> Given the gulf between Safari vs Chrome battery performance, I'm not all that convinced that the declarative api is pure downside like HN cynicism and Twitter outrage might suggest. Safari was already beating Chrome on battery life before its extension API was neutered. This is post hoc revisionist rationalization.

themacguffinman 7y ago
So obviously the correct response from the Chrome team is to continue avoiding an approach that is known to save battery life /s
- bangonkeyboard 7y ago
  To clarify: Safari was already beating Chrome on battery life before _Safari's_ extension API was neutered.
  - themacguffinman 7y ago
    What's your point? That Chrome now can't adopt Safari's extension API to save battery life because...? Improving Chrome's battery life by adopting a simpler extension API helps close the gap. That's a significant benefit whether or not Safari did it first or whether Chrome still has room for improvement.
    - shawnz 7y ago
      The grandparent was implying that Safari's better battery life justifies their decision to use the declarative API. But that was already the case before they adopted the declarative API, so it's not obvious that the declarative API has anything to do with that success. Maybe it's just a minor improvement, or maybe it isn't an improvement at all.
      - themacguffinman 7y ago
        I'm not sure how you could make that argument and ignore the fact that the declarative API is technically simpler and its battery benefits are apparent from that aspect alone.
        shawnz 7y ago
        It's not apparent that the benefits are significant in any way. They could be minuscule and therefore not worth sacrificing important user experience features like adblocking over. It could also be that because of the reduced expressiveness of the adblocker, more ads are missed, and you might therefore end up with a net increase in the amount of code that has to be executed by the browser. So the declarative API could actually lead to a performance decrease in practice.
        themacguffinman 7y ago
        The Chrome team has already evaluated the change and explain why the benefits are not miniscule [1]: > In addition to these safety concerns, there are also significant performance costs. In most cases, these costs are not from the evaluation of the extension script processing events, but rather from everything else coordinating the script. That overall performance impact can be very large, even for an extension written as performantly as possible where the JavaScript execution time is negligible. > As it’s designed today, the blocking version of the Web Request API requires a persistent, long-running process, and is fundamentally incompatible with “lazy” processes - processes that can be set up or torn down as-needed, conserving valuable system resources. There are also significant costs associated with the serialization of the request data, the inter-process communication needed to send that data to the extensions, and the processing of extension responses. You are free to dismiss the writeup as lies, of course. You're also free to handwave it away by saying "well I don't like the trade-off". But you can't discuss this as if the benefits are not apparent. [1] https://blog.chromium.org/2019/06/web-request-and-declarative-net-request.html https://blog.chromium.org/2019/06/web-request-and-declarativ...
        7y ago

themacguffinman 7y ago

So obviously the correct response from the Chrome team is to continue avoiding an approach that is known to save battery life /s

bangonkeyboard 7y ago
To clarify: Safari was already beating Chrome on battery life before _Safari's_ extension API was neutered.
- themacguffinman 7y ago
  What's your point? That Chrome now can't adopt Safari's extension API to save battery life because...? Improving Chrome's battery life by adopting a simpler extension API helps close the gap. That's a significant benefit whether or not Safari did it first or whether Chrome still has room for improvement.
  - shawnz 7y ago
    The grandparent was implying that Safari's better battery life justifies their decision to use the declarative API. But that was already the case before they adopted the declarative API, so it's not obvious that the declarative API has anything to do with that success. Maybe it's just a minor improvement, or maybe it isn't an improvement at all.
    - themacguffinman 7y ago
      I'm not sure how you could make that argument and ignore the fact that the declarative API is technically simpler and its battery benefits are apparent from that aspect alone.
      - shawnz 7y ago
        It's not apparent that the benefits are significant in any way. They could be minuscule and therefore not worth sacrificing important user experience features like adblocking over. It could also be that because of the reduced expressiveness of the adblocker, more ads are missed, and you might therefore end up with a net increase in the amount of code that has to be executed by the browser. So the declarative API could actually lead to a performance decrease in practice.
        themacguffinman 7y ago
        The Chrome team has already evaluated the change and explain why the benefits are not miniscule [1]: > In addition to these safety concerns, there are also significant performance costs. In most cases, these costs are not from the evaluation of the extension script processing events, but rather from everything else coordinating the script. That overall performance impact can be very large, even for an extension written as performantly as possible where the JavaScript execution time is negligible. > As it’s designed today, the blocking version of the Web Request API requires a persistent, long-running process, and is fundamentally incompatible with “lazy” processes - processes that can be set up or torn down as-needed, conserving valuable system resources. There are also significant costs associated with the serialization of the request data, the inter-process communication needed to send that data to the extensions, and the processing of extension responses. You are free to dismiss the writeup as lies, of course. You're also free to handwave it away by saying "well I don't like the trade-off". But you can't discuss this as if the benefits are not apparent. [1] https://blog.chromium.org/2019/06/web-request-and-declarative-net-request.html https://blog.chromium.org/2019/06/web-request-and-declarativ...
        7y ago