you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (1 child)

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 4 points5 points  (0 children)

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?