> Kobold does not have a concept of a stateful component. The view rendering part is relatively unopinionated about state management. It is entirely feasible to implement React-esque hooks like in Yew or Dioxus as a 3rd-party crate. Reactive signals like in Sycamore or Leptops should also interact nicely with the View trait.
it seems that it's the manually manipulated ones that are at the forefront...
> I need to look closer. It does appear that the Millions implementation will get flagged as manual manipulation. So that might get changed to one a bit slower. I can't imagine anyone writing this code
There was a bug in ivi 2.0.0 with `shouldComponentUpdate` optimization, it was completely ignored. This benchmark submission rerenders and diffs everything on each change, all other `f(state) => UI` libraries in this benchmark are implemented with `shouldComponentUpdate` optimization. Also, unlike majority of libraries on the left side of the table, ivi doesn't use any type of event delegation(implicit or explicit) to get better results, just plain old `addEventListener()` is used internally to attach event listeners.
It’s a term borrowed from C++, a “zero cost abstraction.”
Some folks use “zero overhead abstraction” to try and make the concept a bit more clear, since everything has some cost somewhere. “Zero cost” can feel incorrect.
Blame Gary Gygax for coming up with the strange concept that kobolds are these weird reptilian creatures. I like "traditional" kobolds (https://en.wikipedia.org/wiki/Kobold) more. The cutest is probably this one: https://en.wikipedia.org/wiki/Meister_Eder_und_sein_Pumuckl#... - mind you, I wouldn't trust him to handle my UI either, but at least I wouldn't have to worry that he wants to chew my face off...
26 comments
[ 2.9 ms ] story [ 51.8 ms ] threadIn fact he mentions this at the end :
> It is entirely feasible to implement React-esque hooks like in Yew or Dioxus as a 3rd-party crate.
Looks like leptos could actually enhance this idea of `View`.
> Kobold does not have a concept of a stateful component. The view rendering part is relatively unopinionated about state management. It is entirely feasible to implement React-esque hooks like in Yew or Dioxus as a 3rd-party crate. Reactive signals like in Sycamore or Leptops should also interact nicely with the View trait.
You need either granular reactivity or diffing (or perhaps both), or else your framework's performance will easily be trash
> I need to look closer. It does appear that the Millions implementation will get flagged as manual manipulation. So that might get changed to one a bit slower. I can't imagine anyone writing this code
Those numbers aren’t _the best_, but given the improvement in TTI from only needing 3kb of framework that seems like a pretty good tradeoff.
Some folks use “zero overhead abstraction” to try and make the concept a bit more clear, since everything has some cost somewhere. “Zero cost” can feel incorrect.
Creating and adding DOM nodes is definitely not free, but I can see how this is very low overhead compared to VDOM diffing.
> What you don’t use, you don’t pay for (in time or space) and further: What you do use, you couldn’t hand code any better.
https://en.cppreference.com/w/cpp/language/Zero-overhead_pri...
Although:
https://www.youtube.com/watch?v=rHIkrotSwcc
I'm not sure whether Rust people consistently use it with precisely the same sense.
Sycamore is much closer to that 0 cost Rust frontend framework, but has gone through many improvements.