React: impression after Angular (p. 1)

Let’s talk about the situation with front-end today. Web pages eventually became more complex and robust. Pages are not longer younger brother that display forms and stuff; it’s real apps in the browser.

So it does mean that they will evolve and would need to be maintained with the help of tools. Developers would need enforce best practices in the code, have a clean way to write tests (in best case with TDD) and keep stuff decouple and interchangeable.

Luckily, we have quite advanced tools like React, Angular, Ember, Backbone and number of others. There was a trend when some of the tools, especially Angular were so popular so any front-end developer would start using them in the everyday job.

In the beginning is was fine, but then I counted pain points with Angular, and eventually switched to React. Now I got some impressions and thoughts that might be interesting for the community.

Impression #1

Redefined abstractions VS component based approach

Things are far easier with React.

React force people to think in components and well defines good View you can organise stuff as you want and pick Model and Controller in the way that you like. It might be Backbone models, or your would take a look how things could be done with Flux.

But with Angular I got some pain, and I’ll try to explain why. No, really. I talked with numerous developers, but only a few of them had a clue about what is going in inside Angular.

If you tried to pick each component from Model-View-Controller (MVC) in Angular, you would figure out that Controller is the only well-defined thing there. View is just a proxy to the controller, and you don’t have a full control on it, and Model is usually blurred in tons of services, factories and providers. Everyone is trying to redefine some basic things with Angular, and there is no guarantee that your developers will do it right.

Angular also redefined almost every single thing from native Js environment. Now we have some angualrish abstractions $window, $document, $location, which sometimes have awkward API and documentation saying that it is needed for the better testing.

By the way.

Impression #2

Documentation

Once you read it you can start hacking some code, and every single thing is well documented and you can refer to it. Googling or search on StackOverflow is just secondary sources of knowledge.

And then let’s take a look at Angular’s documentation!

I found that ridiculous. In case of Angular, I could not rely on official documentation, as it was (and it is) poor organised. Angular documentation has only some small parts of useful information that already require some level of maturity with the framework. As for me, it’s not that good for the framework ecosystem and makes me sad since Angular is the most popular front-end framework on the marked now.

Hi low quality products :(

Impression #3

Testing

It’s declared that Angular is designed to be easy to test. From the first sight it’s true: DI, testing tools, examples in documentation can help the developer to cover angular code with tests. But …

When I started to do unit and E2E testing with Angular, I found a lot of annoying problems. Let’s say, we want to test a directive with an isolated scope and make sure that some values passed to attribute where rendered to the DOM.

Here I would suppose that directive is nothing else but a function that can map state to UI layer and what I need is just pass prams in an isolated context.

Haha! NOT SO EASY!

To test directive I need: (syntax might be not precise) 1. Create new $scope with $rootScope.$new() and store it somewhere 2. Compile directive with $compile (service? ) (WAT?) 3. Trigger $digest loop to make some values in scope to be changed 4. Do your tests

I would say it’s not that easy for testing. So my impressions about React where just good as I could manipulate with components almost as with simple functions.

Here is good documentation about testing utils with React. My impression was superb about testing React components what I’m doing with my front-end projects.

Next impressions

I have some more observations to share; they are coming in part 2.

Got a question?

Feel free to ask me on Twitter or Github.

Originally published at www.devartem.info.