Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is absolutely true.

Virtual DOM diffs do a huge amount of unneeded work because in the vast majority of cases a renderer does not need to morph between two arbitrary DOM trees, it needs to update a DOM tree according to a predefined structure, and the developer has already described this structure in their template code!

A large portion of JSX expressions are static, and renderers should never waste the time to diff them. The dynamic portions are clearly denoted by expression delimiters, and any change detection should be limited to those dynamic locations.

This realization is one of the reasons for the design of lit-html. lit-html has an almost 1-to-1 correspondence with JSX, but by utilizing the static/dynamic split it doesn't have to do VDOM diffs. You still have UI = f(data), UI as value, and the full power of JavaScript, but no diff overhead and standard syntax that clearly separates static and dynamic parts.

The syntax is very close:

JSX:

   render(props) {
     return <>
       <h1>Hello {props.name}</h1>
       {props.items
          ? <ol>{props.items.map((item) => 
              <li>{item.label}</li>)}
            </ol>
          : <p>No Items</p>}
     </>;
   }
lit-html:

   render(props) {
     return html`
       <h1>Hello ${props.name}</h1>
       ${props.items
          ? html`<ol>${props.items.map((item) => 
              html`<li>${item.label}</li>`)}
            </ol>`
          : html`<p>No Items</p>`}
     `;
   }
I really think the future is not VDOM, but more efficient systems, and hopefully new proposals like Template Instantiation can advance and let the browser handle most of the DOM updates natively.

edit: closed JSX fragment as pointed out



Typo -- you didn't close your fragment on the JSX.


> I really think the future is not VDOM, but more efficient systems, and hopefully new proposals like Template Instantiation can advance

Template Instantiation is like a half of a half of 1% "advance" in the best case scenario. It's being rushed forward despite the fact that no one sat down and listed all the benefits vs. all the downsides of implementing it in the browser.

What browsers do need is a declarative DOM API and a native "DOM as a function of state" which renders the whole instantiation proposal moot, and at the same time actually advances the browser as a platform.

There's a discussion on GitHub which in my opinion is going nowhere because TI is viewed as unquestionable good https://github.com/w3c/webcomponents/issues/704


One thing nice about React is that it can take care of quoting for you depending on the method call the jsx template translates into (attribute, value, element name). String templates doesn’t have that nice property.


Can you explain that more?

I'm not sure what you're saying is true with lit-html. You don't have to quote attributes with single expressions.

    html`<div class=${myClass}></div>`
is perfectly fine.


Ah, thanks for pointing that out.


lit-html is context-aware and safe, just like JSX. It's not a raw string templating library.

https://lit-html.polymer-project.org/guide/template-referenc...


Do you use lit-html?

The idea is interesting. It looks more procedural than say preact, but I also appreciate the directness.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: