4 ms·

Apparently, you don't use this instead of another framework, but with (http://facebook.github.io/react/docs/common-questions.html http://facebook.github.io/reac

Apparently, you don't use this instead of another framework, but with (http://facebook.github.io/react/docs/common-questions.html http://facebook.github.io/react/docs/common-questions.html). To me, the closest existing thing to this would be Coffeescript as both need to be compiled into plain Javascript.

jonahx 13y ago
Okay, so I can use it with other libraries. But they haven't told me why I would. What problems, eg, is it solving that angular is not, or in a better way than angular does?
- peterhunt 13y ago
  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
- vjeux 13y ago
  Some things after I've been working with it for a few months 1) One of the great thing of React to me is the fact that we're writing everything in Javascript. With a very small syntax enhancer that is JSX you can write XML inside of the Javascript. The end result is that you don't need to learn a template language or many new concepts such as all the ng-repeat, or code inside of strings that angular has. If the framework doesn't support something, you can just implement it yourself. The React dom nodes are just regular javascript objects and you use regular arrays to manipulate them. It is also very convenient to be able to write XML in Javascript. You work with html trees all the time yet you can't easily make new ones in js. 2) Having a representation of the DOM in javascript is a huge enabler. Out of the box we can batch all the expensive DOM operations and only update the parts that actually changed. But it allows to do more crazy things. We can put all our application logic in a web worker or render the page server side. There are a lot of cool possibilities once you are in a React world. 3) One of the huge issue we face as js developer is traversing the dom to get a reference to whatever node we want. jQuery shine with that. React transforms the paradigm. Instead of finding dom nodes you are creating them. It leads to different ways of seeing the world. If you want to hide an element, instead of finding it and hiding it, you just don't create it in the first place.
  - jonahx 13y ago
    I'd like to see more info like this. Thanks.
  - bigethan 13y ago
    >render the page server side Curious about this one (coming from mobile web perspective crappy cpu, high latency). Render the page with node / serve html / React calls its render functions? / something else ? How does it bind to the already existing dom without building it? do all the render()s have to be called twice (once on server, once on client)? Any info would be appreciated.
    - peterhunt 13y ago
      Hey, I built this feature and was super stoked about it :) First of all, we haven't released the official server rendering stuff yet, since the API still needs to be cleaned up. But it's a total of 20 lines or so, so I'll likely post an example soon :) So React has a very low degree of coupling to the browser. Specifically it has two phases: 1. Generate the HTML markup, giving each DOM node a unique ID 2. Attach top-level event handlers. When an event fires we look at the target ID to figure out which component to bubble to (we have normalized, cross-browser bubbling and capturing built into our synthetic event system). In client-rendered apps we run both of these on the client. For server rendered apps, we initialize and only generate markup on the server and send it down. Then on the client we re-initialize, but notice that the markup is there so we just attach event handlers. This system enabled us to build a prototype a while back that ran React entirely in a web worker, but we haven't had time to productionize that yet.

jonahx 13y ago

Okay, so I can use it with other libraries. But they haven't told me why I would. What problems, eg, is it solving that angular is not, or in a better way than angular does?

peterhunt 13y ago
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
vjeux 13y ago
Some things after I've been working with it for a few months 1) One of the great thing of React to me is the fact that we're writing everything in Javascript. With a very small syntax enhancer that is JSX you can write XML inside of the Javascript. The end result is that you don't need to learn a template language or many new concepts such as all the ng-repeat, or code inside of strings that angular has. If the framework doesn't support something, you can just implement it yourself. The React dom nodes are just regular javascript objects and you use regular arrays to manipulate them. It is also very convenient to be able to write XML in Javascript. You work with html trees all the time yet you can't easily make new ones in js. 2) Having a representation of the DOM in javascript is a huge enabler. Out of the box we can batch all the expensive DOM operations and only update the parts that actually changed. But it allows to do more crazy things. We can put all our application logic in a web worker or render the page server side. There are a lot of cool possibilities once you are in a React world. 3) One of the huge issue we face as js developer is traversing the dom to get a reference to whatever node we want. jQuery shine with that. React transforms the paradigm. Instead of finding dom nodes you are creating them. It leads to different ways of seeing the world. If you want to hide an element, instead of finding it and hiding it, you just don't create it in the first place.
- jonahx 13y ago
  I'd like to see more info like this. Thanks.
- bigethan 13y ago
  >render the page server side Curious about this one (coming from mobile web perspective crappy cpu, high latency). Render the page with node / serve html / React calls its render functions? / something else ? How does it bind to the already existing dom without building it? do all the render()s have to be called twice (once on server, once on client)? Any info would be appreciated.
  - peterhunt 13y ago
    Hey, I built this feature and was super stoked about it :) First of all, we haven't released the official server rendering stuff yet, since the API still needs to be cleaned up. But it's a total of 20 lines or so, so I'll likely post an example soon :) So React has a very low degree of coupling to the browser. Specifically it has two phases: 1. Generate the HTML markup, giving each DOM node a unique ID 2. Attach top-level event handlers. When an event fires we look at the target ID to figure out which component to bubble to (we have normalized, cross-browser bubbling and capturing built into our synthetic event system). In client-rendered apps we run both of these on the client. For server rendered apps, we initialize and only generate markup on the server and send it down. Then on the client we re-initialize, but notice that the markup is there so we just attach event handlers. This system enabled us to build a prototype a while back that ran React entirely in a web worker, but we haven't had time to productionize that yet.