render() {
      var person = model.person
      return <div>
      <span>{person.name}</span> - {person.power_level}
      <button onClick={this.tapIncreasePowerLevel} />
      </div>
    }

[1] https://github.com/leeoniya/domvm

[2] http://mathieuancelin.github.io/js-repaint-perfs/domvm/index...

[3] http://mathieuancelin.github.io/js-repaint-perfs/

As a result, old advice about separating code from templates does not apply. Combining code and templates is the right thing to do in React, and JSX is far more pleasant to read and write than the native function call syntax, which is still available if you really don't like JSX.

If you haven't tried it, you should.

jsx is just more natural for designers but i agree with the gp that the benefits can be obtained with plain declarative js and avoid all the tooling required for jsx.

Most developers have never used a virtual-dom library, especially those that find JSX offensive. Your sales pitch for your library is coming off pretty aggressive, and it's a bit off topic. No one is talking about render speed.

> JSX is far more pleasant to read and write than the native function call syntax

No, it isn't. XML is both hard to read and write. It's for machines, not humans. Besides that, mixing two languages with two very different syntactic structures together is a recipe for disaster. And besides that, you now need an additional compilation step because it's not plain JavaScript. What works much better is something like Mithril's templating API, which is concise and pure JavaScript.

That's a very accurate observation and it's a very strong argument against React.

It's like they saw "code is data" and reversed it (rock star developers do not believe in formal logic theory).

The result is a language with all the beauty of 2001's PHP and the modernistic pretentiousness of pseudo-functional JS. Calling it React is just adding insult to injury by taking a huge crap of the solid Rx research in .NET that actually brings something new to the table.

The PhD's at Microsoft Research-Cambridge, Bart deSmet (MS-guys, I can't believe you pulled him off language development for Cortana) and the rest of the Rx team must be vomiting at what came out of their mathematically sound (often wholly proven within F*[3]) Rx work, but at the same time praising whatever deity that their name isn't attached to it. At least they're adhering to the interface signature of IObserver<T>.

Digression -- but anyone who is interested in the duality (not in the mathematical sense of 'duals) between LINQ operators and monadic operators, watch this talk with de Smet[1]. It's brilliant in it's ability to reduce all of LINQ to 5 [or less, .SelectMany() is to LINQ as NAND is to gate logic; it's later proven that 3 operators are all that are required, no surprise there, Kleisli triple anyone?] and shows with great elegance the isomorphism between monadic Haskell and LINQ. (And why RX falls so naturally out of .NET as a result.)

[1] https://channel9.msdn.com/Shows/Going+Deep/Bart-De-Smet-MinL... [2] http://community.bartdesmet.net/blogs/bart/archive/2010/01/0... [3] https://fstar-lang.org/ - to be formally presented at POPL '16. I'd offer commentary but it wouldn't do justice - any PL nerds should give that a read immediately, assuming they haven't already. MSR is without a doubt the Bell Labs of our generation.

Yes, you've expressed my point better than I could. Other commenters have thought that I dislike JSX because I like separate, string-based templating languages, but I think those are terrible! I hate JSX from a language design standpoint. Writing HTML templates as functional code in your language of choice is a big win, but inventing a new language "with all the beauty of 2001's PHP and the modernistic pretentiousness of pseudo-functional JS" is a big lose.

http://franz.com/support/documentation/current/doc/aserve/ht...

http://weitz.de/cl-who/

[1] http://mithriljs.org

Seems that everyone is busy coming up with convoluted ways to do the same old thing (manipulating the DOM). When I look at early jQuery era front-end code, it's quite easy to follow what's going on. The language (ES3) was simpler, and the competing libraries at the time provided thin abstractions on top of the DOM API.

The DOM was more or less complete when DOM Level 3 was specified in 2004. How much of the front-end code being written now, will be able to be easily understood and maintained in ten years time, after the trendy fads have come and gone? Maybe that question is irrelevant since most business fail within that timeframe, but for posterity's sake, I'd like to look back and learn what went well and what went horribly wrong.

Eventually, the kind of virtual DOM will move to either some standard API (via a way of committing changes in a transactional manner) or into the next iteration of the DOM API itself, so yes, none of the VDOM libraries will survive the next 5 years.

For now, VDOM libraries are a necessary evil, not some revolutionary concept like many people seem to try to make us believe.

It doesn't even make sense to standardize VDOM since it's just an implementation detail.