5 ms·

This is clearly overengineering if one has to write and maintain a service worker just to be able to display a static site offline. How to debug it? How to see

This is clearly overengineering if one has to write and maintain a service worker just to be able to display a static site offline. How to debug it? How to see if any of your visitors cannot load site because of error in a service worker? How to decide which pages to preload for offline reading? Also a service worker would add additional process in Chrome and require 30-40 Mb of RAM. I don't want service workers in my browser. Well, web standards have always been this broken and illogical as long as I rememeber.

untog 9y ago
> How to debug it? Chrome debug tools work just fine. > How to see if any of your visitors cannot load site because of error in a service worker? The service worker fetch event is a promise, so you can catch any errors encountered and tell the client to go fetch the remote version instead. You can then do whatever analytics stuff you want with the error. > How to decide which pages to preload for offline reading? Well, who knows. But it's flexible enough to let you decide yourself - the last attempt, AppCache, forced you to decide upfront. With a service worker you could in theory use a user's browsing history to know what pages they are likely to look at. Or you can actually create responses manually in the worker, so you can dynamically generate an entire page locally on the device. It's very powerful. > Also a service worker would add additional process in Chrome and require 30-40 Mb of RAM This part I can't argue with. I mean, Chrome already uses a different process for every tab, but more resources is more resources. I don't see service workers as over engineering, I see them as a low level API. We just need some abstractions.
- codedokode 9y ago
  There is still a problem that some sites will have a service worker and some will not. Maybe it would make more sense to allow the user to pick what they want to cache for offline reading. > The service worker fetch event is a promise, By the way promises is another poorly designed technology: they catch unhandled errors and do not report them in any standard way [1]. [1] https://stackoverflow.com/questions/28001722/how-to-catch-uncaught-exception-in-promise https://stackoverflow.com/questions/28001722/how-to-catch-un...
  - untog 9y ago
    > There is still a problem that some sites will have a service worker and some will not. Why is that a problem? > By the way promises is another poorly designed technology: they catch unhandled errors and do not report them in any standard way If you're using promises there is really no reason to not be handling your errors. Catching unhandled errors is by design and it works great. It's absolutely trivial to do. And, as the SO post you've linked to points out, you can catch unhandled promise errors using window.onunhandledrejection. It's not like it's that dramatically different to window.onerror. Promises might not be perfect, but they're better than JS callback hell in absolutely every way.
    - codedokode 9y ago
      > And, as the SO post you've linked to points out, you can catch unhandled promise errors using window.onunhandledrejection. It's not like it's that dramatically different to window.onerror. Why make a new non-standart event instead of just throwing an error and handling it with default error handler? That is poor design - because initially there was no reporting of unhandled errors at all and only later a workaround was added.
      - WorldMaker 9y ago
        `window.onunhandledrejection` is a part of the spec, it simply took a bit for browsers to catch up to it. It's a different handler because an application may need to know the difference between a synchronous error and an asynchronous error and handle them (dramatically) different.
        codedokode 9y ago
        If there is a need to distinguish between different kind of errors then it can be done by checking error prototype (if (error instanceof AsyncError) { ... }). There was no need to introduce a new event. I think the reason is because some developers have a kind of exception-phobia and they prefer to hide errors (make developer check for them explicitly) rather than let them bubble up. I see this in other platforms too. For example, in .NET if a background thread crashes because of unhandled exception then nothing happens to the main thread, no error is reported. The developer must check for an error and of course most developers won't care about this. Another example is how error reporting is done in a browser. JS errors are never shown to the user so if a rich JS app has an error the user won't know about it, the app will just stop working or show invalid data.

untog 9y ago

> How to debug it? Chrome debug tools work just fine. > How to see if any of your visitors cannot load site because of error in a service worker? The service worker fetch event is a promise, so you can catch any errors encountered and tell the client to go fetch the remote version instead. You can then do whatever analytics stuff you want with the error. > How to decide which pages to preload for offline reading? Well, who knows. But it's flexible enough to let you decide yourself - the last attempt, AppCache, forced you to decide upfront. With a service worker you could in theory use a user's browsing history to know what pages they are likely to look at. Or you can actually create responses manually in the worker, so you can dynamically generate an entire page locally on the device. It's very powerful. > Also a service worker would add additional process in Chrome and require 30-40 Mb of RAM This part I can't argue with. I mean, Chrome already uses a different process for every tab, but more resources is more resources. I don't see service workers as over engineering, I see them as a low level API. We just need some abstractions.

codedokode 9y ago
There is still a problem that some sites will have a service worker and some will not. Maybe it would make more sense to allow the user to pick what they want to cache for offline reading. > The service worker fetch event is a promise, By the way promises is another poorly designed technology: they catch unhandled errors and do not report them in any standard way [1]. [1] https://stackoverflow.com/questions/28001722/how-to-catch-uncaught-exception-in-promise https://stackoverflow.com/questions/28001722/how-to-catch-un...
- untog 9y ago
  > There is still a problem that some sites will have a service worker and some will not. Why is that a problem? > By the way promises is another poorly designed technology: they catch unhandled errors and do not report them in any standard way If you're using promises there is really no reason to not be handling your errors. Catching unhandled errors is by design and it works great. It's absolutely trivial to do. And, as the SO post you've linked to points out, you can catch unhandled promise errors using window.onunhandledrejection. It's not like it's that dramatically different to window.onerror. Promises might not be perfect, but they're better than JS callback hell in absolutely every way.
  - codedokode 9y ago
    > And, as the SO post you've linked to points out, you can catch unhandled promise errors using window.onunhandledrejection. It's not like it's that dramatically different to window.onerror. Why make a new non-standart event instead of just throwing an error and handling it with default error handler? That is poor design - because initially there was no reporting of unhandled errors at all and only later a workaround was added.
    - WorldMaker 9y ago
      `window.onunhandledrejection` is a part of the spec, it simply took a bit for browsers to catch up to it. It's a different handler because an application may need to know the difference between a synchronous error and an asynchronous error and handle them (dramatically) different.
      - codedokode 9y ago
        If there is a need to distinguish between different kind of errors then it can be done by checking error prototype (if (error instanceof AsyncError) { ... }). There was no need to introduce a new event. I think the reason is because some developers have a kind of exception-phobia and they prefer to hide errors (make developer check for them explicitly) rather than let them bubble up. I see this in other platforms too. For example, in .NET if a background thread crashes because of unhandled exception then nothing happens to the main thread, no error is reported. The developer must check for an error and of course most developers won't care about this. Another example is how error reporting is done in a browser. JS errors are never shown to the user so if a rich JS app has an error the user won't know about it, the app will just stop working or show invalid data.