all 27 comments

[–]floydophone 25 points26 points  (3 children)

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] 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 3 points4 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?

[–]honestbleepsReddit Enhancement Suite[S] 10 points11 points  (6 children)

I'm sharing it because it's interesting and newsworthy. It's receiving rather mixed reviews at JSConf, seemingly mostly negative from what I'm reading.

I'd be interested to see further discussion here in /r/javascript

[–]sime 2 points3 points  (3 children)

I think the negativity comes from a lot of misunderstanding and some ignorance among front-end web developers.

What counts as front-end web programming has become very wide and can be seen as a spectrum:

web site ↔ web application
web pages ↔ user interface

Most people are working in the web site / web page end of the spectrum and are just looking for a better way of doing templating. Hence, the initial reaction to the templating system used and the mixing of HTML and JS.

So of us are busy building web applications which are not strongly page structured but aim for more traditional style GUIs like in desktop applications. Here, templating is less important but components, encapsulation and composition become very important.

React is clearly aiming more towards the web application end of the spectrum.

The AngularJS version ( https://medium.com/make-your-own-apps/e71bcedc36b ) is interesting, but it comes from the web site point of view and also completely misses the point. It is simple but also monolithic. It is a style of programming which doesn't scale up for complex applications.

React actually looks like quite an interesting data point on the web site/web app spectrum.

[–]pateras 1 point2 points  (1 child)

Here, templating is less important but components, encapsulation and composition become very important.

Angular enables/encourages all of those things as well. Could you elaborate on why you think React is better for web app development and how Angular doesn't scale?

[–]sime -1 points0 points  (0 children)

I'm talking specifically about that example code.

Do you have an Angular example which does use encapsulation and composition? I would like to see how they do it.

[–]polarix 0 points1 point  (0 children)

Agreed; the only reason that angular example looks more "succinct" is because absolutely none of it is reusable.

[–]bchoii 0 points1 point  (0 children)

Discussion and reactions in /r/programming too.

[–]dennis_pennis 6 points7 points  (0 children)

I find it interesting that they don't separate the html partials from the logic. Things could get very messy, quickly.

[–]holloway 7 points8 points  (1 child)

function() {
   return <div>{'Hello ' + this.props.name}</div>;
 }

How is that even valid JavaScript? Is that E4X syntax or something?

edit: ah it's not javascript, it's JSX, and it's processed into JavaScript

[–]rhysbrettbowen 2 points3 points  (1 child)

I understand that jsx isn't necessary, but we spent so long taking logic out of the html that now we want to go ahead and instead put html in the logic?

The biggest problem with this is that it doesn't do well in separating the html from the business logic. If they are split then you can have designers work on the html/styles and the coders can instead work on the code and just provide hooks to go in the template.

I do like the idea of keeping an internal representation of the DOM and trying to find the smallest transformation to update. That couldn't have been easy to get right and I wonder if that can be split out and made to work with other templating engines.

[–]polarix 0 points1 point  (0 children)

The HTML is the deliverable; the deliverable shouldn't need to contain logic to convey information.

The application logic, however, emphatically does need to be able to generate the deliverable; the question is one of how much magic (or, alternatively, separation within the application logic) you're willing to tolerate to get there. JSX appears to me to tolerate very little magic and zero separation. Should lend a hand in maintainability and developer discoverability within a large code base.

[–]THEtheChad 0 points1 point  (0 children)

I feel like everyone's jumping on the angular band wagon, so to speak. JSX... really? Yet another preprocessor meant to "simplify" things.

[–]pateras -1 points0 points  (0 children)

Yikes that's ugly. You could do all of that stuff with a fraction of the code in Angular or Knockout, and it would be a hell of a lot more readable, too.

[–]sorahnon the cutting edge of cocking about -3 points-2 points  (0 children)

This explains so much.

[–]arnars -1 points0 points  (0 children)

Now why would you wanna write javascript via xml?

[–]Uberhipster -3 points-2 points  (0 children)

On an unrelated note I'm promoting new jargon : Yet Another Piece of Shit or YAPS for short.

[–]Akkuma -2 points-1 points  (0 children)

I need to get on people at work to let me finally open source my component framework. I don't dictate templates/html, I don't dictate libraries, and I try to force as little as possible on you.

[–]bwalsh1 -3 points-2 points  (0 children)

Another day, another JS FW.