5 ms·

That's a great question. React is designed for building big UIs. The type where you have lots of reusable components that are handling events and presenting an

That's a great question. React is designed for building big UIs. The type where you have lots of reusable components that are handling events and presenting and changing some backend data. In a traditional MVC app, React fulfills the role of the view (and maybe the controller, depending on your definition). React's technique is to break your view down into smaller, composable components. These components provide a render() method which specifies how the component will generate its markup. render() can either return normal DOM elements (like <div>s) or can return other components. When your data changes, the render() method is called again. We compare the old render()'d version with the new one and the framework determines the most efficient way to update the DOM. Often this will be faster than hand-coding it, as React knows about the entire state of the page and can do cool tricks like batching reads and writes. The way we're able to pull this off is by constructing a very fast, lightweight representation of the DOM which knows which parts are dirtied and which parts are clean. Because this rerender is so fast (on the order of 1ms for TodoMVC), we don't need the end user to explicitly specify data bindings. We've found that this is an easy way to build apps. We have many examples of using React with Backbone as the backend, or using it in conjunction with something like Bootstrap's JS widgets. They're available at https://github.com/facebook/react/tree/master/examples/ https://github.com/facebook/react/tree/master/examples/. Does this answer your question? As we've just launched I could definitely use some feedback on how we could explain it better!

simonw 13y ago
Wow, OK. This could definitely do with being included in the introduction - my first impression was "calling render() all the time and rebuilding the chunk of HTML must result in terrible performance on mobile devices etc". Your explanation here makes the whole system make a ton more sense.
jonahx 13y ago
Hey Peter, Thanks for answering. It's nice to know the technical details, and I feel like you partially answered my question, but I'm still not 100% clear on the advantages over angular. What I gathered from your answer is that 2 advantages are: 1. It's faster than angular. Perhaps able to handle larger applications with tons of things going on better? But how large is large? I want to see an example app that React handles easily and angular struggles with. I know the Todo App example is mandatory, but angular (and every other framework) handles those well already. 2. It's perhaps easier to code and maintain than angular. I'm guessing this from your comment about data-bindings being unnecessary. But I'm not totally clear, as data-binding and updates are automatic in angular. I know there are politics involved when comparing yourself to a competitor, and most programmers seem to be overly respectful of their peers, which I can appreciate. But it's too easy to fall back on the party lines "X and Y solve different problems", "X and Y have different strengths", and "You should try both out and decide for yourself!" As a framework user, these kinds of niceties are unhelpful and frustrating. It shouldn't be considered rude or disrespectful to factually list the advantages of your framework over the obvious alternatives. It is, after all, the only thing I'm really interested in as a user. So my suggestions would be: A bullet point list of advantages of this framework over angular, being as clear and specific as possible. If they're good for different situations, I want to know what those situations are. A big showcase app with the tons of components you alluded to, all working in beautiful harmony. I should be able to click a link to see the demo, not have to pull from github. And ideally there would be some accompanying walkthrough showing code snippets for various parts of the app, and explaining why they are so awesome. Hope that helps!
- peterhunt 13y ago
  Agh, I tried to reply but failed miserably, reply is here: https://news.ycombinator.com/item?id=5789890 https://news.ycombinator.com/item?id=5789890
grannyg00se 13y ago
"...we don't need the end user to explicitly specify data bindings. " Aren't the data bindings going to be explicitly specified within the render function?
peterhunt 13y ago
jonahx - I wish we had some bigger examples checked into the repo. I'll work on fixing that. A few things: - We've built lots of big components on Facebook and all of Instagram.com with it. Those are pretty big apps (though I know, you're asking for code and want proof). - I think that composing UIs with JavaScript and components is easier than using directives or a templating language. For example, because Angular uses ng-repeat to construct lists, if you want alternating row colors you use something like ng-class-even. I think that creating a new directive for every use case is less intuitive than how you'd do it in React: http://pastebin.com/maw6uSMG http://pastebin.com/maw6uSMG (paste it into the live editor on the React homepage to try it) We could be more flexible than that. Let's say we wanted to, for some reason capitalize every other row. With Angular we'd need to create a new directive, with React it's just: http://pastebin.com/39fik9W9 http://pastebin.com/39fik9W9 What do you think?
- eric_bullington 13y ago
  If is as fast as described, it's a godsend to Backbone developers. I love Backbone, but as I described below, I've ended up learning AngularJS because handling the DOM can be so tricky and cumbersome when you use Backbone. And AngularJS is a great project that definitely solves most performance issues, but as you pointed out, many facets of directives are pretty unintuitive. And integrating third-party libraries is a pain with AngularJS. So I'm really excited about trying this out. I really like the sample you put on pastebin -- very intuitive for Backbone devs.
  - abcbaby 13y ago
    have you played with marionette.js ? it builds a lot of very useful features on top of backbone
- jonahx 13y ago
  peter, thanks for the examples. it actually seems analogous to angular. the "createClass" bit is like a directive definition, and the "renderComponent" bit is like your new declarative markup. i do agree that angular can be complex and opaque, especially once you start to delve into the internals (compiling, priority, transclusion, etc), and avoiding that complexity is a good selling point. if i were you, i would hit that hard :) that said, those examples don't seem all that different to me than the angular way. maybe the simplicity would start to shine in more complex use cases. again, a good toy problem that requires angular gymnastics to solve, side by side with a straightforward react version would be compelling. my final and important question is this: you mentioned react only solves the view problem. does that mean if i want to migrate from angular to react that i would have move from angular to "react + backbone" or "react + something else"?
