Five capabilities that exist nowhere else — not in React, Svelte, Solid, Vue, or any other framework. Each + one is novel. Together, they're a paradigm shift.
+In every other framework, signals are invisible to the type system. You can pass a + signal where a plain value is expected and it silently breaks. DreamStack catches this at + compile time.
+// The compiler KNOWS these are reactive +let count = 0 // → Signal<Int> +let name = "Ada" // → Signal<String> +let doubled = count * 2 // → Derived<Int> +let hot = count > 10 // → Derived<Bool> + +// ✅ Type-safe: compiler verifies deps +// ✅ Auto-tracks what to re-render +// ✅ Zero accidental subscriptions+
// TypeScript can't tell these apart: +const [count, setCount] = useState(0) +// count is... number? Signal? Who knows? + +// This compiles but SILENTLY BREAKS: +function add(a: number, b: number) { + return a + b +} +add(count, 5) // ← loses reactivity! +// No framework catches this at compile time+
React has useEffect (untyped, untestable). DreamStack has algebraic effects — declare + what side-effects a function may perform, and the compiler enforces that every effect is + handled. Swap handlers for testing without touching business logic.
+// Declare what effects exist +effect Http.get(url: String): Response +effect Time.delay(ms: Int): () + +// Use them — the TYPE tracks it +let search = (q) -> { + perform Time.delay(250) + perform Http.get("/api?q=" ++ q) +} +// search : (String) -> Response ! Http, Time + +// In production: +handle { Http.get(u) -> fetch(u) } + +// In tests — SAME code, DIFFERENT handler: +handle { Http.get(u) -> mock_data }+
// Effects are opaque and untraceable +useEffect(() => { + fetch('/api') // ← hidden side-effect + .then(r => r.json()) + .then(setData) +}, [query]) + +// Questions no framework can answer: +// • What effects does this component perform? +// • Are all effects cleaned up? +// • Can I swap fetch for a mock? +// • Will this work without network? +// +// Answer: 🤷 good luck+
In other frameworks, spring animations are separate from state. In DreamStack, a spring + IS a signal — set its target and every derived value, every view binding, every layout constraint + updates automatically through the reactive graph. Physics and reactivity are one system.
+// A spring IS a signal — same API, same graph +let sidebar_w = spring( + target: 240, + stiffness: 170, + damping: 26 +) // → Spring<Float> (is-a Signal<Float>) + +// Derived values track spring physics! +let main_w = 1000 - sidebar_w +// main_w smoothly animates as sidebar springs + +// Layout constraints + springs = magic +view main = row [ + panel { width: sidebar_w } // springs! + panel { width: main_w } // auto-follows! +] + +on toggle -> sidebar_w.target = 64 +// Everything animates. Zero manual work.+
// Animation is separate from state +const [sidebar, api] = useSpring({ + width: expanded ? 240 : 64 +}) + +// Want main panel to follow? Manual math: +const main = sidebar.width.to( + w => 1000 - w +) // ← manual interpolation per value + +// Want derived-of-derived? More manual work. +// Want 5 things to follow? 5× manual. +// Physics never feeds back into the +// reactive graph. Two separate worlds. +// +// Spring ≠ Signal. They can't talk.+
In React/Solid, dependencies are discovered at runtime. DreamStack's compiler statically + analyzes the entire signal dependency graph before a single line runs. Dead signals get eliminated. + Over-subscription is impossible.
+// The compiler produces this at BUILD TIME: +Signal Graph { + count: Source(Int) → [doubled, is_hot, view] + doubled: Derived(Int) ← [count] + is_hot: Derived(Bool) ← [count] + + // Dead signal detection: + ⚠ unused_var: Source(String) — DEAD, eliminated + + // Optimal subscription plan: + view.main subscribes to: [count, doubled, is_hot] + // NOT to unused_var — zero wasted work +}+
// Dependency discovery happens AT RUNTIME +// The compiler has NO IDEA what subscribes to what + +useEffect(() => { + // React: "I'll figure it out when it runs" + // Missing dep? Silent stale closure bug. + // Extra dep? Runs too often. + setDoubled(count * 2) +}, [count]) // ← YOU must list deps manually + +// In Solid: auto-tracking is runtime-only. +// Unused signals still exist in memory. +// Over-subscription? No compiler to warn you.+
CSS was designed for documents, not UIs. DreamStack uses a Cassowary constraint solver —
+ the same algorithm Apple uses for Auto Layout. Declare relationships between elements, and the solver
+ finds the solution. No flex-grow: 1; min-width: 0; overflow: hidden nightmares.
// Declare relationships. Solver does the math. +constraint sidebar.width == 200 @ Strong +constraint sidebar.width >= 64 @ Required +constraint main.x == sidebar.x + sidebar.width +constraint main.x + main.width == 1000 + +// The solver guarantees: +// • sidebar = 200, main = 800 (normal) +// • sidebar = 64, main = 936 (collapsed) +// • NEVER sidebar = -1 or main = NaN + +// Bonus: constraint + spring = animated layout +constraint sidebar.width == sidebar_spring +// Physics drives layout. Solver maintains truth.+
/* Hope and pray this works: */ +.sidebar { + width: 200px; + min-width: 64px; + flex-shrink: 0; + transition: width 0.3s; +} +.main { + flex: 1; + min-width: 0; /* ← the classic hack */ + overflow: hidden; /* ← another hack */ +} + +/* What if sidebar + main > viewport? */ +/* What if content pushes sidebar wider? */ +/* What if animation causes flash of wrong layout? */ +/* CSS: ¯\_(ツ)_/¯ */+
Five capabilities. Zero competitors have all five. Most have zero.
+| Capability | +DreamStack | +React | +Svelte 5 | +Solid | +Vue | +
|---|---|---|---|---|---|
| Signals in the type system | +✓ | +✕ | +✕ | +✕ | +✕ | +
| Algebraic effects (testable side-effects) | +✓ | +✕ | +✕ | +✕ | +✕ | +
| Springs are signals (unified graph) | +✓ | +✕ | +✕ | +✕ | +✕ | +
| Compile-time dependency graph | +✓ | +✕ | +~ | +✕ | +✕ | +
| Constraint-based layout (Cassowary) | +✓ | +✕ | +✕ | +✕ | +✕ | +
| Score | +5/5 | +0/5 | +~0.5/5 | +0/5 | +0/5 | +