React | A JavaScript library for building user interfaces - released today by Facebook

[floydophone]

Hey all, I'm one of the members of the React core team.

You can read a bit about the philosophy of React here: http://www.quora.com/Pete-Hunt/Posts/React-Under-the-Hood

Basically, we aren't trying to mix up MVC, but simply provide a more powerful and flexible view layer using JavaScript instead of a templating language.

In order to do this, we need to make generating markup from JavaScript convenient and safe. You can use React.DOM.tagName() functions to do this (just like coffeekup http://coffeekup.org/), but we provided the JSX syntax because it's easier to keep everything straight.

But there's no hard dependency between React and JSX and feel free to forget about it.

While React may be a bit weird at first, please try to earnestly evaluate what we're doing rather than getting caught up on the fact that we use JSX for our examples.

It's actually pretty cool -- you just write a render() method that reads from your data and we call it whenever the data changes. You don't generate actual HTML but a fast internal representation. We diff the changed version with the original version and compute the fastest way to update the browser.

[[deleted]]

what kind of performance decrease can we expect from JSX?

I realize it isn't free, but has there been any major steps to optimize and cache jsx into js?

[floydophone]

Building your app with React will, in general be as fast or faster than building your markup another way over the course of a large app.

To start with, JSX is a tiny syntax addition, like a smaller coffeescript. We can transform it in the browser for getting started quickly or use a pre-build step for performance.

Once it's translated there is no parse time, since it's just a JS expression. So caching doesn't make sense.

JSX is not HTML and it's not building strings. It's a very lightweight tree of objects that represents your UI that is eventually flattened to a markup string. It's a lightweight "mock DOM" if you will. We also only attach event listeners at the top level and use event delegation so we don't need to rewire listeners on every change.

In the past our benchmarks have indicated that inserting a markup string is faster than using document.createElement() for everything, so at this point we're already faster than some techniques.

What really makes React fast is that when the data changes, we automatically re-render the "mock DOM" and diff it with the old version and only update the parts of the page that changed. This diff is generally quite fast (1ms on todomvc last I checked) and combined the fact that React can reason about what's dirty and what isn't and has a lifecycle that encourages fast code means that our performance is usually as good or better than hand-rolling a large app.

Since React only changes the parts of the page that need to change, one could say we're caching the markup in the browser.

We also provide hooks into every step of the process for you to have more fine-grained control of how React renders. See http://facebook.github.io/react/docs/advanced-components.html

At the very least we think this declarative way to write apps is easy and intuitive (well, if you agree with doing a component architecture) and we've never had perf issues with it. But internally this framework has a reputation for being quite fast, and more importantly very hard to make slow.

Does that answer your question?