Replies: 1 comment
-
|
Hello @xania Impressive benchmark that you have here. Congratulations! Very interesting topic, I think that there is a lot to say :) First of all, the blockdom library is meant to be used as a low level rendering engine for an actual framework. In this case, I actually built owl (https://github.com/odoo/owl) on top of blockdom for odoo. It is a real framework used in production, in real apps, with real users :). I need to do a branch on the js framework project to compare owl with other frameworks. i expect it to have a pretty good score (but more like 1.10/1.15 because of the overhead of owl semantics with asynchronous rendering and scheduling) But then, the framework using blockdom can choose to implement its own semantic. Owl chooses a class based component system, with asynchronous/blocking rendering: if the component uses the onWillStart hook, then its rendering will be delayed until the result of the function is received. Also, if it is involved in a rendering with other components, owl will wait until all components are ready before applying them to the dom, in one atomic step. So, to summarize, blockdom itself does not deal with stale closures, promises and observables. It is the problem for the layer above it, in my case, Owl. And owl does not have stale closures since it uses classes. It creates an instance of the component initially, then keep it around, and render the template when necessary with the current instance as rendering context. It deals with promises and asynchronous code by having a scheduler that coordinates how all renderings are applied (internally, it has a pretty sophisticated system to track pending renderings, cancel them, restarts them to avoid concurrency issues). Also, Owl wait for an animation frame to back all screen updates. About observables, Owl has a reactivity system kind of similar to Vue. It uses proxy to track which components should be updated. Now, I agree with you that rendering once, then updating with signals seems like a good solution. I am considering rewriting the owl rendering engine to experiment with it. But , but it has some issues. For example, solidjs had to provide a batch function to prevent unnecessary work in some cases. It feels like an abstraction leak to me. And now, owl never triggers more than one rendering if multiple state changes occurs in the same call stack. Also, Owl want to batch all updates together at the next animation frame. So, it is unclear if such a strategy will help much. It could even be possible that using observable to update the screen independently many times in an animation frame is less efficient than rendering a template once outside an animation frame (so doing some cpu work at a moment where it has no visual impact), then updating the screen once (at the last moment where it has a visual impact). Also, note that owl templates are incredibly small: they are basically a short function that returns the dynamic parts of the template. They do not render a large vdom tree, they just "capture" the current values from the context, in a block tree form, ant that's it. Well, it feels like I may have rambled incoherent thoughts. I hope it helps :). If you have any questions, or feedback on how I could improve blockdom/owl, really don't hesitate, i am very interested in this topic. Also, I will check out xania, it looks interesting |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, author of xania here
The concept of virtual dom is clearly not only for faster and better developer experience, but can also be very performant as displayed by the impressive benchmark results. Honestly I didnt expect a vdom implementation to be this fast.
Based on my experience with React I have a question,
I started development of xania because i believed that React re-rendering behavior could not reconcile vdom with first class support for promises, observables and other structures that emit 0, 1 or more values over time
Also, re-rendering in React turns out to be causing a lot of issues and complications in user code measured by the number of hooks and there nuances.
Only solution I was able to come up with to prevent re-rendering (which is essential in a vdom implementation) is fine-grained reactivity.
So my question, how does blockdom solve deal with stale closures, promises and observables?
Beta Was this translation helpful? Give feedback.
All reactions