KaoruAoiShiho 13y ago
React's technique is to break your view down into smaller, composable components. These components provide a render() method which specifies how the component will generate its markup. render() can either return normal DOM elements (like <div>s) or can return other components. When your data changes, the render() method is called again. We compare the old render()'d version with the new one and the framework determines the most efficient way to update the DOM. Often this will be faster than hand-coding it, as React knows about the entire state of the page and can do cool tricks like batching reads and writes. The way we're able to pull this off is by constructing a very fast, lightweight representation of the DOM which knows which parts are dirtied and which parts are clean. This describes angular, that's what angular does. Edit: Well it's similar to what angular does, the intent is the same, but it doesn't know the state of the DOM among other things. Because this rerender is so fast (on the order of 1ms for TodoMVC), we don't need the end user to explicitly specify data bindings. We've found that this is an easy way to build apps. Is this faster than angular? Benchmarks please!
- peterhunt 13y ago
  Angular's got a lot of great ideas, but the key difference is how you build with React. Angular's directives are pretty similar conceptually to React components, yes. But Angular requires you to imperatively manipulate the DOM in its linking functions, whereas with React you declaratively specify how you want your component to look and when it changes state the framework computes the fastest DOM manipulations for you, which we think saves you some work and is often more performant. If I had thorough benchmarks available I'd provide them, but sadly benchmarking things correctly is a lot of work and I just don't have time :/ You could try to play around with both frameworks' TodoMVC examples with Chrome's devtools to compare them, though.
  - gregwebs 13y ago
    Angular douesn't require you to use linking functions. They aren't necessary for 90% of the time when you can just use a template and a controller. It would be interesting if you provided an example in React of something that did require a linking function in Angular.
shaydoc 13y ago
I use KnockoutJS, would there be anything in particular you feel React has going for it over knockout ?

simonw 13y ago

Wow, OK. This could definitely do with being included in the introduction - my first impression was "calling render() all the time and rebuilding the chunk of HTML must result in terrible performance on mobile devices etc". Your explanation here makes the whole system make a ton more sense.

jonahx 13y ago

Hey Peter, Thanks for answering. It's nice to know the technical details, and I feel like you partially answered my question, but I'm still not 100% clear on the advantages over angular. What I gathered from your answer is that 2 advantages are: 1. It's faster than angular. Perhaps able to handle larger applications with tons of things going on better? But how large is large? I want to see an example app that React handles easily and angular struggles with. I know the Todo App example is mandatory, but angular (and every other framework) handles those well already. 2. It's perhaps easier to code and maintain than angular. I'm guessing this from your comment about data-bindings being unnecessary. But I'm not totally clear, as data-binding and updates are automatic in angular. I know there are politics involved when comparing yourself to a competitor, and most programmers seem to be overly respectful of their peers, which I can appreciate. But it's too easy to fall back on the party lines "X and Y solve different problems", "X and Y have different strengths", and "You should try both out and decide for yourself!" As a framework user, these kinds of niceties are unhelpful and frustrating. It shouldn't be considered rude or disrespectful to factually list the advantages of your framework over the obvious alternatives. It is, after all, the only thing I'm really interested in as a user. So my suggestions would be: A bullet point list of advantages of this framework over angular, being as clear and specific as possible. If they're good for different situations, I want to know what those situations are. A big showcase app with the tons of components you alluded to, all working in beautiful harmony. I should be able to click a link to see the demo, not have to pull from github. And ideally there would be some accompanying walkthrough showing code snippets for various parts of the app, and explaining why they are so awesome. Hope that helps!

