It'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

Lit 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.

> 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/

Dependencies 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>)?

No. 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);

Gotcha. Interesting...how does it work? Sounds like a pretty novel way to solve the problem.

Essentially 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.

Thanks 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.

Virtual 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.