Replies: 3 comments 4 replies
-
|
Not really. This rendering model is quite different from Leptos's, which is built on fine-grained reactivity. I know Dioxus has some LiveView features either already or upcoming; you may want to check them out! Leptos is really very far from Elm in its approach. There are plenty of Elm-ish Rust frameworks like Yew, Sauron, or Seed, which may be interesting to you too. |
Beta Was this translation helpful? Give feedback.
-
|
What makes Leptos interesting is that the client code is still rust (WebAssembly) NOT js and Server Code of Rust as well, that makes it similar to Elixir/Phoenix, if the fine-grained reactivity achieves similar performance to LiveView, then developers won't really care. To me it's developing in the one language, for both the Server and Client that is appealing. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, well in that case — yes, we have that! If you want a good example of how to write very tightly coupled client and server code check out the todo-app-sqlite example. You really can basically write the application as though the client/server distinction wasn't that big of a deal. |
Beta Was this translation helpful? Give feedback.
-
@gbj: Wouldn't fine-grained reactivity be perfectly suited for an implementation of LiveView? Instead of applying the changes directly to the DOM, you'd just sent them from the server (which manages the state of the app and handles user events) to the browser (which sends events to the server). LiveView, basically, is just a layer between the DOM and a VDOM or the fine-grained reactivity of Leptos. I might miss something, but fine-grained reactivity seems perfect for this. |
Beta Was this translation helpful? Give feedback.
-
|
Sure, you could do that, the question is just: Why? By which I mean: it's perfectly possible to implement this in userland for any given application or as a library. For particular kinds of applications like games, chat rooms, or collaborative editing it might be useful. As a general purpose rendering technique it's not the most straightforward or performant option. |
Beta Was this translation helpful? Give feedback.
-
|
What liveview style can do, that gets really messy with "server functions", is incremental, automatic changes as server-side data changes. For example, the todo example has to manually list all the operations that are known to invalidate the previous RPC, and even then does not see changes made by other clients. You can build something like this on top of SSE or WebSockets yourself, essentially subscribing the client to server-side pubsub events, but now you're building layers upon layers of communication mechanisms -- with liveview, the liveview itself is the pubsub mechanism, and all the reactive updates are handled the same way, requiring less application programmer effort. https://github. I'm currently experimenting with dioxus-liveview and they are talking of abandoning it, and it does not handle disconnects right. I wish there was a standard "shove (V)DOM mutations over the wire" convention I could plug any renderer into.. |
Beta Was this translation helpful? Give feedback.
-
Correct. From the very earliest days of the framework, we've had an example of this in
Well, a layer upon another layer, in any case. It's pretty straightforward to build things like collaborative editing over websockets -- either by doing it yourself or by using one of the various databases that supports it. The hard parts are the parts that have the least to do with the UI (how you manage conflicting changes, etc.) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Leptos, looks like the next generation of Elm based web development using Rust, having spent the last couple of years doing Elixir Phoenix LiveView, is there anything on the Roadmap that looks like LiveView, which by the way uses an integrated WebSocket, around an Actor model (GenServer), with a native templating engine all authored in Elixr.
As there are many Web development tools for Rust, I see one advantage of using Rust is to produce the fastest compiled output, but productivity through a clean coding experience is critical for the uptake.
Beta Was this translation helpful? Give feedback.
All reactions