On January 3rd, 2016 Dan Abramov published a tweet saying:

“In 2016 I want more React users to build something with Angular, Ember, Cycle and vice versa. Let’s learn more from each other.”

I decided to write this blogpost to share my experience with React. But, before doing that I will describe my first experience with front-end development.

It went a little something like this:

Me vs the Angular docs

The first stand-alone front-end application I built was for a school project. It was built with Angular and my experience was not good… I crashed against the library. I found the documentation to be hard to follow and that made the learning experience a frustrating one. I ended up building the app, but it had no routes so it was basically useless. In Angular’s defence I was a noobie at the time and I don’t know how good or bad the docs are at the moment for Angular 2. After that bad experience I started looking at other options and that was when Ember came in to play.

My reaction to the Ember docs

Learning Ember has it’s challenges just like anything else, but compared to learning Angular it was much simpler. This doesn’t mean that Ember is easier than Angular or that Angular is harder that Ember, however this highlighted something that I really like about the Ember Community: the attention to documentation and guides is phenomenal. This makes the user on boarding smoother and from my point of view, learning Ember means learning the framework’s conventions. Ember adopts the convention over configuration philosophy. The framework provides routing with the Ember Router, a test runner, a test framework, a data persistence library with ember-data, an asynchronous code library in RSVP, a command line interface in ember-cli, a standard project structure in Pods and a rich add-ons ecosystem. As you can see, Ember gives you a lot out of the box. Understanding how everything works can be a challenge but once you do you’re extremely productive. Once you’re comfortable with Ember, starting a project or moving into one is easy because you know what to expect. I believe this is great from a productivity point of view, but I’ve learned that there’s a lot of value in making your own configuration and React indirectly exposes you to that.

Developing with React

React.js is a library not a framework. Obviously it doesn’t provide the things that Ember provides out of the box. The way I see it, Ember gives you a house when it comes to React you have to build your house. Technically speaking, you don’t need to build your house with React, you could only use the library, but that wasn’t my case. Coming from Ember, where basically everything is given to you, the process of learning what and how to use things can be difficult, especially in the configuration part. Due to this, I can understand why a lot of people that try to get into React or stay with React feel fatigued or lost at some point. Even if it’s frustrating, making your own configuration and learning what to use and where can provide a lot of value to you as a developer. Learning how to use Webpack and which loaders to use or learning how to setup a dev server or a test runner like Karma with a test framework like Mocha can only provide value to you as a developer. I believe that the knowledge I’ve acquired can help me for my future and it has made me appreciate all of the work that goes into Ember.

Creating your own configuration can feel like this:

But it’s worth it.

Learning how to work with React was a fairly simple process. In recent years React influenced many JavaScript frameworks, Ember was not the exception. Ember adopted a component first view, a very similar life-cycle, an actions up, data down system and others.

Making projects with React also exposed me to some level of functional programming through Redux and some parts of React. I’d also like to point out that both React and Redux have great documentation and I think this was essential to the learning process.

After learning and using Ember and React I can’t say that one is better than the other. I believe both present different approaches to solving the same problem. Also, I don’t think it’s fair to say that one is better than the other because they try to expose different philosophies. I think that instead of choosing sides as if this was a “war” we should appreciate the hard work that’s put into any Open Source Software that we use, learn from them and if we can contribute to it. At the end of the day the framework or library that we choose will be determined by the timeframe, problem at hand or… your boss. Great apps can be built with Ember.js and React.js. Both ecosystems are amazing.

PS. JSX is not that bad.