Why is raven so big now?

[wheresrhys]

I was about to update Financial-Times/o-errors#40 to raven-js@3, but am disappointed to find the size of the component has grown by about a third since version 1... that's an extra 10k minified! I'm interested why this could be the case. In particular, delving through the issues I see that there was some effort made to remove TraceKit, as most of it was unused, but now looking at the source it's been reinstated?

[benvinegar]

Well, we added a lot of stuff:

• try/catch instrumentation (for complete stack traces in more browsers)
• breadcrumbs (and auto breadcrumbs instrumentation/configuration)
• XHR transport
• User feedback dialogs
• Synthetic traces via captureMessage

... to name a few. We've also removed stuff, like the client-side source/sourcemap fetching from TraceKit (Sentry does this all server-side). But for the most part TraceKit is still there, and is still a big footprint in the client code.

IMHO, that's a lot of value for "growing by about a third". After gzip, 3.6.1 is under 9kb. I've experimented with small changes that reduce the minified filesize (i.e. aliasing vars), but after gzip, the actual bytes remain the same.

[wheresrhys]

Fair enough. A few questions arising from that though:

• Our main pain point with sentry is the poor stack trace/context in ie9 and below. Will upgrading to v3 improve this?
• I'm not sure if it accounts for much of the code increase, but the user feedback feature, IMHO, should be a plugin. I can't see any organisation wanting to use it without making a conscious decision to opt in.

On the other hand, breadcrumbs looks like an excellent feature, probably worth the extra kb by itself.

[benvinegar]

Our main pain point with sentry is the poor stack trace/context in ie9 and below. Will upgrading to v3 improve this?

So, Raven 2+'s adds stack traces from IE10, Safari 7-9, and Microsoft Edge (there was an onerror regression from 11 -> Edge). It's definitely worth upgrading for those alone.

It's technically possible to generate stack traces from IE8/9 using arguments.callee hacks, but this doesn't work if any of your code uses strict mode. If you don't use strict mode, and this is something you'd like to see, we could add it.

I'm not sure if it accounts for much of the code increase, but the user feedback feature, IMHO, should be a plugin. I can't see any organisation wanting to use it without making a conscious decision to opt in.

It's mostly implemented via an external script. Raven.showReportDialog just loads that script using a dynamic script include (source).

[wheresrhys]

Thanks for the info. Fell a lot more confident about the upgrade now 😄

[benvinegar]

It's technically possible to generate stack traces from IE8/9 using arguments.callee hacks, but this doesn't work if any of your code uses strict mode. If you don't use strict mode, and this is something you'd like to see, we could add it.

Oops, I forgot this was already in the source (via TraceKit).

[benvinegar]

Relevant to this discussion: #716

[benvinegar]

So, after #716, I took some measurements from raven-js and some client libraries from competing crash reporting tools:

file	raven-js	A	B	C	D
minified	21.6 kB	21.2 kB	31.6 kB	26.8 kB	10.4 kB
minified + gzip	8.5 kB	6.9 kB	11.2 kB	10.4 kB	4.7 kB

raven-js fits right in the middle. But when taken into consideration how actively developed it is, and how much functionality it provides (most of these libraries do not have breadcrumb instrumentation), I'm pretty happy with the current situation.

I'm going to close this issue for now, but I appreciate you raising it – it resulted in #716 and forcing me to take stock of the situation.