Is it me or react-aria have a larger bundle-size than similar libraries?

[johny-ss]

I left headless UI out of the comparison since it is not intended to be such a complete set of components and the comparison would be unfair.

react-aria.components is 165 kb.

Ariakit is 39 kb. I know it has fewer components and functionalities, but I don't think it can be explained by that reason alone, since it is 25% the size of RAC.

radix is difficult to compare since they do not have a package with all the components. I tried the following options:
@radix-ui/themes: 80 kb. I see that it has many components, I don't know if all of them
radix-ui: 49 kb. A year ago someone made a package grouping all the radix components

I would have thought that since react-aria was lower level and shared so many hooks between components, the bundle size would be smaller, but it doesn't give me that feeling.

Could it be that react-aria's size is not optimized?

[devongovett]

Hard to compare apples to apples when you are comparing the size of the entire library. React Aria has a lot more features than the ones you're comparing it with, so the total size of everything is going to be larger no matter what. You would need to compare the sizes of individual components rather than the whole thing.

[reidbarber]

We have an existing issue for doing some cleanup in usePress at #1720 (includes removing the fallback for pointer events).

---

I think all the libraries you mentioned are great, and are preferable to building these features from scratch. I think doing a detailed comparison of the menu components would require some time to test across an array of devices and assistive technology. In terms of DX, I would highlight React Aria's Styling and Advanced Customization sections of the docs. Also, features such as internationalization and drag and drop may be important to your apps, so consider those features as well.

[devongovett]

fwiw, there are some tree-shaking issues at play here as well. I believe bundlejs uses esbuild under the hood. I submitted an issue over there for one issue that affected bundle size a lot: evanw/esbuild#3561. This was fixed in the latest version but not sure if it has made its way to bundlejs yet. Another issue was #5645 which caused textfield to always be included no matter if it was used or not, which should be fixed in our next release. Those two changes seemed to make it a lot smaller, but I'm sure there's more we can do.

[devongovett]

In regards to pointer events, I think we could remove the fallbacks, but my guess is that a lot of unit tests rely on them still since JSDOM still does not support them (jsdom/jsdom#2527). But perhaps we could gate the fallback behind a process.env.NODE_ENV === "test" check or something so it gets removed in production builds.

[johny-ss]

Thanks to both of you. I hope those changes on the way can reduce the bundle size 🤞

I love that RA does so much for web accessibility. However, an extra 10-20kb per component or 64kb for a button is definitely something I'm worried about.

In regards to pointer events, I think we could remove the fallbacks, but my guess is that a lot of unit tests rely on them still since JSDOM still does not support them (jsdom/jsdom#2527). But perhaps we could gate the fallback behind a process.env.NODE_ENV === "test" check or something so it gets removed in production builds.

Yes, that or move those tests to a real browser. Maybe they can be parallelized by mounting and unmounting on the same page to make it faster.

[devongovett]

Just tested, and after the changes, button is 8.1KB minified with esbuild and brotlied. But also keep in mind that the components share a lot of dependencies with each other (e.g. usePress), so if you use more than one component it will amortize a lot. You can't calculate the total size by adding up the individual components, you'd need to bundle the exact combination you are using.

Yes, that or move those tests to a real browser.

Would be nice, but I'm not referring to our tests, but all of the applications using React Aria. We can't control if they use JSDOM or not, and I think a majority do (it's the default in Jest for example).

[axelboc]

I've just tried implementing a very basic menu component with react-aria-components@1.2.0. I'm super impressed with the composable API, the detailed documentation and the UX capabilities for end users. 😍 So, thanks so much for that.

The only surprise is that the code below basically adds 185 kB to my Vite bundle, or 50 kB gzipped:

import {
  Button,
  Menu,
  MenuItem,
  MenuTrigger,
  Popover,
} from 'react-aria-components';

<MenuTrigger>
  <Button>Foo</Button>
  <Popover>
    <Menu>
      <MenuItem>Bar</MenuItem>
    </Menu>
  </Popover>
</MenuTrigger>

When I analyze the bundle, I see a lot of stuff that aren't used, like @react-aria/i18n, @react-aria/selection, @react-stately/selection, @react-stately/tree, useSubmenuTrigger in @react-aria/menu, etc.

I don't deny that the library is powerful, especially compared to the one I'm trying to replace (react-aria-menubutton) but this is quite extreme. I'd really like to avoid adding to the JS bloat problem if I can. I'll keep an eye on future releases in case tree-shaking issues are resolved in the future. 🙏

For what it's worth, I tried Ariakit as well and found an increase of 128 kB (38 kB gzipped), which isn't much better.

[devongovett]

Those are all used, they are dependencies of those components. Submenu might be able to be tree shaken when not used, but not sure how big of a difference it would make. Perhaps there are more ways we can improve the size, but good UX unfortunately requires a lot of code (I wouldn't call that "bloat") – at least until the browser gives us more tools built in (popover is coming).

[reidbarber]

It has been discussed before, but I want to emphasize the property of having so much shared code between components, which doesn't show itself when testing one component. For instance @react-aria/selection and @react-stately/selection get used by all components that feature selection, so you'll only load those once no matter how many components with selection you're using. Same for things like press interactions, focus handling, and more. The "Law of Diminishing Bundle Size Increases" I guess.