The architecture seems more closer to React before Fiber. It seems that you can't interrupt an update / reconciliation with a higher priority update. For that you can't use functions but you would somehow needs to be able to yield control back instead of forcing to complete reconciling / rendering the whole tree. Fiber does with a tree-like structure (and thus heap allocations and dynamic dispatch). But I think for Rust a better primitive will some kind of a state machine like generators. Instead of a function each child becomes a generator which can yield control back if it's interrupted or resume inner generators.
You're correct that there's no cancellation/interruption mechanism right now, and my overall thought is that it may be possible to avoid needing it. Ask me in a year or so how that has worked out :P. (FWIW I am eagerly looking forward to the async/await work resulting in generators possibly being available in stable surface rust)
@@adamperry7294 Can recommend looking into, and perhaps get some inspiration from, Crank.js. It's influenced by React, but does away with hooks by using generators and async/await to control the lifecycle of components. This essentially allows you to mix side effects and rendering without encapsulation.
He's saying no_std, which means the code can run without the standard library. This is useful when there's no operating system available, like in web assembly.
The web interfaces shown in this talk are extremely stringly-typed, because that's how the web is. I'm in the process of building up some typed wrappers around the stringy APIs, along with XML syntax, etc etc etc. Nothing about moxie itself necessitates weakly typing your UI elements -- they are "just" functions (with a little macro sprinkled on top). In time we should have nearly the full expressive power of Rust functions when defining the shape of your UI this way. Other binding crates may never go through a stringly-typed intermediate stage, because they for example might work with an API that is statically typed at its lowest level.
The architecture seems more closer to React before Fiber. It seems that you can't interrupt an update / reconciliation with a higher priority update. For that you can't use functions but you would somehow needs to be able to yield control back instead of forcing to complete reconciling / rendering the whole tree. Fiber does with a tree-like structure (and thus heap allocations and dynamic dispatch). But I think for Rust a better primitive will some kind of a state machine like generators. Instead of a function each child becomes a generator which can yield control back if it's interrupted or resume inner generators.
You're correct that there's no cancellation/interruption mechanism right now, and my overall thought is that it may be possible to avoid needing it. Ask me in a year or so how that has worked out :P.
(FWIW I am eagerly looking forward to the async/await work resulting in generators possibly being available in stable surface rust)
@@adamperry7294 Came to ask, how has that worked out? :P
@@adamperry7294 Can recommend looking into, and perhaps get some inspiration from, Crank.js. It's influenced by React, but does away with hooks by using generators and async/await to control the lifecycle of components. This essentially allows you to mix side effects and rendering without encapsulation.
Fantastic quality video and audio, thanks.
This looks awesome. Definitely one to check out.
Wow, this is pretty cool stuff.
so what's the update about this subject?
12:52 "I real want this to work ...??!?'"
Transcript says "understood" but that doesn't make sense, right? 🤨
He's saying no_std, which means the code can run without the standard library. This is useful when there's no operating system available, like in web assembly.
Haha what a fun talk!
Looks pretty stringly-typed... I guess it has to be in order to target the web? To support custom dom elements and what not
The web interfaces shown in this talk are extremely stringly-typed, because that's how the web is. I'm in the process of building up some typed wrappers around the stringy APIs, along with XML syntax, etc etc etc.
Nothing about moxie itself necessitates weakly typing your UI elements -- they are "just" functions (with a little macro sprinkled on top). In time we should have nearly the full expressive power of Rust functions when defining the shape of your UI this way.
Other binding crates may never go through a stringly-typed intermediate stage, because they for example might work with an API that is statically typed at its lowest level.