Browser library bundle size is very large.

Hi! While looking into using Datadog RUM, I noticed the bundle size is much bigger than I’d expect: @datadog/browser-rum bundle analysis. Currently it’s about half the size of our entire UI component library, including styles.

Most of this comes from @datadog/browser-core and its dependencies.

While there’s a lot of code in the packages themselves, the size is mostly inefficiency in dependencies and bundling. This is good! It’s the easiest to cut down.

Likely highest gains:

• Inline merge and assign functions in the project instead of using lodash. The two lodash imports account for almost 25% of the total size.
• Consider switching from tsc to rollup, possibly using tsdx to save headaches. Rollup is specifically designed for building self-contained libraries, and will avoid the tslib dependency (the second largest after lodash).

[BenoitZugmeyer]

@fdc-viktor-luft We did consider creating a package supporting only ES6 syntax. It didn’t yield significant-enough results to justify maintaining such package right now. Because IE11 will be retired in june, we will reconsider it and may drop IE11 altogether.

[BenoitZugmeyer]

We just realized an audit of our SDK bundled size. Here are the main efforts that we will work in the coming weeks/months:

• #1335 Drop old browsers support when computing stack traces. While the SDK support only IE11 and newer browsers, we still have some code to support very old browsers when computing stack traces. Let’s remove it.

• #1354 Tweak build-env setup to improve dead code removal. We currently have build flags to produce slightly different bundles for tests. This setups could be improve to allow more dead code removal in release bundles.

• #1364 Use const enum when possible. We currently have large TS enums that are used accross the SDK, using const enums would help to reduce the bundle size.

• #1347 Remove TSLib usage. We barely use it and could cause a big size overhead if it’s not tree-shaken (depending on NPM users build setup)

• Avoid using class syntax. This syntax is hard to mangle, especially when transpiled to ES3

• Avoid using optional chaining and nullish coalescing operators, which often produce more code than expected when transpiled.

Other notes:

• we experimented using another bundler (ex: rollup), and it didn’t have a significant impact size-wize. We are using a custom ESLint rule to ensure that most of our codebase is side-effect free and can be tress-shaken by terser almost as well.

• we are considering using code-splitting, so various parts of the SDK could be loaded only if needed. This would be a breaking change, so not actionable right now, but definitely something to keep in mind when the occasion presents itself.