# Presenting Swiflow, a frontend stack for the web in Swift → Wasm **URL:** \ **Category:** Community Showcase\ **Tags:** webassembly\ **Created:** [July 3, 2026, 5:58pm UTC](https://forums.swift.org/t/presenting-swiflow-a-frontend-stack-for-the-web-in-swift-wasm/87971 "2026-07-03T17:58:13Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![zzal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zzal/32/45859_2.png) [@zzal](https://forums.swift.org/u/zzal)\ **Post date:** [July 3, 2026, 5:58pm UTC](https://forums.swift.org/t/presenting-swiflow-a-frontend-stack-for-the-web-in-swift-wasm/87971/1 "2026-07-03T17:58:14Z")
Does the web need a Swift frontend stack? I don't know, but here's my take on what could be something for me to develop web apps in the future. (Swiflow is a solo project, built and maintained by me as a hands-on exploration of Swift on the web) **Swiflow** is not a UI library; it's a batteries-included frontend stack for single-page apps, written in Swift 6 and compiled to WebAssembly; A virtual-DOM machine in Swift. The bet it tests: WebAssembly moves the work from runtime to compile time, and that buys ergonomics that are structurally hard to get in JS. ([The longer argument →](https://github.com/zzal/swiflow/blob/main/WHY.md)) Repo: [https://github.com/zzal/swiflow](https://github.com/zzal/swiflow) (Apache 2.0) - **Reactivity** — `@Component` / `@State`; `@ReducerState` for wizard/queue-style client state (pure reducers, effects at the call site); environment, refs, `.task` effects. - **SwiflowUI** — token-driven components (forms, overlays, virtualized `DataTable`, coalescing toasts). Components read `--sw-*` tokens and never branch on dark mode or reduced motion — token layers do. `swiflow theme` generates WCAG-validated palettes from a brand color at build time. - **SwiflowQuery** — server-state caching: SWR, dedup, optimistic updates with generation-guarded rollback, invalidation, retry/backoff. The hairy interleavings are fuzz-tested plus gated deterministic races. - **Router / Store / Fetcher** — hash & history routing, IndexedDB persistence, typed JSON-over-`fetch`. - **Real CSS** — the `#css` macro validates actual CSS at compile time and scopes it per component. - **The CLI** — `swiflow init` scaffolds a working app; `swiflow dev` hot-reloads **while preserving your `@State`** (edit a color five levels deep in a wizard, stay on step five); `swiflow doctor` checks your toolchain. ## **Try it** Requires Swift 6.3.2 + the WebAssembly SDK (two commands, [see the README](https://github.com/zzal/swiflow#readme)). Then: ```sh # Install the swiflow CLI (prebuilt: macOS arm64 / Linux x86_64) sh -c "$(curl -fsSL https://raw.githubusercontent.com/zzal/swiflow/main/install.sh)" swiflow doctor # checks your toolchain swiflow init my-app # will auto-select the HelloWorld template cd my-app && swiflow dev # → http://localhost:3000 ``` This is the first version I'm comfortable asking other people to try. If your reaction is "this shouldn't exist, and here's why," I want that review ---
**Author:** ![vitamin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/vitamin/32/11098_2.png) [@vitamin](https://forums.swift.org/u/vitamin)\ **Post date:** [July 7, 2026, 5:23am UTC](https://forums.swift.org/t/presenting-swiflow-a-frontend-stack-for-the-web-in-swift-wasm/87971/2 "2026-07-07T05:23:21Z")
Curious to try this with [SwiftXState](https://github.com/gistya/SwiftXState) and WebGPU stuff :D Gonna download and try tomorrow ---
**Author:** ![zzal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zzal/32/45859_2.png) [@zzal](https://forums.swift.org/u/zzal)\ **Post date:** [July 10, 2026, 3:34pm UTC](https://forums.swift.org/t/presenting-swiflow-a-frontend-stack-for-the-web-in-swift-wasm/87971/3 "2026-07-10T15:34:20Z")
Out of curiosity, I tried incorporating SwiftXState into a Swiflow project. Good news first: SwiftXState works in Swiflow today, no changes needed on either side. The caveat is **bundle size** , measured on optimized release builds: - Swiflow starter app: 5.4 MB (1.9 MB gzipped) - With SwiftXState: 47.0 MB (18.5 MB gzipped) Using SwiftXState added ~7 KB — the +41.6 MB comes entirely from linking it, because its core imports Foundation, which on wasm drags in swift-foundation + ICU data. Nothing Swiflow can fix downstream; it's the Foundation-on-wasm tax. So: great for internal tools and prototypes today; not something I can recommend for public-facing sites until the weight comes down. ---
**Author:** ![filip-sakel](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/filip-sakel/32/8697_2.png) [@filip-sakel](https://forums.swift.org/u/filip-sakel)\ **Post date:** [July 10, 2026, 3:38pm UTC](https://forums.swift.org/t/presenting-swiflow-a-frontend-stack-for-the-web-in-swift-wasm/87971/4 "2026-07-10T15:38:52Z")
How does Swiflow compare to existing libraries, such as [ElementaryUI](https://elementary.codes/)? ---
**Author:** ![zzal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zzal/32/45859_2.png) [@zzal](https://forums.swift.org/u/zzal)\ **Post date:** [July 10, 2026, 4:04pm UTC](https://forums.swift.org/t/presenting-swiflow-a-frontend-stack-for-the-web-in-swift-wasm/87971/5 "2026-07-10T16:04:06Z")
The main differences: - ElementaryUI is SwiftUI-inspired (view modifiers). Swiflow is HTML-first — you write div, button, real attributes, scoped CSS modules — so what you write maps 1:1 to the DOM you get. Although you can create reusable Component (React inspired) - Bundle size. ElementaryUI supports Embedded Swift, which gets bundles down to kilobytes. Swiflow uses full Swift — a starter app is ~5 MB wasm (~2 MB over the wire) — trading size for the whole language: actors, macros, the full stdlib, and any SwiftPM dependency that compiles for wasm. - Swiflow is a broader web app dev solution. Virtual dom with state-preserving HMR, data fetching with caching/mutations (à la Tanstack Query), a page router, a persisted store, a themed accessible UI component library, a form controller, a testing library, and browser devtools all ship in the box. ElementaryUI is more focused on the core view layer. ---
**Author:** ![vitamin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/vitamin/32/11098_2.png) [@vitamin](https://forums.swift.org/u/vitamin)\ **Post date:** [July 12, 2026, 12:15am UTC](https://forums.swift.org/t/presenting-swiflow-a-frontend-stack-for-the-web-in-swift-wasm/87971/6 "2026-07-12T00:15:48Z")
> [@zzal](#): > > Out of curiosity, I tried incorporating SwiftXState into a Swiflow project. > > Good news first: SwiftXState works in Swiflow today, no changes needed on either side. > The caveat is **bundle size** , measured on optimized release builds: > > - Swiflow starter app: 5.4 MB (1.9 MB gzipped) > - With SwiftXState: 47.0 MB (18.5 MB gzipped) > > Using SwiftXState added ~7 KB — the +41.6 MB comes entirely from linking it, because its core imports Foundation, which on wasm drags in swift-foundation + ICU data. Nothing Swiflow can fix downstream; it's the Foundation-on-wasm tax. > > So: great for internal tools and prototypes today; not something I can recommend for public-facing sites until the weight comes down. Thanks for the feedback. Check out tag `2.0.0-alpha.7`, I've removed Foundation as a dependency from the core target `SwiftXState` (now we use a custom JSON parser instead of Foundation's). I'll also migrate the Inspect target to Foundation-free shortly, in case you want the JSON output and inspection capabilities. This brought down the size of the SwiftXState.swiftmodule release build to 1,988,073 bytes (~2MB... 45MB less than when it had Foundation... wow). 2.0.0 is also a really major improvement. It adds a SwiftUI-like declarative state machine DSL, which you can see the DSL in use in the repo examples or in SwiftBuild app (GUI for building the Swift compiler): [GitHub - gistya/swift-repo-gui: SwiftUI GUI and mod tracker soundtrack for building the Swift programming language · GitHub](https://github.com/gistya/swift-repo-gui) ---
**Author:** ![Max\_Desiatov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/max_desiatov/32/20654_2.png) [@Max\_Desiatov](https://forums.swift.org/u/Max_Desiatov)\ **Post date:** [July 12, 2026, 3:21pm UTC](https://forums.swift.org/t/presenting-swiflow-a-frontend-stack-for-the-web-in-swift-wasm/87971/7 "2026-07-12T15:21:05Z")
> [@zzal](#): > > - Swiflow uses full Swift — a starter app is ~5 MB wasm (~2 MB over the wire) — trading size for the whole language: actors, macros Both actors and macros are available in the Embedded Swift mode. ---
**Author:** ![zzal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zzal/32/45859_2.png) [@zzal](https://forums.swift.org/u/zzal)\ **Post date:** [July 19, 2026, 8:07pm UTC](https://forums.swift.org/t/presenting-swiflow-a-frontend-stack-for-the-web-in-swift-wasm/87971/8 "2026-07-19T20:07:28Z")
I have added a scaffold template that showcase the potential gain of heavy calculation of WASM over JS. Try `swiflow init myApp --template GridBoard`_(we are now on v0.5.3)_. An electricity-grid dashboard with over **12M data points** , showing a serverless, dashboard of a simulation of Canada's power grid. Every interaction is a full-dataset query: a year of 5-minute-resolution data for 13 provinces and territories lives in WASM linear memory, and dragging the scrubber, painting the season×hour wheel, or hovering a province re-scans it between two frames. No server, no API, no precomputed tiles. The perf HUD shows the receipts. ### → running at 120 fps (Chrome & Firefox. Safari is caping at 60 fps) Nice to see it run!