Question: Appetite for implementations of SwiftUI Components

[fbartho]

I just learned of this project today, so forgive me if I missed a strategy/vision document that I should have read. I'm thrilled about this project and what it makes me think I can do with it 😊. Super cool!

I was curious about a few things:

• Is it unwise to desire a full parallel of most of the basic SwiftUI components within ElementaryUI?
• Would it even be possible for the majority of components? (The question is more: are you immediately aware of a reason why it wouldn't be possible).
• If it is possible, could someone dynamically (at build-time) swap between implementations? (so that many components could be used on either platform)
• Would you consider merging such a thing in (assuming code-quality, approach and other similar concerns are addressed)?
• Structurally I could equally see it being an additional repo

I totally understand if this doesn't align with your vision for this project. I've just been itching for a great (quality/usability) web development experience that more closely parallels native development.

Feel free to tell me to buzz off, and cheers!

[sliemeobn]

thanks for the nice words and for reaching out!

it is definitely not unwise to desire more SwiftUI-compatible APIs or components - I really wanted HStack / VStack and the like - but here there be dragons...

maybe I just lack the fantasy, but there simply is no way to map SwiftUI's layout system to CSS stuff (flex, grid, ...) directly. sure, you can kind of map a few things, but things like spacers or frame alignment/sizing just will not work the same.

my conclusion: if you want these layout primitives to function identically, you would need to rewrite the entire SwiftUI layout system, including runtime overhead and binary size costs, and leave CSS-native stuff mostly unused.

so I think for most cases this is simply too high a price for "I can partially use the same UI code".

another problem I see with going after SwiftUI parity is the constant maintenance burden of keeping it up-to-date - rethinking how to map stuff to the web for every new API addition. not a trivial task...

I think the "better" approach is to add a "Layout and Styling" layer that has a "SwiftUI-feel but a CSS function". Think FlexRow/ FlexColumn instead of Stacks. I started this work in ElementaryFlow and I want to publish a 0.1 soon-ish. (I'll make some noise about it when it is out).

One part I do think could be very nice to port over are "semantic elements", like Button or List that take a ButtonStyle or a ListStyle through the environment. This, however, does add a bit of runtime indirection, so not sure if that is always the right trade-off.

All of that said: I am not opposed to this in the slightest - if somebody wants to give it a go I am happy to collaborate. I think a separate package would be a good home for such a "SwiftUI compatibility shim" layer anyway.

You want it, you build it ; )

[laosb]

One part I do think could be very nice to port over are "semantic elements", like Button or List that take a ButtonStyle or a ListStyle through the environment. This, however, does add a bit of runtime indirection, so not sure if that is always the right trade-off.

Not in ElementaryUI, but in Elementary (the server side version), but I do find myself creating my own Button, Menu and thing alike that adapts its styling by passing a semantic container type internally. I find this SwiftUI abstraction plenty helpful in creating application UI, even what I have is just HTML and HTMX stuff.

The problem, is that in Web App landscape, everyone wants their own style of every primitive element ever. I'm currently building on top of (paid) Tailwind Plus elements, but I find it difficult to build a unstyled abstraction. To do that I either need to find a mature unstyled ("headless") web component library (which Tailwind Plus has but it's not open source and requires a license), or implement all that a11y magic again in Swift. This is unfortunate.

[sliemeobn]

@laosb I agree, it's definitely not just a trivial "copy-paste". As you say, there is no "default button style" or similar for the web.

I will require some thinking and a few careful design decisions before bringing these higher-level components to life.
for that reason I tried my best to not "burn" types like Button or List already - we can have them once we are sure how they should work. (or, of course, locally in every project as they see fit)

[fbartho]

I too have been struggling with the "Frameworks Don't Play Nice With Each Other + You Always End Up With a Framework" problem that you describe @laosb.

And I appreciate what you're saying @sliemeobn re: burning basic type-names too early. So we should definitely experiment in a way that doesn't hog the stage.

I have this perception, perhaps a naive one, that it's possible to describe a UI layer with a pluggable model, but that still comes with good defaults, and that can interoperate between frameworks without the frameworks specifically knowing about each other.

And my perception is that SwiftUI (eg. with things like @Environment, ButtonConfiguration, ButtonStyle) or in the olden-days UIKit (with things like UIAppearance) were closer to that hypothetical world than CSS & JSFrameworks today.

My experience with html, css, and modern frameworks seems to show that Raw CSS & HTML have defaults from a previous era, and oh-so-many quirks. Encapsulation is not granted for free, and everything is made of escape hatches and optional things that interact weirdly.

This also means that every damn project I have to either adopt a single framework (such as Tailwind) or write everything from scratch. And building from scratch is incredibly challenging when you have high expectations for accessibility.

I want to be building with lego blocks and have a 3D printer to invent new blocks. I don't want to be working with tweezers and grains of sand to build the town. Every block should snap together, fit our design system, be accessible by default.

---

A complete side-thread is that rust-wasm is a developing thing presently, and since Swift-Native has the advantage on the UI Ergonomics side; with ElementaryUI there's a chance here to claim the web as the React successor / web-UI leader for WASM.

[sliemeobn]

@fbartho "let's make it happen"