Consider bundle size

[brambow]

Feature Request

Consider the total library size.

Problem description

Fluent is significantly larger than comparable options, including it's spiritual predecessor SUIR. (244kb gzipped vs 83 for SUIR). While apps that treeshake can reduce the size, I've noticed it's still pretty large. For example, I've been working on a library that uses Fluent, but only imports 10 of Fluent's components and the gzipped size is still over 100kb.

https://bundlephobia.com/result?p=@stardust-ui/react@0.40.3

Here's an example of what stardust is taking up in my library once treeshaking occurs (using source-map-explorer):

According to this, the 10 stardust components I'm using account for 15% of my overall application size at 230kb (All the application is doing here is displaying a Mapbox map)

Proposed solution

I'm not really sure. I know a library that considers so much, like accessibility and theming, and has so many components out of the box might be bigger than something like Rebass. But surely there are some opportunities to reduce size. For example, there's a ton of places where you're importing the full lodash library, only to use one function, like _.get(). In those cases, wouldn't it be better to import the individual lodash es modules?

I think Fluent has a lot to like, but its size concerns me a bit and definitely has me looking at other alternatives.

[astegmaier]

I tried to do some debugging and testing to measure the impact of importing and using @fluentui/react, and I found some things that might be helpful.

First, I noticed that if I started with a simple "Hello World" app, and added only:

import { themes, Provider } from "@fluentui/react";

const App = () => (
  <Provider theme={themes.teams}>
    <div>Hello from App2!</div>
  </Provider>
);

The tree-shaked, minified bundle size of my app increased by ~800k (!). When I looked closer at what was happening, I found that if I didn't import the entire themes object, and instead directly imported the teams theme, I could get this down to 753k.

Besides that, I found three main reasons for the large size:

1. As @brambow mentioned, the project frequently imports external dependencies like lodash with statements like import * as _ from "lodash" instead of more granular imports like import { get } from "lodash", so more of those dependencies gets imported than necessary.
2. Importing a theme implicitly loads all the svg icons used by that theme, even if they are unused.
3. Importing any theme implicitly loads the code for most of the components in the library (e.g. Dropdown, Menu, etc.), even if they are unused.

Fixing (1) should be pretty straightforward. Fixing (2) and (3) to allow this code to be "pay-to-play" would require some more thought from someone who understands the internal structure of the library, but it should be doable.

Below are the details of my analysis (which you can see in this excel file).

You can also repro the issue yourself from this repo.

[layershifter]

Thanks for digging this!

1 is not an issue as we use babel-plugin-lodash to handle this:

fluent-ui-react/build/babel/index.js

Line 38 in ddf6298

isDistBundle && 'lodash',

You can check our dist files on CDN, for example: https://cdn.jsdelivr.net/npm/@fluentui/react@0.43.1/dist/es/components/TextArea/TextArea.js

import _invoke from "lodash/invoke";
import _get from "lodash/get";

[astegmaier]

@layershifter - thanks for taking a look!

You're right that the build imports of lodash in the es6 bundle files look granular, so my guess about what was causing so much lodash code to make it into the final tree-shaked bundle was mistaken.

I think (probably) something is still going wrong, though. Below is an image of all the stuff from lodash that makes it into my final tree-shaked bundle. There's a bunch of files that I don't see referenced anywhere within the project (e.g. _deburrLetter.js, _unicodeWords.js, etc.). I'll do some additional debugging to try and understand why this happening, but I'm all ears if you can think of the reason.

EDIT: After looking closely, it looks like there are actually some things (about half of them) in the lodash package that are not in the final tree-shaked bundle, so I think tree-shaking is probably happening, but there's so much stuff because lodash is used extensively in @fabricui/react. Let me know if that makes sense to you - if yes, this is probably not a low-hanging-fruit way of reducing bundle size.

Lodash all-in was only contributing 38kb to the bundle size, though - even if we can't fix this issue, I think the biggest bundle size wins will come from addressing (2) and (3) above. It looks like #2320 should help with (2) - thanks for pointing me to that!

[layershifter]

For 3, yesterday we discovered multiple issues #2324 and going to fix them #2325.