Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Hard for me to tell, since you seem to have devoted your entire comment to insulting the author without actually elaborating on why he's wrong.

Most of the article doesn't make any concrete arguments, so there's nothing to dispute. Most of the article boils down to "React is magical and better at Angular at everything", which...I dunno, where do you even start? The point about learning curves is just a bald "you can be an expert at React in a week; you have to read the Angular source to even use it!", which is just blatantly and obviously wrong. Or the abstraction point; apparently Angular is bad because you need to know about its internals to make anything work, but React is good because you just need to know about its internals to make everything work.

There's nothing really to engage with there. If you think React is super easy to master, and Angular is super hard, then you'll nod in agreement. If you don't think that—and I don't, for all that I love React and dislike Angular—there's nothing to dispute. No studies, no anecdotes, no surveys.

> this looks like a better way of letting HTML people focus on HTML while I focus on the JS

My experience has been that any designer technical enough to write HTML using Angular directives is technical enough to write JSX; the complexity difference is minimal.

But your mileage will vary; perhaps you—or the designers you work with—are fine with Angular directives but not JSX. Adoptions of tools like React-templates suggests this is not widespread, however. :)



I read the entire source of angular and enjoyed doing so. If I work with a react-based stack I'll probably do the same and enjoy that too.

But: My attempts to figure out a complete react stack resulted in me discovering that the react tutorial example is awful, then realising that's because the way I think demands a fluxish thing, then finding redux made sense but assumed I already knew flux, then discovering the billion other fluxish things and developing a headache.

So I clearly don't know what I'm talking about with react yet. If you have any suggestions for how to resolve the above headache I still want to try - hence my request for details, I wanted to understand why you liked React.


Well...

React is just a view layer; it's a way of turning data into DOM nodes. It works fine, and it's a pretty good way of doing so, although it's fairly weak for, say, making a bunch of basic CRUD forms, but very good for making little widgets. Bonus: It's very very composable. And you can make cool things—even those CRUD forms that otherwise seem daunting—by composing components and wrapping it up into a simple <Widget data={data} conf={conf}/> tag.

Strengths of React: declarative, kind of functional-ish, works well with immutable data. If you do it right, your React code is basically just a bunch of pure functions which accept data and turn it into DOM nodes; that makes it easy to reason about, easy to test, east to compose. If you ever look at your app and it looks wrong, troubleshooting it is easy. Put a console.log statement at the top of your render function to print out your props. If it's not run, your render function isn't being called. If it's run with the wrong arguments, a parent is passing in the wrong props. If it's being run with the right props but still looks wrong, you have an error in your render code, fix that.

Even a very, very complex React app boils down to the same reductive approach; start at the top of the tree and follow the data down until you hit the error. Debugging a complex Backbone app, in contrast, can be much more exciting in my experience.

But again, just a view layer. Comparing it to Angular is a bit like comparing Angular to Handlebars. :) You need a lot more to write a real app. Now you can try and hook it up to a Backbone router and Backbone models, but eww, don't do that. Or you can go the Om/Omniscient route with cursors and such. Or, yes, flux.

Flux is a really good pattern too. Redux is probably my choice for top two favourite flux implementations right now, but it's changing fast, still pretty beta, very poorly documented, and definitely aimed at people who already know flux.

I'd actually recommend you look at Marty or Alt. I think Alt might be slightly the better library, but Marty probably has the edge on documentation. Both are very similar and, as a bonus, are in the process of merging. Either would probably be a better choice than Redux if you're new to Flux in general. (I'm using Marty in a project at the moment, and found the documentation pretty helpful.)

I'd also recommend this blog post: http://www.toptal.com/react/navigating-the-react-ecosystem

The Reactiflux community on Slack is also really helpful.


Redux makes a lot of sense to me actually; I'll dig into it again when they've finished the great 1.0 renaming.

Thanks for the reply, much appreciated.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: