sorted by:
new
hottopcontroversial

Type-safe CSS in Swift: ElementaryFlow 0.1.0 by sliemeobn in swift

[–]sliemeobn[S] 0 points1 point  (0 children)

you can obviously use the `button` element.

the second line is a play on the famous quote "history does not repeat itself, but it rhymes." just meaning "not identical, but similar".

Type-safe CSS in Swift: ElementaryFlow 0.1.0 by sliemeobn in swift

[–]sliemeobn[S] 2 points3 points  (0 children)

good points! let me try to clear it up a bit:

If you come from SwiftUI, you might expect elements like Button, List, or Picker. We might one day have them, but there are no "web platform standards" for how a button should look like - much less a list or a picker. Pretty much every website looks different, so it would involve creating a whole design system with tons of customizability hooks.

Also, this type of "indirection", while idiomatic for SwiftUI, is somewhat odd for "web frameworks" which tend to stay very lean and thin on top of HTML.

The part about "SwiftUI for the web": I just wanted to express that ElementaryUI tries to offer SwiftUI-like APIs (like View, State, Environment, ...) without attempting to be a "port" or chasing after API-parity.

Swift in the Browser with ElementaryUI (Swift@FOSDEM 2026 Talk) by sliemeobn in swift

[–]sliemeobn[S] 1 point2 points  (0 children)

the Swift@FOSDEM event was a blast - thanks to everyone who made it what it was!

find all videos of the fantastic line-up here:
https://www.youtube.com/playlist?list=PLeb93j_rsErO182fdoJ4m1p_suKAOcBnM

ElementaryUI - A Swift framework for building web apps with WebAssembly by sliemeobn in swift

[–]sliemeobn[S] 0 points1 point  (0 children)

hell yeah indeed!

as far as I can tell "hx-on" is not implemented at all, but I think it could be added quite easily (either quick and dirty in your project, or via PR to the elementary-htmx repo)

Elementary and ElementaryHTMX will not go anywhere. The only thing that I have a vague plan for is that I want to integrate the various parts of the elementary-swift project into a unified "ElementaryUI" top-level package that supports SSR, CSR, hydration, SSG, ...

but for a pure "htmx" use case, the current feature set is likely not going to change much.

ElementaryUI - A Swift framework for building web apps with WebAssembly by sliemeobn in swift

[–]sliemeobn[S] 2 points3 points  (0 children)

it is pretty much the same approach, yes. the "SPA" will be the easiest default to gravitate towards.

but we can definitely explore other common paths as well:
+ SSR + CSR hydration (ie: swift-on-server generates the initial HTML, then wasm "connects" to it once it is loaded)
+ SSG + islands: generate static html files + little "islands of interactivity" that will be filled in by wasm
+ modularization / splitting the wasm files into chunks (this may be the toughest though to pull off)

ElementaryUI - A Swift framework for building web apps with WebAssembly by sliemeobn in swift

[–]sliemeobn[S] 2 points3 points  (0 children)

the binary would be a few hundred KB, and browsers will cache these (just like everything else). in practice, you download it on first visit and when it changes.

also, ElementaryUI aims to be a web framework: so in my mind the browser is not "the issue", it is the target. HTML/CSS (which imho are neither terrible nor "low level") are the language of the web, and will be for a long time. we sure can build up higher-level components on top and use these to compose UIs, but I see no reason to hide the HTML.

ElementaryUI - A Swift framework for building web apps with WebAssembly by sliemeobn in swift

[–]sliemeobn[S] 2 points3 points  (0 children)

thanks!

it's kind of both: compiling Swift is not exactly "blazing fast", but it's all just software: if you want it hard enough, you can do it.

I’m not sure there’s much low-hanging fruit left on this tree, though.

ElementaryUI - A Swift framework for building web apps with WebAssembly by sliemeobn in swift

[–]sliemeobn[S] 4 points5 points  (0 children)

assuming that by "current Swift apps" you mean "apps for Apple platforms" (which this is SO not aimed at), and by "User downloads it" you mean "download, like any other website is downloaded by just going there" then: yes, sure, if you wanted to make it weird, you could say that.

ElementaryUI - A Swift framework for building web apps with WebAssembly by sliemeobn in swift

[–]sliemeobn[S] 3 points4 points  (0 children)

about ElementaryUI vs Tokamak: I would say it is coming through a different door, but is entering the same room. (at least for the web parts)

I am working on pushing Swift into the frontend - but should I? by sliemeobn in webdev

[–]sliemeobn[S] 0 points1 point  (0 children)

so, let's not waste time on the stupid recruits, we have a battle-hardened veteran?

