I'm building a collection of examples[3] and if I can get it working I'll add it.
[1] https://wout.space/notes/how-to-share-store-between-multiple...
[2] https://hexdocs.pm/phoenix_live_view/live-navigation.html
[3] https://github.com/woutdp/live_svelte/tree/master/examples
Are you using Phoenix’s javascript client (and protocol) or rolling your own?
[1] - http://LiveViewJS.com
I think this is is a really powerful way to make web apps and it's nice to see that others are doing it too.
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.
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
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).
That would be awesome even without any live view like functionality
> 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.
I think Rust will be around in 5 years. Will AssemblyScript?
I guess this project's trying to make some buzzword ?
Because for documentation, assumption is bad.
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.
> Note that you still cannot define a one-word component without referencing it via path syntax.
module::header {}