Skip to content

Conversation

@gordonbrander
Copy link
Contributor

@gordonbrander gordonbrander commented May 13, 2024

@gordonbrander gordonbrander changed the title 2024 05 13 minimal component set Design for a minimal component set May 13, 2024
@gordonbrander gordonbrander changed the title Design for a minimal component set A minimal declarative component set designed for LLM generation May 13, 2024
Comment on lines +43 to +49
- `<hstack>` - flexbox with row flex direction.
- Attributes
- `gap` - creates a gap between items. Defaults to a standard gap size.
- `<vstack>` - flexbox with column flex direction.
- Attributes
- `gap` - creates a gap between items. Defaults to a standard gap size.
- `<spacer>` - an empty element with aggressive flex grow and flex shrink to allow it to fill additional available space.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No <grid>? You can jerryrig one using stacks I suppose.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we want to avoid fine-grained visd primitives for now, in favor of use-case specific declarative/semantic layout components.

I think flexbox is a minimal layout module that should work for everything else. Notable to me that React Native and SwiftUI have both converged around it. And hstack/vstack/spacer offer the minimal markup surface.

- `<button>`
- `<textfield>`
- `<rich-textfield>` - can wait
- `<input type="text">`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<input type="number> is another good candidate imo

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idle thought, if we integrate models like Whisper we could even have an input type to accept voice/audio.

@cdata
Copy link
Contributor

cdata commented May 14, 2024

Take the following with a grain of "chris wouldn't have put in the effort to write a whole RFC for an experiment so maybe he should keep his opinions to himself."

Not stated in this RFC (but I, for one, would enjoy reading) is a rationale for why an off-the-shelf component set and/or state management solution is not considered. At the surface level, it seems like the shortest path to answering a question like, "can an LLM organize basic declarative components into something more useful," is one where the components and/or state management does not need to be implemented from scratch.

(Thanks for being bothered to write this BTW)

@gordonbrander
Copy link
Contributor Author

@cdata do you have a component library in mind? Would be a great exercise to take it and figure out the delta between it and our requirements

@cdata
Copy link
Contributor

cdata commented May 14, 2024

No, I didn't have a library in mind. But, there is so much unmentioned prior art for the web as to make me wonder about the rationale for something brand new. Authoring good/robust components from scratch is a time consuming and thankless exercise, after all.

For some token cases of component libraries, I would suggest picking apart https://ui.shadcn.com/ or https://shoelace.style/.

@gordonbrander
Copy link
Contributor Author

TY! I'll dig into these.

@jsantell
Copy link
Collaborator

jsantell commented Mar 5, 2025

Closing out stale PRs, please reopen if this is relevant

@jsantell jsantell closed this Mar 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants