I have used RAC heavily over the past year.
The experience was mostly great, but I’ve encountered more rough edges and limitations than I’d expect from a headless & composable component library of its caliber:
🧵
Why you should use React Aria:
• It has 50+ components, including complex ones like data tables, trees, date pickers, color pickers, and tons more. No need to combine multiple libraries to build your app.
• It has complex interactions like accessible drag and drop, keyboard multi select, form validation, virtualization, and table column resizing built in.
• It is optimized to feel great on touch screens. No weird sticky hover states, conflicts with text selection, etc.
• It’s battle tested for accessibility across devices including mobile, going far beyond the ARIA Practices guide.
• It has internationalization built in, including localized strings, support for many calendar and numbering systems, etc.
• It has a compositional API. Combine components together to create custom patterns.
• You get full control. The components are already pretty flexible but if you need even more you can drop down to the hook layer and customize everything.
• Great documentation including interactive examples, guides, agent skills, etc.
I’m biased but nothing else comes close to this level of functionality, quality, and customizability in one package.
I’m sharing this because it would have been useful for me to know about these issues.
I feel like tradeoffs in frameworks & libraries are severly undocumented.
It may not be fancy to bring them up, but they are just as important as features when deciding for one.
There were more, smaller issues that I don’t remember anymore, but it doesn’t matter.
I am not sharing this to make RAC look bad — it’s an awesome library, built by smart team of professionals.
The sweet spot for Docker in development is to let it run your accessories, like database, Redis, ElasticSearch, but stick to native installations of Ruby/JavaScript/whatever using mise. No "works on my machine" version drift, little fuss, great performance 👌
The problem with the "if it works who cares what the code looks like" mindset for agentic work is that it assumes the agent has a perfect understanding of "works." Realistically, things are underspecified, agents make bad assumptions, etc.
To be fair, agents are pretty good at unit test coverage. They're pretty bad at designing human experiences (API, CLI flags, etc.), especially cohesive ones for future roadmap plans they may not have visibility into (unless your backlog is perfect and vision fully laid out, which I doubt). They're bad at knowing where performance matters and what type (CPU vs memory tradeoffs). They're bad at where compatibility matters and where it doesn't (and tend to err on the side of preserving it without further guidance). Etc.
Unless you have this ALL specified, you can't possibly claim "it works" without taking a look and thinking about it.