The team I'm apart of started a project 2 months ago. We chose React and Redux over Ember, Angular, et al. A main decision factor was that we needed the server to render our initial HTML, neither Angular nor Ember can achieve this easily, we'd most likely have to lean on a third-party service. Angular looked particularly unattractive with Angular 1 being as good as dead and we didn't feel confident starting with Angular 2, there we're simply too many unknowns. We loved the hot loading & the redux-devtools features, turns out these have given us a decent productivity boost.
2 months into the project I'm confident we chose the best tools for the job, there's been absolutely no regrets from the team members.
The problem is that the surface of Angular is incredibly complex.
With React, you have components, which are just things (classes or functions) that convert a set of properties to a subtree of more components (ideally mostly ones that directly represent DOM elements) and do so deterministically and reproducibly.
With Redux you just have objects ("actions") representing changes to your application state and functions ("reducers") that convert an action and the current state into the future state. There are also functions ("action creators") that help you create the former and functions ("middleware") that affect how Redux processes them.
With Angular1 you have templates and directives and components and models and scopes and controllers and filters and injectors and services. And services can be constructors or factories or providers or values or constants or decorators. And scopes can be isolate or nested and there is the digest cycle and there are watch functions and if you do anything async outside of Angular you need to make sure to trigger the digest cycle (but not if you're already in the digest cycle) and I haven't even talked about interpolation yet.
Angular2 is slightly better but the docs are pretty sparse and many people's brains will still shut off as soon as they hear "dependency injection" and have you fucking seen what they have done to HTML to maintain their false illusion of "it's just HTML and JavaScript, designers can understand this"?
React doesn't need you to think. Initially the API made you define components by using a magical function, then they extended it to allow just using ES2015 classes, now you can even define simple components as plain old functions. The surface has shifted from minimal to nearly non-existent.
Redux has more conceptual overhead than React ("Wait, reducers can't have side-effects? Where does my AJAX go?") but most of the learning time is spent un-learning concepts you take for granted (e.g. you shouldn't mutate state, your components should ideally not have any state at all and it's perfectly fine to normalize your state because you only need to derive it when it actually changes). The number of actual concepts Redux brings to the table is fairly low.
Angular is a battleship. React+Redux is an attack submarine.
> Angular is a battleship. React+Redux is an attack submarine.
> The value of the battleship has been questioned, even during the period of their prominence.... battleships were increasingly vulnerable to much smaller, cheaper weapons...[11] https://en.wikipedia.org/wiki/Battleship
I'm not sure if your metaphor was intentional, that Angular is like a flashy, seemingly powerful but ultimately archaic, dead-on-arrival platform, but I appreciate it nonetheless.
I found it useful to actually read the Redux docs page-by-page (at least the introduction and basics) but it also links to some tutorials.
I actually had to read the basics and advanced sections several times before it fully clicked. It helps if you don't expect Redux to be super complex -- like React it does just one thing: manage your state by responding to actions. If React is the V in your MVC, Redux is the M.
This is a very noob question. I started with React. Its just great. While I was working on the "component" thinking, I just thought react does provides "states" concept in which we can store the component's state. Which is ( for me ) looks like React does provides the model too (what I'm thinking right now is setState as a model and render as view of React lib). Probably my thought process is wrong over here. Am I wrong here?
But if one can store the component state in React setState, why one should look for "Redux" or any Flux libs?
Ember has a solution for server-rendered HTML, called 'Fast Boot'. It can be used both for speedup (quite obvious, given the name) and for e.g. SEO-purposes (though I think Google is pretty good at crawling JS these days).
It's still at a very early stage though (alpha), but I think it has great promise. More details in the recent 2.3 beta changelog:
(Not saying you made the wrong choice, it sounds very reasonable -- Ember's solution isn't ready for use just yet. But thought I'd note this here in case others have the same thought)
We did take a look at Fast Boot and if I remember correctly it came with a big caveat that it's only suitable for the most brave. If Fast Boot were stable then Ember would have been a real strong contender.
I'm really excited at the rate of pace of change on the front-ends. My last project was in Backbone and React & Redux feel a gigantic leap forward. I'd love to experiment with Elm and Cycle.
yep, i'm also working on a react/redux project (where i'm only js senior and rest of the team are rails devs with only basic js skills) and big advantage is, how easily and quickly they became productive. We have other project in Ember, where logic was to take advantage of similar concepts & conventions as in rails, but in reality it's incomparable.
But what about angular being a framework and react being a library? Ido hate to invest time in react only to find out that when working on some project it doesn't provide all I need. By project I mean some backend api and front end SPA
React is less full-featured than Angular is less full-featured than ExtJS and so on.
You're not going to use a single tool to build your project. You're almost guaranteed to using different tools to build your frontend and backend (even if some of the tools may be the same or some of the code may be shared). You're extremely likely to use more than one tool for either of them.
Nothing will "provide all [you] need". If it did, it wouldn't be a library or framework, it would already be the finished product you're trying to build.
React does one specific thing and it does it incredibly well. If that thing is what you need: great, you can use React as one of the tools to build your product. If it's not what you need: don't use it. You shouldn't worry about whether something provides everything you need, you should worry about whether what it provides is actually what you need or not.
Angular does a lot more things than React does. Logically that means it's less likely to be a perfect fit for your project. You're more likely to find out that it does something in a way that doesn't work for you, simply because there are more things it does. But it may also do enough things in just the way you need them to be done to be worth the few places where it doesn't fit your project perfectly.
It's always a compromise. Unless you have unlimited time and can develop the perfect tools yourself, you're going to have to make a few sacrifices along the way.
If it doesn't provide all you need then it's easy to involve other non-React code to make it all work. That's what's so great about it being a library - you're free to implement whatever pattern you'd like around it. For me, that's Flux/Redux (I use actions to call to well defined services) but it really doesn't matter.
I think there's a list somewhere of patterns that are difficult / non-ideal for React but I don't have it in front of me. For 99% of use cases React really isn't going to be a detrimental choice as long as you choose a good pattern to surround it with.
