I suppose your requirements are different. We want to deal with errors like we deal with inbox, fix issues until we have "inbox zero". On our case that is all the client we need. There's obviously more logic on the backend, but not much.
Yeah it needs to do that, but that likely means that deploying a particularly egregious bug will fill your inbox with repetitive and useless data. It should also give you information on the current user, the browser, locale, etc. None of that extra stuff is really extra, it's critical for quick debugging. It's also hard to get right, and doesn't preclude inbox zero in any way.
Internally we use Redis sorted sets to merge the errors into one entry on the inbox. We get the browser info from server HTTP headers. It's a cute list of errors that we regularly run trough.
Well, your error tracking solution is not simple as a javascript snippet then.
Good for all projects, but how much does the project at hand actually require? And adding dependencies later is a lot easier than removing them.