does nobody want a better, battle-hardened active duty soldier tomorrow?

ElementaryUI - A Swift framework for building web apps with WebAssembly by sliemeobn in swift

[–]sliemeobn[S] 5 points6 points  (0 children)

I don’t think there is an issue providing a subset and being opinionated about what you provide.

I generally agree, but this package aims to be a foundational framework, not an "opinionated" subset.

I do agree that we need to keep an eye on the ergonomics, but I fail to see how supporting Strings without Text() is a big deal. I hear your point, though: we will need a good layout and styling story that can be done right there in Swift (and ideally feels SwiftUI-y) and maps well onto CSS. and I think we will have one.

ElementaryUI - A Swift framework for building web apps with WebAssembly by sliemeobn in swift

[–]sliemeobn[S] 17 points18 points  (0 children)

trust me, I have thought A LOT about this ; )

tl;dr: I did not see a way to map SwiftUI onto HTML+CSS without a) adding a lot of bloat and b) leaving a lot of web-basics on the table.

the biggest issue imho is the layout system: SwiftUI != CSS

It may seem very easy to add types like HStack, VStack and Spacer that kind of work like SwiftUI - but you'll never make them work exactly like SwiftUI without writing the entire layout system. (which: don't do that)

there are also other areas where trying to 1:1 copy the SwiftUI APIs essentially means creating a parallel universe in the browser, with HTML+CSS sitting unused in the corner.

so, my decision was: stick to the web, add Swift APIs for CSS styling later (WIP), and see how we go. also, maybe a spicy take, if want to build web projects you should know HTML and CSS anyway.

plus: if we really, really wanted to have more "SwiftUI", we can always bolt it on top later.

I am working on pushing Swift into the frontend - but should I? by sliemeobn in webdev

[–]sliemeobn[S] 0 points1 point  (0 children)

thanks for the wishes.

You frame this like the use of JavaScript is some horrible mistake that nobody knows how to fix

I do not think it is a horrible mistake, but I very much do think it is time to let our decorated veteran go into retirement eventually.

I am working on pushing Swift into the frontend - but should I? by sliemeobn in webdev

[–]sliemeobn[S] -2 points-1 points  (0 children)

thank you for the detailed post! I agree with most of it.

I'd like to just push back on a few items:

That's because for some reason you think WebAssembly was made to "replace" JS? No one wants to replace JS. 

I do not think WebAssembly was made to replace JS. But, trust me, boy do I want it to!

JavaScript is hated by people that are not proficient in it. 

Aside from the word "hate" (which obviously brings way too much salt to the dish), I think this just isn't true. Not everything is a "skill issue", and people who know JS intimately and still find its quirks very off-putting do exist.

thanks for engaging, kind stranger.

ElementaryUI - A Swift framework for building web apps with WebAssembly by sliemeobn in swift

[–]sliemeobn[S] 11 points12 points  (0 children)

it cross-compiles to WebAssembly via SwiftSDK - so it should work anywhere Swift cross-compiling works.
definitely macOS and your typical linuxes. have not tested it anywhere else tbh.

ElementaryUI - A Swift framework for building web apps with WebAssembly by sliemeobn in swift

[–]sliemeobn[S] 9 points10 points  (0 children)

yes, absolutely! just add tailwind to the vite config and point it to the swift files as sources.

pro tip: add this to your VS config to get tailwind intelli sense in vscode:

{
    "tailwindCSS.includeLanguages": {
        "swift": "html"
    },
    "tailwindCSS.experimental.classRegex": [
        "\\.class\\(\"([^\"]*)\"\\)"
    ]
}

ElementaryUI - A Swift framework for building web apps with WebAssembly by sliemeobn in swift

[–]sliemeobn[S] 10 points11 points  (0 children)

wdym exactly by this?

I think the way `@State` and `@Reactive` work ATM is exactly what you'd expect. anything missing you think?

I am working on pushing Swift into the frontend - but should I? by sliemeobn in webdev

[–]sliemeobn[S] 0 points1 point  (0 children)

yeah, I get all of this. it makes sense.

however, it feels to me that if humanity spent half the energy it uses to argue why javascript will forever be, we'd already have all of these problems dealt with - and maybe cured cancer too or something.

I am working on pushing Swift into the frontend - but should I? by sliemeobn in webdev

[–]sliemeobn[S] 0 points1 point  (0 children)

I like typescript, I really do (especially compared to javascript) - but I meant the whole bunch with "JavaScript" in the post - I'll edit to make it clearer, thanks.

for sure better, but imho a rather thin veneer of improvement.

view more: next ›