peterhunt 13y ago
Agh, I tried to reply but failed miserably, reply is here: https://news.ycombinator.com/item?id=5789890 https://news.ycombinator.com/item?id=5789890

grannyg00se 13y ago

"...we don't need the end user to explicitly specify data bindings. " Aren't the data bindings going to be explicitly specified within the render function?

peterhunt 13y ago

jonahx - I wish we had some bigger examples checked into the repo. I'll work on fixing that. A few things: - We've built lots of big components on Facebook and all of Instagram.com with it. Those are pretty big apps (though I know, you're asking for code and want proof). - I think that composing UIs with JavaScript and components is easier than using directives or a templating language. For example, because Angular uses ng-repeat to construct lists, if you want alternating row colors you use something like ng-class-even. I think that creating a new directive for every use case is less intuitive than how you'd do it in React: http://pastebin.com/maw6uSMG http://pastebin.com/maw6uSMG (paste it into the live editor on the React homepage to try it) We could be more flexible than that. Let's say we wanted to, for some reason capitalize every other row. With Angular we'd need to create a new directive, with React it's just: http://pastebin.com/39fik9W9 http://pastebin.com/39fik9W9 What do you think?

eric_bullington 13y ago
If is as fast as described, it's a godsend to Backbone developers. I love Backbone, but as I described below, I've ended up learning AngularJS because handling the DOM can be so tricky and cumbersome when you use Backbone. And AngularJS is a great project that definitely solves most performance issues, but as you pointed out, many facets of directives are pretty unintuitive. And integrating third-party libraries is a pain with AngularJS. So I'm really excited about trying this out. I really like the sample you put on pastebin -- very intuitive for Backbone devs.
- abcbaby 13y ago
  have you played with marionette.js ? it builds a lot of very useful features on top of backbone
jonahx 13y ago
peter, thanks for the examples. it actually seems analogous to angular. the "createClass" bit is like a directive definition, and the "renderComponent" bit is like your new declarative markup. i do agree that angular can be complex and opaque, especially once you start to delve into the internals (compiling, priority, transclusion, etc), and avoiding that complexity is a good selling point. if i were you, i would hit that hard :) that said, those examples don't seem all that different to me than the angular way. maybe the simplicity would start to shine in more complex use cases. again, a good toy problem that requires angular gymnastics to solve, side by side with a straightforward react version would be compelling. my final and important question is this: you mentioned react only solves the view problem. does that mean if i want to migrate from angular to react that i would have move from angular to "react + backbone" or "react + something else"?

KaoruAoiShiho 13y ago

React's technique is to break your view down into smaller, composable components. These components provide a render() method which specifies how the component will generate its markup. render() can either return normal DOM elements (like <div>s) or can return other components. When your data changes, the render() method is called again. We compare the old render()'d version with the new one and the framework determines the most efficient way to update the DOM. Often this will be faster than hand-coding it, as React knows about the entire state of the page and can do cool tricks like batching reads and writes. The way we're able to pull this off is by constructing a very fast, lightweight representation of the DOM which knows which parts are dirtied and which parts are clean. This describes angular, that's what angular does. Edit: Well it's similar to what angular does, the intent is the same, but it doesn't know the state of the DOM among other things. Because this rerender is so fast (on the order of 1ms for TodoMVC), we don't need the end user to explicitly specify data bindings. We've found that this is an easy way to build apps. Is this faster than angular? Benchmarks please!

peterhunt 13y ago
Angular's got a lot of great ideas, but the key difference is how you build with React. Angular's directives are pretty similar conceptually to React components, yes. But Angular requires you to imperatively manipulate the DOM in its linking functions, whereas with React you declaratively specify how you want your component to look and when it changes state the framework computes the fastest DOM manipulations for you, which we think saves you some work and is often more performant. If I had thorough benchmarks available I'd provide them, but sadly benchmarking things correctly is a lot of work and I just don't have time :/ You could try to play around with both frameworks' TodoMVC examples with Chrome's devtools to compare them, though.
- gregwebs 13y ago
  Angular douesn't require you to use linking functions. They aren't necessary for 90% of the time when you can just use a template and a controller. It would be interesting if you provided an example in React of something that did require a linking function in Angular.

shaydoc 13y ago

I use KnockoutJS, would there be anything in particular you feel React has going for it over knockout ?