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.

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.

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.

> you can't "push" errors somewhere

Why? Can't you push the Error object or stack trace into an array to await processing?

What if the thing that is pushing the error object has an error?

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/GlobalEvent...

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.

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.

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,