In Arcade, we highly appreciate the Pareto Principle and have a similar approach in defining how the system should work. Pareto Principle states that roughly 80% of consequences come from 20% of the causes. Translating it to the Arcade context – by providing the very core components we can let products build 80%+ of their product UI.
The hardest part though is to get them done right. It's not just the framework experience you need but also design system development experience. That's what makes us different in the area with 10 years of working on design systems. We've worked on products of different size and scale. We've seen libraries that expose thousands of components, so it becomes unreal to use them for your product. We know which components are product specific and which parts you need every time you start something new.
That said our main goals are:
Regarding the last item, we know that every product is special, and these 20% may differ by a lot. We explicitly say that we don't know what those 20% will be, but it's our mission to let you solve it with our help.
Accessibility is not a buzz word for us, but a responsibility to provide equal opportunity for everyone. We take care of the accessibility related implementation details like aria attributes, keyboard navigation and focus management. This means that most of the time it should just work in the product. In case any additional context should be provided to the components on the product side, we explain how it can be done in our documentation.
Arcade components start with Arcade provider that is responsible for a number of global features like theming, RTL handling, focus ring management etc. Having a central entry-point makes it different from some other libraries where every component is isolated and gives us an opportunity to provide more features and optimizations out-of-the-box.
A lot of other libraries let you customize their design with css overrides. It works great in short term but in long-term it makes the future migrations much harder and even minor releases might become breaking for you. In Arcade, we're seeking for the right balance in this question. Our components look very simple and can be customized with theming. On the other hand, we keep them together as a system and tweaking a token value in a theme will keep your product UI consistent.
When you have dozens of components that work as a system, there is huge responsibility to handle breaking changes well. To keep the system usable in long-term we have a clear release strategy and will be providing guidelines and scripts for easier migration. Every time new functionality is added – we're making sure it's future-proof and can be scaled if needed.
We're keeping as few runtime dependencies as possible for avoid getting your product on the libraries you don't really need. Currently, our only runtime dependencies are React and ReactDOM, which are peer dependencies for us, and their version is picked by your product.
We're keeping as few runtime dependencies as possible to have better control over bundle size. No more endless css-in-js solution or 3rd party component dependencies you have to include into your project.
Our current dependencies:
Even though our codebase is private, we have a public repository available for reporting issues, requesting features and starting discussions.