V-DOM use cases 8000 #35
Replies: 1 comment 1 reply
-
|
Hello @orenelbaum This is a very interesting question, and actually, a question I studied a lot these last 3/4 years. And still, I feel that I only have a partial understanding of the topic. We are aware of solidjs work. I am a big fan. Also, I read this interview: https://itnext.io/designing-solidjs-suspense-f4e92c625cb5 a long time ago, which is really an interesting discussion on that topic. The short answer to your question is: yes, obviously, you don't necessarily a vdom for concurrent rendering. But it actually depends on what you mean by concurrent rendering. I'll come back to that later. To understand where I am coming from, I should explain that I work on the framework at Odoo, which uses its own framework (owl: https://github.com/odoo/owl). Since Owl was used to replace the previous implementation, it was required to have asynchronous rendering (as we called it back then). We struggled to implement it properly, then after a few months of work, we managed to implement a rendering pipeline using fibers, slightly inspired by react 16. Funnily enough, the day we merged our work was the day react announced their concurrent rendering mode in a blog. Anyway, this year, we are updating owl to owl 2 (see https://github.com/odoo/owl/tree/owl-next for a look at that work, should be ready in a month or so), and are using blockdom as the underlying virtual dom, which is really exciting. Note that at the same time, we updated our state solution to be much more fine grained: we are moving toward fine grained reactivity, where each component automatically subscribe to the properties that it uses, and will only be rerendered if they are modified. As promise, back to concurrent rendering. As I understand what solidjs is doing, since it has no virtualdom, what it does is maintain an alternative reality by creating the actual dom (using all the tricks solidjs does, like cloneNode and stuff), and updating the actual dom by replacing the old part with the new dom once ready. owl is doing it differently: it maintains a virtual block tree in memory (which is a very small structure with basically only the dynamic data) and does not need to create the DOM at all. only when the asynchronous stuff is done, then it can update the DOM and will patch the rendering to the screen. This has a different performance profile than solidjs. It does not need to touch any dom until the latest second. But there is a much bigger difference: all components in owl are a unit/atom of rendering. This means that the content of a component DOM will be updated atomically, every time. And this is different in the solidjs model: the component actually disappears from the runtime. So, once you update two values, one synchronous value and another that needs to wait, by default in solid, you may have your screen updating to display the first immediately, then later, will update the other. This means that the visible state may be inconsistent for a while. However, with owl, the screen update is delayed until the component is completely ready. By default, without using a suspense component. To get the same effect in solid, you need to coordinate the renderings with suspense components. Well, I have to go. Let's hope this text is coherent. Tell me what you think (in particular, what you mean by non optimal pattern. From my point of view, owl is a different set of trade offs than solidjs, and for some usecases, is better than solidjs)! I'll come back to this later :) |
Beta Was this translation helpful? Give feedback.
-
|
By nonoptimal patterns I mean unnecessary rerenders. With a V-DOM You can use patterns that you know are going to cause unnecessary rerenders, but it's ok since you don't take a significant performance hit. It enables things like nested routing in React Router 4 and "invisible" renders in GQty. As for performance, what benefits do you get from deferring DOM manipulation? In Solid 1.1 with scheduling enabled, off screen rendering has a lower priority than on screen rendering, so even if you are doing off screen DOM manipulation, you are not blocking anything else, so as far as I understand there are no significant drawbacks here as far as performance goes. As for your point about not needing suspense, it seems like an interesting feature, but doesn't seem necessary for concurrent rendering, and doesn't seem to be the reason you say in the docs that you need a V-DOM for concurrent rendering, as you mention React, which also doesn't have this feature. So if the reason you imply in the docs that you need a V-DOM for concurrent rendering is because of different performance profiles, I'd like to hear what are the actual performance benefits. Update: After digging more into this, I understand the performance benefit. With Solid you might render DOM nodes that would become unnecessary if you get updates during the transition. This shouldn't affect FPS, but could make the transition take longer than it would take with a V-DOM library. Are there any other performance benefits that you see other than that? BTW I'm sorry if I came off a bit harsh, I didn't mean to. I just wanted to get to the bottom of this. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, I was reading the readme, and the premise of the library seems really cool!
I saw in the section "About this project" the paragraph about why do we need a V-DOM. It implies that you need a V-DOM in order to achieve concurrent rendering.
I'm not sure if you guys know this, but Solid supports concurrent rendering as well, which seems to show that you don't necessarily need a V-DOM for concurrent rendering.
So I was wondering if you guys knew about it and what do you guys think?
It seems to me that the main benefit of V-DOM is as a safety net that allows you to use nonoptimal patterns without taking significant performance hits. I would love to hear your thoughts.
Beta Was this translation helpful? Give feedback.
All reactions