it would be super useful to make tutorial on little more complicated examples like, passing around data through components, pages, writing rest apis and receiving and sendting to other servers.
Great stuff Chris. Thoughts on ergonomics vs Dioxus, Sycamore, or Leptos? Found simple things like nested lists get really ugly, really quickly in these Rust front ends.
I think Rust frontend in general is a pretty hard sell. Some tools like Sycamore advertise as "anti-JS" which is a really tough position to be in with a large community-sized lift to rebuild an ecosystem on top of. Dioxus is really early in it's lifecycle and if you have any JavaScript skills at all I'd recommend going full Tauri over Dioxus' piecemealing of Tauri's crates. I haven't worked with Leptos at all. The popular state of the art in frontend JS is heavily influenced by VC funding though, so the ergonomics of Rust on the frontend has to compete with companies who are well funded and trying to onboard you quickly and lock you in. This often results in fast onboarding but high-maintenance applications over time. So I could see Rust building an ecosystem that isn't driven by the same factors that could be very productive. It'll take a lot of work from a bunch of people though.
I would love to see a Leptos tutorial. I think it's inspired by SolidJS and most of the issues you had with Yew (defining a component name for example) don't look like so bad in Leptos
Has anyone figured out the proxy problem? I independently followed the yew tutorial and am stuck with the same behaviour EDIT: Digging through the Yew Discord I found that if you cleared the cache (or visit in an incognito window as I did) it works as expected. I have no clue why or how to prepare for such an issue but that's at least a temporary fix
Regarding 14:23, just think about an Option as a single element List, then it makes more sense. Same as Tree in which all nodes have only one child is a List.
It turns out there's a clippy lint for preventing this approach in other contexts, so especially interesting it was chosen here -- rust-lang.github.io/rust-clippy/v0.0.212/#for_loop_over_option
That fetch/unwrap chain is pretty 1:1 with a JS fetch promise chain. Fetching can fail, and deserializing a response can fail. JS has the benefit of being able to catch *any* error with a try/catch or chained .catch. the same code in js: const data = await fetch('/tutorial/data.json') .then(data => data.json()) .catch((err) => handleErr(err)); OR try { const res = await fetch('/tutorial/data.json'); const data = await res.json(); } catch (err) { handleErr(err); } handleErr would then have to handle both request error types, and deserialization error types. So it's just as much (if not more) boilerplate to write something that actually handles both error types cleanly.
I saw Yew mentioned many times, but never really understood the need, after this video I can safely say that in it's current form I don't have any application for it at work. Performance wise, could you potentially draw more/faster in WASM?
wasm doesn't have access to the dom, so you're not going to get faster dom updates afaik. It can be useful for performance if you're doing a lot of calculation, which is why I think some of the primary usage of wasm right now is with wgpu -> canvas interactions or other computationally heavy use cases.
Awesome video! Would be interested to see your thoughts on Yewdux. It doesn't try to be Redux 1:1, but should be relatively easy to pickup for people familiar with flux-like libs.
Nice Demo / Turorial. One small nit... the video doesn't match the tutorial doc and this could cause some confusion. Current tutorial version is 0.21 ...
I use yabai on macos, and the rainbow background is my own gradient desktop image from photoshop. I go over it here: ua-cam.com/video/apEXmJP5xxw/v-deo.html
It is cool to see more wasm presence on the web, but this syntax, boilerplate and clones everywhere.. It looks very much like rust and react are just not meant to be used together like that
@@chrisbiscardi I only know enough react to be dangerous. But something interfacing with a database, accepting and storing data and then mixing in push based real-time events would be awesome.
Thoughts v sycamore? I've had positive though limited experience with sycamore -- but it looks better than this! However interoperability with Javascript libraries seems a no-go. A Yew tutorial including such would be illuminating.
I'll do some videos on sycamore too. I'm pretty skeptical of anything that advertises as "anti-javascript" in general and sycamore's homepage saying "Had enough of JavaScript? So have we." as a main selling point is meh IMO. Giving up the very fast moving JavaScript ecosystem's libraries means you have to rebuild everything against a moving target so would require a very large community-sized lift for that to pan out, or a specific use case.
@@chrisbiscardi thank you so much for your reply. Is Sycamore anti JavaScript from a programmatic standpoint, or simply philosophically. In other words, does it stand in the way of JavaScript library compatibility for the intrepid? I don't know how much Yew bends over backward to support JavaScript library compatibility -- which I thought was an issue with wasm-bindgen in general? (Library, not calling individual commands intentionally exported). Again, appreciate the response.
@@larrymarso4492 seems philosophical since it's on their homepage. They do have a documentation page on interop: sycamore-rs.netlify.app/docs/advanced/js_interop but they're still pre first release afaik (suggested installation method is the git repo) so not all docs are filled out and we'll see how it evolves
Great to see someone go beyond the click counting example 🙂
Very informative video Chris. Please bring more videos on Yew, if possible 🙏
+1
you deliver this quality content so fast, i can not even watch it. ty. and iam so lf to 2023, my rust year. superb work
Thank you, I'm glad to know that someone else had the same problem with the json fetch at the end.
Thanks for such an informative video. It was clean & without any distraction, just on point.
it would be super useful to make tutorial on little more complicated examples like, passing around data through components, pages, writing rest apis and receiving and sendting to other servers.
Great stuff Chris. Thoughts on ergonomics vs Dioxus, Sycamore, or Leptos? Found simple things like nested lists get really ugly, really quickly in these Rust front ends.
I think Rust frontend in general is a pretty hard sell. Some tools like Sycamore advertise as "anti-JS" which is a really tough position to be in with a large community-sized lift to rebuild an ecosystem on top of. Dioxus is really early in it's lifecycle and if you have any JavaScript skills at all I'd recommend going full Tauri over Dioxus' piecemealing of Tauri's crates. I haven't worked with Leptos at all.
The popular state of the art in frontend JS is heavily influenced by VC funding though, so the ergonomics of Rust on the frontend has to compete with companies who are well funded and trying to onboard you quickly and lock you in. This often results in fast onboarding but high-maintenance applications over time.
So I could see Rust building an ecosystem that isn't driven by the same factors that could be very productive. It'll take a lot of work from a bunch of people though.
I would love to see a Leptos tutorial. I think it's inspired by SolidJS and most of the issues you had with Yew (defining a component name for example) don't look like so bad in Leptos
I've put it on my list to look into
Has anyone figured out the proxy problem? I independently followed the yew tutorial and am stuck with the same behaviour
EDIT: Digging through the Yew Discord I found that if you cleared the cache (or visit in an incognito window as I did) it works as expected. I have no clue why or how to prepare for such an issue but that's at least a temporary fix
How do you split the screens perfectly
Awesome video Chris!! I am adding it to my Rust Frontend Playlist!!
Great name... will *never* be confused with Vue...
Yew better enjoy the Vue from over there.
Ugh, hot reload isn't working? Nothing updates when I save my rust code.
You should file an issue with the project then. I was using hot-reload yesterday with the new release and it was working for me.
Regarding 14:23, just think about an Option as a single element List, then it makes more sense. Same as Tree in which all nodes have only one child is a List.
It turns out there's a clippy lint for preventing this approach in other contexts, so especially interesting it was chosen here -- rust-lang.github.io/rust-clippy/v0.0.212/#for_loop_over_option
9:00 I didn't know you could destructure in the function arguments. I will definitely use this here and there
That fetch/unwrap chain is pretty 1:1 with a JS fetch promise chain. Fetching can fail, and deserializing a response can fail. JS has the benefit of being able to catch *any* error with a try/catch or chained .catch.
the same code in js:
const data = await fetch('/tutorial/data.json')
.then(data => data.json())
.catch((err) => handleErr(err));
OR
try {
const res = await fetch('/tutorial/data.json');
const data = await res.json();
} catch (err) {
handleErr(err);
}
handleErr would then have to handle both request error types, and deserialization error types. So it's just as much (if not more) boilerplate to write something that actually handles both error types cleanly.
That's a really good point. I wonder if that can be handled smoothly with some macros.
I saw Yew mentioned many times, but never really understood the need, after this video I can safely say that in it's current form I don't have any application for it at work. Performance wise, could you potentially draw more/faster in WASM?
wasm doesn't have access to the dom, so you're not going to get faster dom updates afaik. It can be useful for performance if you're doing a lot of calculation, which is why I think some of the primary usage of wasm right now is with wgpu -> canvas interactions or other computationally heavy use cases.
Awesome video! Would be interested to see your thoughts on Yewdux. It doesn't try to be Redux 1:1, but should be relatively easy to pickup for people familiar with flux-like libs.
Video today took a look at yewdux. It was very easy to pick up and follow the todomvc, etc examples
Nice Demo / Turorial.
One small nit... the video doesn't match the tutorial doc and this could cause some confusion. Current tutorial version is 0.21 ...
What program are you using to have your windows work like that? And with the rainbow background?
I use yabai on macos, and the rainbow background is my own gradient desktop image from photoshop.
I go over it here: ua-cam.com/video/apEXmJP5xxw/v-deo.html
It is cool to see more wasm presence on the web, but this syntax, boilerplate and clones everywhere.. It looks very much like rust and react are just not meant to be used together like that
I think it would be interesting to see a bigger React tutorial implemented in Yew.
yeah I agree. I'm planning on doing some more Rust UI explorations across a couple of tools. Is there a specific React app that you'd like to see?
@@chrisbiscardi I only know enough react to be dangerous. But something interfacing with a database, accepting and storing data and then mixing in push based real-time events would be awesome.
Chris very great video yet again!
What ls tool are you using?
Nushell
To use this video: learn react...?
Thoughts v sycamore? I've had positive though limited experience with sycamore -- but it looks better than this! However interoperability with Javascript libraries seems a no-go. A Yew tutorial including such would be illuminating.
I'll do some videos on sycamore too. I'm pretty skeptical of anything that advertises as "anti-javascript" in general and sycamore's homepage saying "Had enough of JavaScript? So have we." as a main selling point is meh IMO.
Giving up the very fast moving JavaScript ecosystem's libraries means you have to rebuild everything against a moving target so would require a very large community-sized lift for that to pan out, or a specific use case.
@@chrisbiscardi thank you so much for your reply. Is Sycamore anti JavaScript from a programmatic standpoint, or simply philosophically. In other words, does it stand in the way of JavaScript library compatibility for the intrepid? I don't know how much Yew bends over backward to support JavaScript library compatibility -- which I thought was an issue with wasm-bindgen in general? (Library, not calling individual commands intentionally exported). Again, appreciate the response.
@@larrymarso4492 seems philosophical since it's on their homepage. They do have a documentation page on interop: sycamore-rs.netlify.app/docs/advanced/js_interop but they're still pre first release afaik (suggested installation method is the git repo) so not all docs are filled out and we'll see how it evolves
Thank you for this tutorial !
nice video chris
Fast watcher!!
Flashhhh!!!
for details, lets watch next video :D
U BEST!!!
You don't have to use curly brackets for text. Only if you want to use a Rust string literal...for some reason. `Hello World` also works.