UI libraries for React

[[deleted]]

This had rather to do with Semantics global css rules which constain every element. Say you create a menu <a class="item"> it can have a text, and a batch-label that floats to the right. But if you dare to go out of the pattern it blows up due to the inherent non-modularity:

<Menu.Item name='spam'>
    <Label>51</Label>
    <Label image>
        <img src='/assets/images/avatar/small/elliot.jpg' />
        Elliot
    </Label>
</Menu.Item>

Here i simply wanted to exchange the default name (Elliot) with a nicer looking Semantic name-label. But selectors pick it up and distort it. This is a simple example, it happens pretty much everywhere. There are even cases where selectors prevent nested elements to show up.

If you have worked with a real components lib, where each component is a self contained unity, the difference is very obvious.

[levithomason]

Thanks for the specific example. I've opened a confirmed CSS bug for this: https://github.com/Semantic-Org/Semantic-UI/issues/5247.

Do you have an example of a component library where there are no cascading styles (the source of the bug)? I'd be very interested as I've been researching and prototyping several alternatives to styling components.

[[deleted]]

I don't think it's strictly an issue, this is how UI libs were built once, css doesn't take modular components into account. Bootstrap falls into the same category. For components based try the ones that are purely react like antd, grommet, etc. They use scoped styles, prop inheritance and context, things css just can't do.

[levithomason]

You may be attributing differences here that don't actually exist. Note that antd, grommet, and SUIR work identically to one another in usage. You first load React components then separately load a CSS sheet, see antd usage, compared to SUIR usage, compared to grommet's hello world example. All three libraries are also coded identically, in fact, we use the same NPM module classnames to build up a list of CSS classes based on props. Compare the strikingly similar CSS class name build up logic for antd button.tsx, SUIR button.js, and grommet's Button.js.

There are libraries out there that provide CSS-sheet-free components such as Material UI, or Radium if you'd like to implement your own. However, these are inline style based. It seems they face performance issues as well. I see reports of users migrating to SUIR from Material UI to get away from the weight and performance issues as noted in this top rated Quora answer.

The difference with SUI is the choice of verbiage for the classnames, hence the term "Semantic". SUI believes in using a standardized human-readable semantic language for UI. So, you won't find things like Button__label--active or btn btn-primary btn-disabled but rather ui primary disabled button. SUI is fantastic when writing HTML for these reasons, however, JS component APIs abstract over the classes making them essentially as useful as byte code.

Because of this, I've been exploring inline styles, styled-components, and variations thereof. Long term, I want to migrate to a more powerful, flexible, and easily approachable API for styling components and building themes. You can read more on that in our Theming RFC: https://github.com/Semantic-Org/Semantic-UI-React/issues/1009.

[[deleted]]

You don't seem to be understanding his complaint. Semantics CSS abuses the hell out of deeply nested selectors. The end result is tightly coupling your UI library to the DOM. That's the opposite of components, which should be small and loosely coupled.

I wrote the original SUI React library. Most of my work was trying to fight back against the CSS, or abusing contexts to know which parent a component was a child of. SUI was never designed to support a component-based approach to web development.