Hacker News Reader

Comment by peterhunt | Hacker News Reader

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 (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

What do you think?

View on HN

Hi guys! Great job! I haven't had a chance to take a thorough look, but I want to clarify that with AngularJS, you could simply do something like

   <li ng-repeat="item in items" 
       ng-style="{'background-color': $index % 2 == 0 ? 'yellow' : 'green }">
   </li>

without creating a directive. Incidentally, I decided to rewrite the React tutorial in AngularJS, and I appreciate any feedback.

https://news.ycombinator.com/item?id=5790799

Your render code isn't easier than writing a directive. The directive would be reusable too, I'm not seeing the wins.

The React way would be reusable as well. The actual code is being passed as an anonymous function which could be extracted out and named.

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.

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"?

For Instagram we have higher level components that do data fetching via a JSON GET request. When the request comes back we store the response in state, and then we pass that state down to child components. We also pass callbacks down to those child components, so that when they want to perform a write to the server, the higher level component can do that.

We move the actual server request and response logic out of the component, of course, so it's just a one-liner within that component.

Instagram got really far with that, but there are parts of Instagram (converted from an earlier Backbone version) that have the child components directly update Backbone models which then handle the server requests. The on change Backbone events then trigger setState() calls on our UI.

At Facebook we have an in-house dataflow architecture that updates our components.

So it really depends on how you want to do it. But we don't provide a "React.Data" or "React.Router" or anything like that. This is by design, since we can't possibly account for everyone's specific use case.

I like the idea of being able to use my own raw domain objects as the model, which in angular you are supposed to wrap up as a service as i understand it -- a bit of boilerplate i don't love. I'll definitely keep my eye on this project, it sounds like it has a nice architecture.

My last piece of advice is docs, docs, docs. Making a framework easy to learn by example is the key to adoption imo. That was one of the chief complaints you heard about ember, though I think they've started to fix that. It's boring work and hard to make good docs, but it's so so important.

Thanks for taking the time to follow this conversation through :) We've spent a lot of time getting the docs to where they are today, but there's always more to do. We have more planned but think we got a pretty good point for our initial public release.

When we've showed the site internally at FB & Instagram we got a lot of the same feedback you're giving now, that we need more examples. We have some more in the repo and more we'd like to write. Coming soon!

> I like the idea of being able to use my own raw domain objects as the model, which in angular you are supposed to wrap up as a service as i understand it -- a bit of boilerplate i don't love.

This is only a cultural thing. Angular is, at its root, a dependency injection framework. The upside of doing thinngs the angular way is that you can wire things together differently down the line (and you can actually get a lot of code reuse if you write 1-2 function services) with the downside being the boilerplate wrappers.

I don't see a live editor on the React homepage!

Reply on news.ycombinator.com