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.
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.