[HN Gopher] Dioxus 0.3 - Templates, Hot Reloading, LiveView, and...
       ___________________________________________________________________
        
       Dioxus 0.3 - Templates, Hot Reloading, LiveView, and More
        
       Author : jgillich
       Score  : 76 points
       Date   : 2023-02-23 13:38 UTC (1 days ago)
        
 (HTM) web link (dioxuslabs.com)
 (TXT) w3m dump (dioxuslabs.com)
        
       | pictur wrote:
       | source code looks pretty readable. there doesn't seem to be much
       | magic. is there any support for use with other languages?
        
         | jkelleyrtp wrote:
         | 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
        
       | floodfx wrote:
       | 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
        
         | jkelleyrtp wrote:
         | 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.
        
       | revskill wrote:
       | 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.
        
         | POiNTx wrote:
         | 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.
        
           | revskill wrote:
           | 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.
        
       | whitepoplar wrote:
       | I think it would be clearer to rename LiveView to something else,
       | so as not to draw confusion with Elixir's LiveView.
        
         | manmal wrote:
         | OTOH, LiveView sounds generic enough to become the name of the
         | whole paradigm.
        
           | toolz wrote:
           | I would support liveview defining the entire process. I've
           | written a lib myself to do liveview type things and coming up
           | with a solid descriptor for things like conference talks was
           | basically impossible. I write a lot of elixir and I would
           | presume "phoenix liveview" is probably what people use to
           | describe the elixir lib to people outside of the ecosystem
           | anyways.
        
       | mwcampbell wrote:
       | > We're actively working on adding accessibility support using
       | the work done by EGUI as inspiration.
       | 
       | Glad to hear it. FWIW, I worked on the AccessKit integration in
       | egui, as well as AccessKit itself, so let me know if you need
       | help.
        
       | Existenceblinks wrote:
       | 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.
        
       | Mizza wrote:
       | If you're doing LiveViews in Rust, does it work per-process-per-
       | user like Elixir? How does that all work?
        
         | jkelleyrtp wrote:
         | 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.
        
       | swlkr wrote:
       | 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
        
         | jkelleyrtp wrote:
         | 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).
        
           | nicoburns wrote:
           | > 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
        
       | jkelleyrtp wrote:
       | Author here. Didn't expect to see Dioxus on HN today!
        
       | POiNTx wrote:
       | Very timely, I've been working on Svelte integration for Phoenix
       | Liveview, started working on it this week[1]. It's very cool to
       | see LiveView expanding as a paradigm outside of Phoenix.
       | 
       | [1] https://github.com/woutdp/live_svelte
        
       ___________________________________________________________________
       (page generated 2023-02-24 23:00 UTC)