5 ms·
It seems obvious to me the next generation front end frameworks will not use a virtual DOM, which at this point seems antiquated and slow.
by 65 2y ago
It seems obvious to me the next generation front end frameworks will not use a virtual DOM, which at this point seems antiquated and slow.
- rglover 2y agoIt's either VDOM or having to depend on a compiler to do everything (how Svelte works). The advantage to the former is it's relatively easy to debug, whereas with a compiler, I'm at the mercy of its developer and their whims. VDOM may be "antiquated" (I mean it's a nested object or linked list which are standard paradigms) but slow depends on what you're doing. I did a linked list for my own full-stack framework's [1] component library and it's quite snappy. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
- yesbabyyes 2y agoLit does not use a virtual DOM, nor require a compile step. Instead, it utilizes object accessors and tagged templates to figure out when to schedule an update.
- recursive 2y ago> It's either VDOM or having to depend on a compiler to do everything (how Svelte works). Assuming you don't mean JSX transform by "compiler", you really don't have to do either one. For my framework [1], state is directly bound to DOM elements. Dependencies are determined at run time. It's not slow. [1] https://mutraction.dev/ https://mutraction.dev/
- rglover 2y agoDependencies meaning other components or something else? And if I understand correctly, you're forming relationships between parents/children by setting extra properties on the DOM nodes themselves (e.g., node.mutraction_parent = <Some Other DOM Node>)?
- recursive 2y agoNo. Dependency means a state/data dependency that would require a UI update. You never need to explicitly assign tree relationships like parents. Here's the example code from the front page. In this case, `model.clicks` is a dependency. const model = track({ clicks: 0 }); const app = ( <button onclick={ () => ++model.clicks }> { model.clicks } clicks </button> ); document.body.append(app);
- rglover 2y agoGotcha. Interesting...how does it work? Sounds like a pretty novel way to solve the problem.
- recursive 2y agoEssentially object proxies. When you invoke a property getter in tracked contexts (like DOM element construction), a dependency is registered for that object property. When you invoke the corresponding setter, the update function for the list of dependencies are notified. That's the idea, in a nutshell. I'm definitely not the first one to come up with this idea, but I hadn't found another UI framework that worked exactly like how I wanted. Solid is kind of close, but not it. Vue has some of this as well, but it's a bit more kitchen-sink in its scope.
- rglover 2y agoThanks for sharing, that's a cool idea. Will have to wrap my head around it a bit more but got me thinking about how to strip vdom.
- WorldMaker 2y agoVirtual DOM has its charms. React is sort of synonymous with Virtual DOM, but isn't the only way to do Virtual DOM and it's probable other Virtual DOM front ends will continue to be built whether or not React goes away. At very least, Virtual DOM will survive at WASM borders if nowhere else. There's still talk of making it a lot easier to bind the DOM across WASM borders, but even then overhead may always be a strange trade-off making it useful to just pass a full Virtual DOM object to JS code on the other side of the border and letting it diff/patch. Most of the WASM-based front ends I've seen are generally some form of Virtual DOM under the hood. That said, yes, the possibilities in doing more "direct DOM manipulation" again and "Vanilla DOM" are exciting and it is a bit of flip from the brief period when major React fans thought Virtual DOM was the greatest. I've been seeing some cool results in my own "non-Virtual DOM" projects.