Overview

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:

  • Provide core components responsible for the complex UI behavior every product has to implement
  • Give access to the system functionality shared across core components and your product, like RTL styles, theming and utilities for common features
  • Solve 80% of the product UI challenges, assist with the remaining 20%

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.

Focus areas

Accessibility

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.

System-wide features

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.

Customisation through theming

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.

Long-term maintenance

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.

Fewer dependencies

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.

Tech stack

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:

  • React + ReactDOM: Runtime peerDependencies
  • PostCSS with a bunch of plugins, used only during the build process
  • Typescript, optional and used only during build process

Community support

Even though our codebase is private, we have a public repository available for reporting issues, requesting features and starting discussions.