Reactivity
#343
Replies: 1 comment
-
Now I understand. My use case is inherently (server side) stateful, which doesn't really jive with the intent of fasthtml and hateoas principals. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm loving the feel of fasthtml! I'm also interested in leveraging server-side reactivity as I believe it can simplify complex apps.
I found this issue and read up on hateoas. I'm a super big fan of the client side being fairly dumb, just displaying what it's provided and not implementing any business logic which is reliant JSON state updates. On the flip side, I've used Plotly Dash over the years and found that explicitly specifying destinations for html fragments is a PITA as complexity grows - especially when one action should update disparate elements in a page.
A while ago, I implemented SilkFlow which is similar to fasthtml in many ways, but it's inspired by solidjs for fine grained reactivity. Naively, it feels like this approach bridges the gap between hateoas and reactivity. To be clear, I'm here because I want to switch to fasthtml in place of SilkFlow, which was developed for a totally different set of constraints. fasthtml is way better designed and implemented and has excellent community engagement!
My question is, am I misguided in thinking server-side, fine grained reactivity with fasthml would be awesome?
Beta Was this translation helpful? Give feedback.
All reactions