I don't think I have a strong opinion about Ember, though you can take the React rendering model away from me when you pry it out of my cold dead hands. But I think I object a little bit to the way they complexify the React stack:
* ES6
* React
* redux and redux-saga
* react-router
* fetch
* lodash
* webpack
* post-css
* karma/mocha/sinon/chai
Of all of these things, to build a decent React app, you only need React.
It seems chintzy to bill React for the cost of webpack/browserify. I understand why someone would: it's the worst part about working in modern Javascript environments. But it's a build tool, not a library.
You Don't Need Redux. Most applications that use redux (or any other Flux library) probably shouldn't. Even redux's author has been taking pains to point out how overused redux is.
You definitely don't need react-router, which is an inner-platform disaster.
Billing React for fetch and lodash also feels chintzy (especially when you try to add a surcharge for switching from underscore to lodash).
I'm also not clear on how ES6 is somehow React's problem. Ember developers use ES6 too. Because ES6 is better than ES5.
I'm not saying the Clef team is wrong. If they're happy with Ember, God bless them! I'm just wary of tech advocacy articles that try to make these kinds of stack complexity comparison arguments; I usually find them to be pretty dubious.
I think this is a fair criticism and I agree that I might have used this comparison in a simplified way to make my point, but I think the primary thesis still holds: when building a React app, you necessarily need to make a very large number of choices that you don't need to make when building Ember.
This isn't because React is bad, it's because React is just the view layer! If we look at it this way, we can re-examine that list as:
* language
* view
* data modeling
* routing
* network connections
* functional utilities
* build
* styling
* testing
And, with React, when you have just a view layer, if you want to build an advanced application, you likely need to add on a bunch of other layers to get everything working. I hear you about being able to "just use React", but I also think that's a an oversimplification the other way: how many applications on the web today are built with only the view layer and none of the others?
After evaluating all the decisions we made in the past when building a React app, we decide to trust someone else to make them for us :)
p.s. the original title was "Choosing Ember of the React ecosystem in 2016" but I ended up shortening it :)
Ok, and fair enough, but a simple question as a response: am I required to buy into the idea that I need a library to cover all of these cases?
Any attribute of constructing an application you break out, people will build libraries for. But are they necessary? In some of the cases we're talking about --- routing and network connections, for instance --- the answer seems to be a clear "no".
I've been using Redux for the first time lately. It may be conceptually elegant but in practice it's really a mess. In order to do any real work with it you have to pull in something like redux-thunk and then all your fancy state management tricks go out the window. I would go so far as to say I consider it an anti pattern outside of some very specific use cases.
I intend to try Mobx sometime soon but I've also found you can go very far using stateful vanilla React components and no third party state libraries at all.
Right there with you on this, love react's rendering model. Redux seems to get all the hype but I'm sort of beginning to suspect it might be mostly the wrong way to do things. It reminds me of TDD, most of the benefits seem to be moral in character rather than concrete.
* ES6
* React
* redux and redux-saga
* react-router
* fetch
* lodash
* webpack
* post-css
* karma/mocha/sinon/chai
Of all of these things, to build a decent React app, you only need React.
It seems chintzy to bill React for the cost of webpack/browserify. I understand why someone would: it's the worst part about working in modern Javascript environments. But it's a build tool, not a library.
You Don't Need Redux. Most applications that use redux (or any other Flux library) probably shouldn't. Even redux's author has been taking pains to point out how overused redux is.
You definitely don't need react-router, which is an inner-platform disaster.
Billing React for fetch and lodash also feels chintzy (especially when you try to add a surcharge for switching from underscore to lodash).
I'm also not clear on how ES6 is somehow React's problem. Ember developers use ES6 too. Because ES6 is better than ES5.
I'm not saying the Clef team is wrong. If they're happy with Ember, God bless them! I'm just wary of tech advocacy articles that try to make these kinds of stack complexity comparison arguments; I usually find them to be pretty dubious.