Create client-side web apps in Swift that weigh less than 200 kB.
Check out the "Swiftle" demo app!
Based on the swift.org WebAssembly SDKs, JavaScriptKit, and Elementary.
For embedded builds, Swift 6.2 or later with matching Swift SDKs for WebAssembly from swift.org is required.
Important
ElementaryDOM is a passion project under active development.
Expect sharp edges, APIs may change, and things may break while I balance performance, ergonomics, and feature set.
Nothing is stopping us from having a viable, fully featured, client-side web frontend library powered by Swift.
If you want to see this come to life, sponsorship is sincerely appreciated 🙏
identity system and list-diffinglifecycle events and proper "unmounting" (currently nodes are just "dropped")@State systemtyped event handlers@Environment systemdependencies on versioned packages (i.e., build without unsafe flags)fix DOM not child-diffing to preserve animations/nodes (the current solution based onreplaceChildrenwill not work, it seems)"model-bindings" for inputs (i.e., bind a @Binding to a text box, or bind a @Binding to a checkbox)view value comparing (generated comparing and custom equatable support)different handling of environment (individual reactivity needed)transitions and animations (ideally CSS-based, probably svelte-like custom easing functions applied through WAAPI)better control over animationssomehow migrate over to "var body" instead of "var content" (what was I thinking....)automatic FLIP animations for certain layout changes (child-layout after changes, maybe size of containers)fix those Foundation imports, review thread-local + mutex usage- more built-in animatable CSS modifiers (colors, borders, borders?, blur)
- basic phaseAnimator implementations
- implement auto-flip animation for custom CSS values (on value triggers)
- maybe add "animateContainerLayout" modifier with value trigger (eg: to animate changes without child-changes)
- support for combined and reversible transitions
- mutli-select bindings (options, radio-buttons, tagged check boxes, ...)
- more unit testing (FLIP handing, animations, reactivity, ...)
- implement @ViewEquatableIgnored
- split out JavaScriptKit stuff in separate module to contain spread, maybe one day we can switch to faster interop somehow
- add basic docs, a good intro readme, and push a 0.1 out the door! (probably best to wait for Swift 6.2 to drop)
- a router implementation (probably in extra module?)
- maybe conditionally support @Observable for non-embedded builds?
figure out why@Environmentwith optionalReactiveObjectdoes not build in embedded- preference system (i.e., bubbling up values)
- embedded-friendly Browser APIs (Storage, History, maybe in swiftwasm package with new JavaScriptKit macros)
think about how to deal with the lack ofCodablein embedded (wait for new serialization macros)make printing work without WASI (maybe pipe putchar through to JavaScript?)- isolation and @MainActor stuff for reusable types (server-side rendering and client apps - probably never quite possible to have same types render "multi-threaded" server side and stay single-threaded client side....)
decide whether the current idea ofViewsflattening themselves into renderable types is even necessary, or if views should just "apply" themselves into the reconciler - might be a bit messier, but maybe faster and more flexible- move all elementary repos under one project roof and use a traits-based, single "ElementaryUI" top-level package (or similar)
simple build with SwiftPM (wasm-ld)_Concurrency module (Task)- Codable 2.0 (we need JSON handling for embedded, on the horizon)
- Synchronization (Mutex)
This package is generally licensed as Apache 2.
The Rectivity module is inspired by the Swift stdlib's Observation framework, and code in ReactivityMacros is directly derived from it (source).
Find a copy of the Swift.org open source project license here.
This project includes binaries from the wasi-libc project, which is licensed under the Apache License 2.0 with LLVM Exceptions.