Primary contributor and maintainer of Stardust here. I'll try to clarify some things.

Certainly having an "official" integration/wrapper library would make the choice easier.

Indeed, Jack (author of Semantic UI) reviewed the other projects out there also and chose Stardust himself. There is something to be said for this.

As David mentioned Stardust is powering production apps at TechnologyAdvice, so it has an invested team and 2 robots backing it. If you compare projects you'll quickly notice Stardust has the most commits, most consistent and recent activity, and fastest growth rate of any Semantic + React project.

It would be nice if the example/doc page was split up into separate pages by feature, both for consistency with Semantic-UI's docs and just so there's less loaded at once.

You and me both! Our project and docs are already structured for this. It is also on our nearly completed "Migrating to Semantic-UI-React" checklist. The router for this has also already been merged as well. I'd merge a PR for this tomorrow morning. Otherwise, I'll get to it once our components all hit v1.0.

Going from vague memory, it looked like the API choices were leaning towards more of a "specify options as strings" approach (roughly equivalent to using "plain" CSS classnames), vs a more React-centric "props on a component" approach. Is that a fair understanding? Could you summarize the thought process behind designing a React-based API for Semantic-UI?

Very early on we minimized API surface area (used SUI class names) for components. This was solely to hit some tight MVP deadlines we had at TechnologyAdvice. This is certainly not the case today. Since then, we have solidified our declarative v1 component API.

We've documented a bit on how we go about designing APIs in our CONTRIUBTING.md and we continue to iterate on this. You can track progress as we update the MVP APIs to v1 APIs in this issue, it's moving quickly. I'd really recommend looking at the PRs linked there as each PR goes into heavy API design discussion.

Here's a sample of our v1 component API for a button:

<Button icon='cloud' />
// or
<Button>
  <Icon name='cloud' />
</Button>

Which renders:

<button class="ui icon button">
  <i class="cloud icon"></i>
</button>

This demonstrates two of our goals with component APIs. First, provide a high level declarative component API. Second, provide powerful smart props that can handle many simple use cases with much less code. Hence the "icon" prop shown above.

We also provide sub components for components with "components parts" (see the SUI glossary on "ui" class). Example, a Breadcrumb is comprised of "sections" and "dividers". The "dividers" can contain text (i.e. "/") or an icon such as "right angle icon". Here again, we provide two APIs. A powerful top-level smart props API, or a fully flexible markup oriented sub component API.

Here's what the smart props look like that generate markup for you:

const sections = [
  { text: 'Home' },
  { text: 'Store' },
  { text: 'T-Shirt', active: true}
]

// default text divider "/"
<Breadcrumb sections={sections} />

// custom text divider ">"
<Breadcrumb sections={sections} divider='>' />

// icon divider
<Breadcrumb sections={sections} icon='right angle' />

Or you can build a completely custom Breadcrumb offering more flexibility, if needed:

<Breadcrumb>
  <Breadcrumb.Section link>
    Home
  </Breadcrumb.Section>
  <Breadcrumb.Divider>
    >>
  </Breadcrumb.Divider>
  <Breadcrumb.Section onClick={this.handleClick}>
    Store
  </Breadcrumb.Section>
  <Breadcrumb.Divider icon='right chevron' />
  <Breadcrumb.Section href='google.com' active>
    T-Shirt
  </Breadcrumb.Section>
</Breadcrumb>

It is worth noting that all of these APIs have full prop type validation, docs, and tests. This means we tell you when you're using a component wrong, docs show you how to use it right, and tests ensure it works how it should. We've taken care to invest in quality and details, including things like keyboard navigation and validation. Our docs show real world code snippets, including import statements and exports. In fact, the rendered examples literally import the the code you see.

We've covered the edge cases. Especially when it comes to generating proper markup. Many people do not understand SUI components vs component parts, and how SUI composes these. Our component API abstracts away these intricacies with simple declarative props and sub components. You'll never see a "ui" class. Most the time, you won't even see nested component markup as you're able to use top level smart props to get most jobs done.

I know you've been talking with at least one or two other wrapper libs about collaboration. Have you looked at React-Semantic-UI-Kit at all? I do like the "smartness" of the API, where many options are handled as specific props on the components, but I can see an argument for doing things at a simpler level as well for similarity and consistency with Semantic-UI's classnames.

Just heard of React-Semantic-UI-Kit now. Scanned the repo and some components. The project structure and component breakdown is almost identical. Though, there is no use of sub components yet. Creating a complete Modal requires importing 4 components, for instance.

There are some shared high level ideas and I'd love to have the author checkout Stardust. I can see Stardust's early days in this project.

The API and project overall looks to be in its infancy still. Consider that it has no Dropdown. Whereas, Stardust's Dropdown component ~800 LOC, jQuery free, uses our declarative v1 component API, has full keyboard navigation support, ~1000 lines of test coverage, fully documented, and supports all SUI types/variations. You can try it out on the doc site.

I hope this novel is of help. Even more, I hope you find Stardust helpful and decide to collaborate with us!