Oh wow - this is deeply, insanely similar to what I’ve been working on. Including your Solidjs based api, and how you’re approaching reactivity and signals. I had no idea Day existed. Write and post about it - this is cool!
To answer your question, no. I’m not convinced by leptos’s html style view macro. It’s cute, but you lose out on autocomplete and other IDE integration. I’m doing a rewrite at the moment and I’m considering dropping it for the fluent api that sits underneath. Kind of exactly like what you’ve got.
I am however, currently using leptos’s reactive_graph - which contains the implementation of signal / memo / etc. I’m not sure how the implementations compare, but one difference from reading the docs is that Leptos signals are Send. You can write to them from other threads. You just can’t do tracked reads from non main threads. (And effects always fire on the main thread). This makes it easy for applications to do work in other threads to fetch data or do long running computations, then pass the results to the UI via a signal. Use threads or tokio or whatever - it all plays nicely together.
You're also using SwiftUI's layout, while I'm leaning on taffy instead for css-style flexbox / grid layout support. I'd love to know more about the deep tradeoffs going on here. Like you, at the "ground level" I'm asking the underlying platform widgets to size themselves. The API taffy uses internally for this is even very similar - if not as well documented. Layout is cached and passed up the tree. Nodes are marked as dirty in the same way. I'm curious if these approaches are fundamentally the same, just with different APIs for developers. Or if there are real capability or performance differences.
> I’m not convinced by leptos’s html style view macro. It’s cute, but you lose out on autocomplete and other IDE integration.
Yes, that was exactly my thinking. In addition to more natural IDE support, relying on plain-old-Rust and not having a macro-processed DSL for the view specification makes it more comprehensible for LLM-driven development and testing (since the agents will likely know how to write correct Rust, but struggle with a bespoke DSL that it hasn't been trained on).
> Leptos signals are Send. You can write to them from other threads.
That's nice — I wasn't aware of that. Day's is main-thread-only, which is currently a significant limitation. I'll definitely look closer at leptos’s reactive_graph for ideas.
> You're also using SwiftUI's layout, while I'm leaning on taffy instead for css-style flexbox / grid layout support. I'd love to know more about the deep tradeoffs going on here.
I was tempted by Taffy, since it is very mature and widely-used, but ultimately chose to have the clankers implement something homespun for Day. One of the major reasons was that I can have fine-grained control over the measure passes for optimization. Measuring is cheap for most platforms, but Android (for example) requires a FFI hop via JNI to communicate back and forth between Rust and Android's Java SDK, and that can be quite expensive. So being able to control how these requests are batched together and optimized was important for getting good performance there (and also potentially for ArkUI and other platforms that don't have C/C++/ObjC bridges directly into their UI frameworks).
More broadly, though, I feel like Day's SwiftUI-style "parent proposes size, child decides" paradigm is better suited for native components, which tend to have more non-negotiable requirements for many of their control sizes and layout.
Are you confident that forking Leptos for this is the right choice? Do you like their HTML-ish DSL when applied to native apps?