Thanks for this update and the refactoring. After the last video I thought: that’s okay, but there must be cleaner way to do this. I am happy you demonstrated this way 👍
@@workflowinmind definitely planing further videos in the future. As soon as I have the needed free time again. This time will hopefully come sooner then later 😁
Great job Chris, this is much better, pr this maybe? I tried using yew and it just felt like a huge mess for someone who doesn't really know what components and all these things mean so any contribution would be beneficial to the yew project.
If you don't know what components are, I suggest starting with React. Yew tries to copy React's APIs into a Rust environment, which I personally don't think works well. Rust has so much more powerful syntax than JS that it just doesn't make sense to make an almost 1:1 copy. Another thing is that it just doesn't feel like you're writing Rust but still have to deal with all the safety guards that Rust provides which makes it very unmanageable imo. That and if you want to write web apps, use TypeScript instead. There's a lot of overhead using WASM on the web, let alone using a memory managed programming language to deal with DOM APIs (i.e. event listeners). Start with React as it has the widest range of resources and is for the most part is backwards compatible (except unstable APIs that you likely aren't going to use yet), and their React Beta docs are also fantastic to learn about components in general.
If they want this work contributed I might PR it. I assume they chose functional components for a reason to reach a specific audience. The "functional component" concept got really popular in the JS ecosystem a few years ago. I'm hanging out in their discord now so should be able to find out.
@@dealloc yes, it felt quite foreign and restrictive comparing to the Rust I'm used to writing, the documentation isn't the greatest as well. I'd really like to see Rust succeed in the web space
@@dyslexicsteak897 I'm sure it will, just not for web UI/DOM in my opinion. There's still a bright future for compiled languages using WASM for more computational tasks like rendering, physics, audio, emulation and the like.
This makes much more sense then the tutorial version! Totally unrelated, but have you ever talked about your tutorial workflow/setup? I want to get back into doing tutorials (VFX/CG related) and would like to have "strict guidelines" and setup to not have to think about it much. Like do you record long sessions that you edit down? I feel like you manage to optimise time very well in these. No mumbling and not epileptic edit either, very good balance
Whatever makes you most productive is what matters. Some record long videos and cut them later, some also write a script or at least an outline to follow to make the video more coherent and avoid talking too much detail which can make it hard to follow. Others don't do it at all and can just talk coherently about a subject on the spot. People have different skills and workflows. There aren't strict guidelines. It's what you find works for you. You'll only learn and adapt your workflow by doing it.
I haven't talked much about my workflow. For youtube since I do daily videos it's very lightweight and has to be end-to-end finished in maybe 2 hours tops or I won't be able to ship a video. Some days I invest more, but I also have other work to do each day. The breakdown is roughly: 1. get the example ready before the video 2. talk through the code/etc and record in obs (20m-1h recording) 3. remove silence programmatically 4. edit any umms, coughing, or bad takes out (davinci resolve, one playback) 5. generate captions and review For me, I find that shipping more videos helps me more than shipping one really well produced video every week/month. So I choose the kind of video I make to fit the daily schedule whereas for Rust Adventure videos, I can spend a bunch of time on any level of production because the shipping schedule is once a month or so.
@@dealloc Thanks but it was not the point of my question. I was specifically curious about Chris workflow given I love the output. It's like asking a Chef you like some tips, yet you know how to cook.
Agreed. React does not translate well to Rust-that and trying to write web apps in Rust, which is another rant I could go on and on about. For fetching, you should not use useEffect directly as it is a footgun. Rather, use abstractions like React Query, swr and the like for dealing with async operations and their state, caching and optimistic updates for a better UX.
Thanks for this update and the refactoring. After the last video I thought: that’s okay, but there must be cleaner way to do this. I am happy you demonstrated this way 👍
I hope to see you back on yt some day :) I really enjoyed the raytracer serie
@@workflowinmind definitely planing further videos in the future. As soon as I have the needed free time again. This time will hopefully come sooner then later 😁
Great job Chris, this is much better, pr this maybe? I tried using yew and it just felt like a huge mess for someone who doesn't really know what components and all these things mean so any contribution would be beneficial to the yew project.
If you don't know what components are, I suggest starting with React. Yew tries to copy React's APIs into a Rust environment, which I personally don't think works well. Rust has so much more powerful syntax than JS that it just doesn't make sense to make an almost 1:1 copy.
Another thing is that it just doesn't feel like you're writing Rust but still have to deal with all the safety guards that Rust provides which makes it very unmanageable imo.
That and if you want to write web apps, use TypeScript instead. There's a lot of overhead using WASM on the web, let alone using a memory managed programming language to deal with DOM APIs (i.e. event listeners). Start with React as it has the widest range of resources and is for the most part is backwards compatible (except unstable APIs that you likely aren't going to use yet), and their React Beta docs are also fantastic to learn about components in general.
If they want this work contributed I might PR it. I assume they chose functional components for a reason to reach a specific audience. The "functional component" concept got really popular in the JS ecosystem a few years ago. I'm hanging out in their discord now so should be able to find out.
@@dealloc yes, it felt quite foreign and restrictive comparing to the Rust I'm used to writing, the documentation isn't the greatest as well. I'd really like to see Rust succeed in the web space
@@chrisbiscardi 👍
@@dyslexicsteak897 I'm sure it will, just not for web UI/DOM in my opinion. There's still a bright future for compiled languages using WASM for more computational tasks like rendering, physics, audio, emulation and the like.
I agree with this refactoring! It's intuitive
This makes much more sense then the tutorial version!
Totally unrelated, but have you ever talked about your tutorial workflow/setup?
I want to get back into doing tutorials (VFX/CG related) and would like to have "strict guidelines" and setup to not have to think about it much.
Like do you record long sessions that you edit down?
I feel like you manage to optimise time very well in these. No mumbling and not epileptic edit either, very good balance
Whatever makes you most productive is what matters. Some record long videos and cut them later, some also write a script or at least an outline to follow to make the video more coherent and avoid talking too much detail which can make it hard to follow. Others don't do it at all and can just talk coherently about a subject on the spot. People have different skills and workflows.
There aren't strict guidelines. It's what you find works for you. You'll only learn and adapt your workflow by doing it.
I haven't talked much about my workflow. For youtube since I do daily videos it's very lightweight and has to be end-to-end finished in maybe 2 hours tops or I won't be able to ship a video. Some days I invest more, but I also have other work to do each day. The breakdown is roughly:
1. get the example ready before the video
2. talk through the code/etc and record in obs (20m-1h recording)
3. remove silence programmatically
4. edit any umms, coughing, or bad takes out (davinci resolve, one playback)
5. generate captions and review
For me, I find that shipping more videos helps me more than shipping one really well produced video every week/month. So I choose the kind of video I make to fit the daily schedule whereas for Rust Adventure videos, I can spend a bunch of time on any level of production because the shipping schedule is once a month or so.
@@dealloc Thanks but it was not the point of my question. I was specifically curious about Chris workflow given I love the output. It's like asking a Chef you like some tips, yet you know how to cook.
@@chrisbiscardi Thanks! That's very insightful and I completely share you later point! I will try to adapt it and see how it goes tysm
🙌
I did exactly the same in my project. These use_effect-like hooks are atrocious. Feel like some js developers trying Rust for the first time…
Agreed. React does not translate well to Rust-that and trying to write web apps in Rust, which is another rant I could go on and on about. For fetching, you should not use useEffect directly as it is a footgun. Rather, use abstractions like React Query, swr and the like for dealing with async operations and their state, caching and optimistic updates for a better UX.