Why using react-aria components instead of MUI/AntD/Chakra or Radix/ReachUI(placemark.io)
placemark.io
Why using react-aria components instead of MUI/AntD/Chakra or Radix/ReachUI
https://www.placemark.io/post/components-react-aria
2 comments
React-aria hooks provide freedom tailor your own components w/o needing to work around the limitations of general purpose controls, while retaining correct interactivity behaviors (the hard part). React-aria has steeper learning curve but well worth it IMO, as I spent more time working around/hacking UI frameworks like MUI, Mantine, etc., to fit my needs that just comes naturally w/ react-aria. There is also react-aria-components (RAC) that went beta a couple weeks ago, which Adobe team is pushing at the start point, use hooks only when needed. Since RAC is just glue on top of hooks, only small incremental hit to bundle size, and lets you have cake and eat it too (e.g., I'm now using RAC 80% of time for declarative approach, also unstyled, and hooks for special cases). If want styled, can go spectrum -- also layer onto of hooks, there ay many options
“The first rule of ARIA is to not use ARIA”
I’m sure that argument is going to come up, but react-aria exists because accessibility in complex interactive applications is _hard_ and often _needs_ ARIA. The landscape of accessibility tools is fragmented, full of bugs, problems, and often _inaccessible_ (have you seen the cost of JAWS?).
I’ve been a proponent and supporter of using react-aria when using React. The developers of it really understand both the accessibility needs as well as “thinking in react” that is paramount for making applications performant.
If you’re using React and creating your own interactive component design system, you _should_ be using react-aria. As much as you think that you can make things accessible on your own, well, you’re probably wrong – but if you’re not, good luck getting an entire team to keep it up. You can’t expect everyone to know how to do everything – and frontend is already a very deep stack.
I’m sure that argument is going to come up, but react-aria exists because accessibility in complex interactive applications is _hard_ and often _needs_ ARIA. The landscape of accessibility tools is fragmented, full of bugs, problems, and often _inaccessible_ (have you seen the cost of JAWS?).
I’ve been a proponent and supporter of using react-aria when using React. The developers of it really understand both the accessibility needs as well as “thinking in react” that is paramount for making applications performant.
If you’re using React and creating your own interactive component design system, you _should_ be using react-aria. As much as you think that you can make things accessible on your own, well, you’re probably wrong – but if you’re not, good luck getting an entire team to keep it up. You can’t expect everyone to know how to do everything – and frontend is already a very deep stack.