If you're interesting in a reactive template library that doesn't require a compiler for non-standard JavaScript syntax, check out a library I've been working on for a little while now, lit-html: https://github.com/Polymer/lit-html

Where JSX would look like this:

    const view = (state, actions) => (
      
        {state.count}
         actions.down(1)}>-
         actions.up(1)}>+
      
    )

The lit-html would be:

    const view = (state, actions) => html`
      
        {state.count}
         actions.down(1)}>-
         actions.up(1)}>+
      
    `;

Nearly identical. lit-html uses ``s and cloning, so that it doesn't have to do any expensive VDOM diffs.

JustSomeNobody

> ... expensive VDOM diffs

Wait, I thought VDOMs were supposed to be fast(er).

Note: I'm not a FE Dev, so I'm only going by stuff I (think I) read, not write.

acdha

It ultimately comes down to Amdahl's law: doing something in a browser requires updating the DOM. Since you always have to do the DOM processing, the only way adding the extra virtual DOM work will be a net win is if it makes it easier to avoid unnecessary updates or allows something like ordering updates to avoid triggering repeated layouts / reflows[1].

Since updating the DOM is relatively fast in modern browsers it's not particularly hard to find cases where the work the virtual DOM has to do cancels out any savings.

1. See e.g. https://developers.google.com/web/fundamentals/performance/r..., a list of triggers at https://gist.github.com/paulirish/5d52fb081b3570c81e3a, and https://github.com/wilsonpage/fastdom for a common technique to avoid it by manually ordering read operations before writes.