Live data from Hacker News

Dioxus 0.3 – Templates, Hot Reloading, LiveView, and More

dioxuslabs.com

11–20 of 33 posts

Re: Dioxus 0.3 – Templates, Hot Reloading, LiveView, and More

#12
post #8

If you're doing LiveViews in Rust, does it work per-process-per-user like Elixir? How does that all work?

The state of the app lives in an async task which can be multithreaded or distributed. Rust webservers can handle tens of thousands (hundreds of thousands?) of connections at once.

Re: Dioxus 0.3 – Templates, Hot Reloading, LiveView, and More

#13

I tried my best to browse all the docs and guides and sample code to know what does live view mean , but failed. I guess this project's trying to make some buzzword ? Because for documentation, assumption is bad.

LiveView is just updating the HTML DOM through a websocket. Instead of using a conventional API, everything happens through the websocket.

This way you can write server side templates to update the client automatically on server side state changes without needing to use an API on the client to fetch the state or even manipulate the state.

Re: Dioxus 0.3 – Templates, Hot Reloading, LiveView, and More

#14
post #13

I tried my best to browse all the docs and guides and sample code to know what does live view mean , but failed. I guess this project's trying to make some buzzword ? Because for documentation, assumption is bad.

LiveView is just updating the HTML DOM through a websocket. Instead of using a conventional API, everything happens through the websocket. This way you can write server side templates to update the client automatically on server side state changes without needing to use an API on the client to fetch the state or even manipulate the state.

I know and heard "liveview" before, from hotwire to liveview from phoenix. It's just that i can't see this through this project's docs or code sample.

Re: Dioxus 0.3 – Templates, Hot Reloading, LiveView, and More

#15
post #7

Great to see another language adopting LiveView! (Author of LiveViewJS[1] here). Are you using Phoenix’s javascript client (and protocol) or rolling your own? [1] - http://LiveViewJS.com

We're using our own protocol right now - haven't really looked too deeply at the Phoenix protocol. We use templates (like Solid or Blockdom) to build and patch the page which is pretty specific to Dioxus.

Re: Dioxus 0.3 – Templates, Hot Reloading, LiveView, and More

#16
post #9

Dioxus liveview is so good. I tried it with salvo and it just worked (tm). The only downside which they're working on is some kind of socket reconnect if someone navigates away and the socket gets disconnected for some reason

Yep, I think the PR is ready to go too!

https://github.com/DioxusLabs/dioxus/pull/762

I think the next logical step is to build our own "Phoenix" on top of axum (or hyper).

Re: Dioxus 0.3 – Templates, Hot Reloading, LiveView, and More

#18
post #6

source code looks pretty readable. there doesn't seem to be much magic. is there any support for use with other languages?

We don't have any bindings for Dioxus into other languages, but there are a handful of projects within the Dioxus ecosystem that do, like taffy.

http://github.com/dioxusLabs/taffy

Re: Dioxus 0.3 – Templates, Hot Reloading, LiveView, and More

#19
post #9

Dioxus liveview is so good. I tried it with salvo and it just worked (tm). The only downside which they're working on is some kind of socket reconnect if someone navigates away and the socket gets disconnected for some reason

Yep, I think the PR is ready to go too! https://github.com/DioxusLabs/dioxus/pull/762 I think the next logical step is to build our own "Phoenix" on top of axum (or hyper).

> I think the next logical step is to build our own "Phoenix" on top of axum (or hyper)

That would be awesome even without any live view like functionality

Re: Dioxus 0.3 – Templates, Hot Reloading, LiveView, and More

#20
On their github repo:

> Simple "hello world" at about 65kb, comparable to React

I assume that is minified and compressed. That's quite bloat. I wonder if they try https://github.com/johnthagen/min-sized-rust ?

Also I feel like the BytecodeAlliance too much focus on their cloud runtime use case while seamless wasm + dom interop is where its adoption will skyrocking. I would rather write Rust/Go/Roc/any-sane-typing instead of TS.

Post reply on HN