TL;DR: The author thinks that React is amazing at everything, but detests JSX. Conversely, he hates Angular but loves Angular's directives. So he hacked together some code that lets him use Angular directives with React, which he thinks is great and everyone else in the world detests.
If you are one of the handful of people who love React, hate JSX, love Angula's directives, but hate Angular...then you will find this article very agreeable. Everyone else will react with a mixture of laughter and confusion.
Sadly, the actual writing and argumentation is poor; if you don't already agree with the author's rather unique point of view, this article certainly won't convince you. It's basically just a puff piece so he can link to his directives-in-React library; eg, important debates about two-way versus one-way binding are dismissed with a quick "React has a mixin for that", which rather misses the point. (Of course, to really discuss this, you'd need to mention Flux, which is studiously ignores, probably because it would distract from his obsession with templates.)
In short: I don't think the author understands React, and I doubt they understand Angular either.
> The author thinks that React is amazing at everything, but detests JSX. Conversely, he hates Angular but loves Angular's directives.
The hilarious part about this statement is that React is the equivalent of the Directive component in Angular...so if you like Angular Directives, there's basically no reason to use React. I'm seriously wondering why this post got so many upvotes.
I'm stuck on an older version of angular, but have directives become more composable in the last couple of versions? I had real problems composing them as element directives, which is the only way i'd be able to swallow the equivalence argument.
Which is funny because Google is also sponsoring Web Components (via Polymer), so I wouldn't be surprised if Angular is one grand experiment to see if the world will adopt data-bound web components as the next step in the evolution of the web.
Sorry can you elaborate? How have they become more composable? I don't recall a point at least post 1.X where they were more or less useful for composition than they are now.
Sure, there are a lot of subtle things which have been improved in later Angular versions.
First of all, you don't need $scope anymore in controllers, you can still use it for functions like $watch, but you don't need to inject it in just to add properties to your controller, you can just use `this.foo = 'bar';`
You also have the controllerAs syntax which I don't think is present in earlier Angular versions, which provides a shorthand for your controller, and bindToController for directives, which allows you to bind attribute values directly to the directives controller without extra syntax.
If I remember other things I will update this comment.
> Sadly, the actual writing and argumentation is poor
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.
From my POV, this looks like a better way of letting HTML people focus on HTML while I focus on the JS - which is something that's been valuable in angular for me.
Any chance you could explain why you believe that's wrong rather than just trying to invent teabagging over IP?
You have HTML people? This raises a question I've had for a while about the "full stack" term. I come from the asp.net world, where I have never dealt with the concept of "full stack", simply because there has never been an alternative. From day one in the 90s I've been expected to do everything from html to sql. Is "full stack" primarily a non-Microsoft matter? If not, what proportion of Ms devs have HTML people, js people, etc. vs "full stack"?
Well ... I usually bang out HTML3-like markup that matches the initial wireframes, then hand it to somebody who's good at CSS to make it look decent. I also do a fair chunk of refactoring JS stuff that was thrown together to test a UI idea into something that's actually maintainable.
Plus on the rare occasions I try and do something involving prettiness, being able to ignore the JS and focus on HTML+CSS is nice for me, too.
> 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.
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 would disagree. I don't think the "level of conversion" presented in the article is anything to praise. There are very few real arguments presented that are worth discussion.
If you are one of the handful of people who love React, hate JSX, love Angula's directives, but hate Angular...then you will find this article very agreeable. Everyone else will react with a mixture of laughter and confusion.
Sadly, the actual writing and argumentation is poor; if you don't already agree with the author's rather unique point of view, this article certainly won't convince you. It's basically just a puff piece so he can link to his directives-in-React library; eg, important debates about two-way versus one-way binding are dismissed with a quick "React has a mixin for that", which rather misses the point. (Of course, to really discuss this, you'd need to mention Flux, which is studiously ignores, probably because it would distract from his obsession with templates.)
In short: I don't think the author understands React, and I doubt they understand Angular either.