4 ms·

For error logging (https://molily.de/robust-javascript/#error-logging https://molily.de/robust-javascript/#error-logging in the article), can anyone recommend a

For error logging (https://molily.de/robust-javascript/#error-logging https://molily.de/robust-javascript/#error-logging in the article), can anyone recommend a logging service that has a small JavaScript footprint? I use Sentry on one site but it has a 56K library you have to load before any of your JavaScript loads, so bad for page size + bad for page blocking. I would have thought they'd at least let you use a shim to capture errors quickly while you defer loading the full library (like how Google Analytics does it) but I can't see an obvious way to do that. Sentry has really nice features but 56K (17K compressed) is a big chunk when I'm trying to keep a page to about 100K transferred.

jbob2000 6y ago
There are many ways the browser can fail. I'm sure their SDK is large because of all the random hacks they need to use to capture everything from every browser. Couple this with the need to create first-class API, which adds some code bloat, and I can see how this ends up at 17K compressed.
- seanwilson 6y ago
  Why can't they do the shim approach while the library loads though? Google Analytics for example lets you push everything you want to record into a plain global array called "ga", and when the library loads, everything in the array in processed by the library. This lets you start capturing events without waiting for the library to load.
  - the_gipsy 6y ago
    it's a bit different though, you can't "push" errors somewhere, I guess so many error handlers and interceptors are set that it's not worth to split.
    - seanwilson 6y ago
      > you can't "push" errors somewhere Why? Can't you push the Error object or stack trace into an array to await processing?
      - jbob2000 6y ago
        What if the thing that is pushing the error object has an error?
- Izkata 6y ago
  I think it's more to get as much context as possible. One of our older products just sets window.onerror [0] to a small function that sends the information back to the server, which then forwards it to Sentry. The information in Sentry is nowhere near as detailed as if it came from Sentry's library, but it's been enough for us and doesn't seem to miss anything. [0] https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror https://developer.mozilla.org/en-US/docs/Web/API/GlobalEvent...
stephenr 6y ago
I guess it depends what you mean by error logging specifically. I added a pretty barebones “report js errors to the backend” script in about 1.1k uncompressed/unminified. It’s possible it doesn’t catch all errors I guess but I can’t imagine what 56K of js just to catch and reports is doing.
- stephenr 6y ago
  Having read that section you linked now, ours is similar to his “not enough” example. I’d say probably 99% of the error reports we see from it are a third party js script not loading (Sometimes a network issue, sometimes a plugin blocks them) we’ve pared third party loads down to just the payment gateways, but they’re still the vast majority of reports we see). However it’s also not js heavy, so that type of error logging solution works well for us.
SahAssar 6y ago
I use sentry but call the API directly. So my overhead is basically try-catch with a fetch sending the data in the catch. I don't get sourcemap mapping, but I can send along enough metadata to find the issue in most cases,

jbob2000 6y ago

There are many ways the browser can fail. I'm sure their SDK is large because of all the random hacks they need to use to capture everything from every browser. Couple this with the need to create first-class API, which adds some code bloat, and I can see how this ends up at 17K compressed.

seanwilson 6y ago
Why can't they do the shim approach while the library loads though? Google Analytics for example lets you push everything you want to record into a plain global array called "ga", and when the library loads, everything in the array in processed by the library. This lets you start capturing events without waiting for the library to load.
- the_gipsy 6y ago
  it's a bit different though, you can't "push" errors somewhere, I guess so many error handlers and interceptors are set that it's not worth to split.
  - seanwilson 6y ago
    > you can't "push" errors somewhere Why? Can't you push the Error object or stack trace into an array to await processing?
    - jbob2000 6y ago
      What if the thing that is pushing the error object has an error?
Izkata 6y ago
I think it's more to get as much context as possible. One of our older products just sets window.onerror [0] to a small function that sends the information back to the server, which then forwards it to Sentry. The information in Sentry is nowhere near as detailed as if it came from Sentry's library, but it's been enough for us and doesn't seem to miss anything. [0] https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror https://developer.mozilla.org/en-US/docs/Web/API/GlobalEvent...

stephenr 6y ago

I guess it depends what you mean by error logging specifically. I added a pretty barebones “report js errors to the backend” script in about 1.1k uncompressed/unminified. It’s possible it doesn’t catch all errors I guess but I can’t imagine what 56K of js just to catch and reports is doing.

stephenr 6y ago
Having read that section you linked now, ours is similar to his “not enough” example. I’d say probably 99% of the error reports we see from it are a third party js script not loading (Sometimes a network issue, sometimes a plugin blocks them) we’ve pared third party loads down to just the payment gateways, but they’re still the vast majority of reports we see). However it’s also not js heavy, so that type of error logging solution works well for us.

SahAssar 6y ago

I use sentry but call the API directly. So my overhead is basically try-catch with a fetch sending the data in the catch. I don't get sourcemap mapping, but I can send along enough metadata to find the issue in most cases,