Comparing Ember with React - A year long experiment

From Ember to React

Almost a year ago, when initiating a new internal project on the company that I currently work, the dev team decided to adopt React in favour of Ember. Though I was against it, I saw an opportunity to learn a new framework, and some new concepts. Back then, Ember was recently 2.0 and had lots of new goodness in it's new major release. Some parts of the core concepts on the 2.x versions roadmap was to adopt some of React's core concepts: component focused development; data down - actions up; one way binding; even a new rendering engine to compete with React's performance. So it only made sense for me to use this opportunity to learn the most I could out of React and it's concepts.

Ember !== React

Though lots of articles out there will try to convince you that one is better than the other because of some reason/concept/etc, it is not a fair comparison. Ember and React are two different species in the modern development wilderness. While Ember stands for a complete and opinionated framework, built to withstand the most ambitious applications and focused on productivity for teams of any size. React is built to be a view library, focused on to do one task, and to do it well: component based views. They are different in size, kind and focus.

Knowing this, it is possible to draw some comparison between some core concepts.

What have I learned with Ember

After spending over two years using Ember, I loved pretty much everything about it. Working with two different projects and two different teams using Ember as framework taught me the importance of a good set of rules and conventions that an opinionated framework like Ember provide. It is pretty much friction free the transition between projects. Though initially Ember can seem to be more intimidating at first, due to the number of things one has to learn before begin to develop, it is not all that overwhelming and difficult to pass the learning curve and start your happy coding days.

Also, Ember has a community that can only be described as epic and awesome. It is easy to find solutions to your problems, to grow your knowledge and keep informed. Ember has a well elaborated and open release roadmap, also the future of Ember is shaped with the help of the community, with it's RFC process.

What have I learned with React

When I dove into React's world it was a whole new learning process. The first thing I missed when moving to React was a good documentation. Though React's documentation is not all that bad, it is not even close to Ember guides or API documentation. So, instead of having it all on the official website, one has to hunt for a reliable source to learn.

Also, as mentioned earlier, React is only a view library. Which means that one has to 'build your own framework', and take all the decisions needed in that process. For small applications it is not such a big task, but this can become overwhelming as you scale your application.

I did not take this as a bad thing necessarily, it can be good if you wish to have granular control over your stack. And to me, it meant learning a whole new set of concepts, which is what I was looking for on this new dive. But you learn to appreciate how easy the development process becomes when the framework and it's community do this hard thinking for you. Though you also will hit a wall where the 'one size fits all' kind of approach fails some edge cases, as I have some times with Ember in the past.

I learned to appreciate the control over every aspect of my application. And to get some edge cases more well covered by a custom made solution, when a framework rule can get in your way.

I used my time with React to get back to Javascript's roots itself. Going as library/framework free as I could, and use all the power of the new ES5/6/7 APIs. It was a journey that made me more aware of the consequences of my decisions as a programmer, and in turn made me appreciate the simple and pure solutions to simple problems.

But it can also become overwhelming at times. Naturally when developing average to large size applications, there will be a lot of decisions around what React libraries to use. From a router, to Flux, Redux, Relay and everything else in between. In order, you end up having to manage and learn dozens of different libraries, it's integrations and interactions.

Another thing that is overlooked on React's side is an official CLI. Might not sound all that important to some, but having a CLI is a key piece for a fast workflow. The Ember team has done a great job putting together Ember CLI and with it it's add-on ecosystem.

The common ground

There are good and bad parts and aspects to all frameworks, and one have to evaluate and weight when choosing one for a project.

I try to bring the best concepts that I gathered when learning a new technology/framework/language to my day-to-day work. With Ember, I appreciate and agree with most of its guidelines. With React, I appreciate the purity and simplicity. In extension, having learned Redux, I appreciate the unidirectional flow for data and actions, and bulletproof state management with immutable objects and pure functions.

The road ahead

I am now fancying returning to an Ember driven development environment, at least for my personal projects. But I do think Ember has some bullet points to cross such as ES2015 modules and less obtrusive API, to allow more 'close to the language' programming, as one can do with classes on React, and I am happy to hear that Glimmer 2 will be able to be used standalone for simple applications.

In the end, there is no perfect framework. There's only a problem to be solved, and different solutions to it. Try to pick the one that fits you, and your team the best.