Reakit: Comparison with Rebass and others

[romainquellec]

Hello.
I love styled components, and use mainly my components and sometimes Rebass.
I think an article or something to talk about reas in comparison with Rebass can be usefull.

Thank you for the work on reas !

[diegohaz]

Hi, @romainquellec. I can write a more detailed article, but here are some thoughts:

• reas can be amazing in the future, but right now it's an experimental project (hence v0.0.x). Rebass seems to be more consolidated, ready to use in production;

• Probably, Rebass is more performatic than reas. I'm not sure about that because I still didn't measure perfomance here (any help is welcome 😁);

• Rebass has an is prop that changes the underlying HTML element. From reas side, as is more powerful, that's the core functionality here. Besides just replacing the element, it can combine multiple components;

• reas isn't just a bunch of components. It's a component system. You can easily create your own components with all reas goodies by just using the as enhancer:

  const MyComponent = ({ as: T, ...props }) => <T {...props} />
  
  export default as('span')(MyComponent)
  

• As far as I know, Rebass doesn't provide stuff for you to control the state of your components. You must implement it by yourself. While all reas components are stateless, the lib provides state enhancers and behavior components to ease that work. Of course, you can always implement it by yourself, using React state, redux, mobx or anything else;

• Rebass components aren't WAI-ARIA compliant by default.

cc @jxnblk

[jxnblk]

Definitely intrigued by this library, but I'll chime in to how I see these as being different concepts.

• First and foremost, Rebass is built with design systems in mind and allows a ton of customization – more so than what I've seen in other UI component libraries like Material UI, React Bootstrap, et al.
• Rebass is built with styled-system, a low-level set of utilities that can let you build your own component library from scratch with a lot of the benefits of Rebass.
• Rebass can be great for starting out a project or prototype, and it's meant to be extended to fit your visual styles – e.g. the Button component has a lot of the boilerplate styles you'd write anyway, but also lets you customize it completely with Button.extend
• The current version of Rebass also includes a higher-order-component (similar but different to reas) and a configuration-driven component factory function.
• I doubt that performance is much of a concern for either of these libraries – there are probably more gains to be had for performance within libraries like styled-components and with generally how you architect your application.

Rebass has an is prop that changes the underlying HTML element. From reas side, as is more powerful, that's the core functionality here. Besides just replacing the element, it can combine multiple components;

This is probably the thing I understand least about reas (and am most curious about) – I don't understand what it does nor why I would want this. Would love to see some more documentation and explanation for the rationale here in the docs. I'm planning on taking a look later, so forgive my ignorance.

For Rebass, I've preferred to keep things a little more React-like by using props. If you want to change the underlying element, you can do things like this:

const ButtonLink = props => <Button is='a' {...props} />

As far as I know, Rebass doesn't provide stuff for you to control the state of your components. You must implement it by yourself. While all reas components are stateless, the lib provides state enhancers and behavior components to ease that work. Of course, you can always implement it by yourself, using React state, redux, mobx or anything else;

This is correct, but architecturally I don't think it makes sense to keep state in low-level UI components like Rebass. For applications, I try to make good use of React's functional setState and have a small library that wraps some of that sort of thing up here: https://github.com/jxnblk/refunk

Rebass components aren't WAI-ARIA compliant by default.

I'm not sure I understand what reas does to be WAI-ARIA compliant by default – I think there's a lot of general misunderstanding about accessibility in the field and want to clarify that it's not really feasible to have accessibility features built in to Rebass beyond what it does now. Rebass uses semantic HTML elements where appropriate, so there's no need for aria attributes (when you use the Input for forms for example), but you do need to handle accessibility on your end, just as with any other HTML you may write. E.g. if you have an <img> tag, you need an alt attribute, and with Rebass, you should use alt attributes on the Image component.

Anyway, hope that's helpful, and I'm curious to see where you go with this library

[diegohaz]

Thank you for commenting, @jxnblk.

This is probably the thing I understand least about reas (and am most curious about) – I don't understand what it does nor why I would want this. Would love to see some more documentation and explanation for the rationale here in the docs. I'm planning on taking a look later, so forgive my ignorance.

Documentation should be improved for sure. as is inspired by Semantic-UI's augmentation feature, which is very similar to Rebass is. In reas, it does the same thing, except that it also accepts an array of components.

Besides that, it can be used in different ways, for example:

• Component.as(string | string[])
  ```js
  import { Button } from 'reas'

const ButtonLink = Button.as('a')
```

• <Component as={string | string[]} />
  ```jsx
  import { Button } from 'reas'

const ButtonLink = props =>
```

• as(string | string[])(Component)
  ```js
  import as, { Button } from 'reas'

const ButtonLink = as('a')(Button)
```

Maybe we should focus on just one API. But, as a good experiment, I would like to see how people will use it.

I think there's a lot of general misunderstanding about accessibility in the field and want to clarify that it's not really feasible to have accessibility features built in to Rebass beyond what it does now. Rebass uses semantic HTML elements where appropriate, so there's no need for aria attributes

By "WAI-ARIA compliant by default" I mean applying roles and aria attributes on those components which can't be easily inferred by a screenreader. Tabs is an example. According to https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/#tabpanel the element should have specific roles, aria attributes and keyboard interactions (which isn't possible to provide without providing some sort of state helper in the lib).

I'm not sure if the library should implement it or let it to the developer. But I'd guess that in the latter situation most developers will not implement any of these a11y stuff, and that's bad for people who need it.

[diegohaz]

FYI, I've added some benchmarks comparing reas with other libs: https://github.com/diegohaz/reas#performance

[Slapbox]

@diegohaz that link doesn't go anywhere. Is there a newer link?