React to this nonsense and move on
Why you should go for React.js, instead of Angular 2.0
(Sorry, bad pun intended)
“Drastically different” — That’s what Angular 2.0 is supposed to be. Deep inside you know that Angular is neither what you want nor need for your next project. Otherwise a radically new version of Angular wouldn’t make any sense.
Even the developers of Angular realised, that something’s wrong with it. That something won’t be eradicated by “drastically” restructuring the framework though. In my opinion, it’s a philosophy as well as an elegance issue.
What do the Angular JS developers want to fix with their 2.0 release?
- Learning Curve
- Performance issues
- Data Binding
Even if all those problems disappear — which is highly unlikely — there’s a problem with the fundamental philosophy and structure of Angular JS, which will keep it from advancing any further than what it is today.
React is clearly superior in terms of performance. Angular 2.0 and the next version of Ember strive to beat React in terms of performance.
What is React’s advantage here? React is using a Virtual DOM to rebuild the content when the state of the application changes. Then it updates the actual DOM with the changes.
The DOM is slow, the virtual DOM is fast, thus everything speeds up. Simple —
How does Angular render its data bindings? I honestly don’t know the details of this process. And if I found it, or read through the code, will it be as simple and lightweight as React? Probably not — Thus Angular 2.0 was born.
Still we could live with performance issues. And when you work around some problems in Angular and Ember it is still feasible to work with it. The real issues with Angular, as I was saying, lie deeper.
Two-way Data Binding. Does that sound awkward? Because it is. The view inherits values from a model, or “scope” in Angular. This scope is either controller-specific or app-specific. The app-specific scope is called root scope and can be accessed from anywhere.
Scopes hold most of your data, that transcends to the view. It models your view. The digest process of these data changes is not trivial. And staying sane, while data affetcs data, affects data, affects data (and so on) is difficult. Many fear an infinite digest loop. The absolute nightmare of every Angular coder.
How could these even happen? We reacted to changes in a model, that could’ve been actuated from various sources, for example: A change in another model. This causes cascades of digests and sometimes even a loop.
The Angular 1.x’s data bindings are awkward and made our lives miserable. Why do we need controllers and views so separate? Does that make any sense? Just when there’s no alternative, really.
We know where our data needs to go, but we pretend that we don’t. We explicitly give up control over our data bindings (ironic, isn’t it), so we don’t have to handle updates and data changes. But thise introduces a new problem. Now we don’t know where our digests go, instead of when our values update. It made things easier (like many great libraries), but introduced horrible new problems.
Angular made very strict and opinionated rules to what code goes where. Rules to make the structure clean and failures unlikely. Rules to make this data bindings feasible. When you wan to use Angular without encountering data binding issues, you just had to comply: Controllers here, services there — “Why is that code in the view?”
Why did we accept these issues?
Angular opened a new world. It made web development more like app development. And it felt totally right. Models, Views, Controllers. The keyword is: Familiarity —
Representation of values in the view through models meant, that we no longer have to care about what is happening at any given time. It completely decoupled the logic from the view through controllers. App development ultimately enabled new advancements in the web. Finally we could be happy, but at what price?
Angular forced a structure on us, that just didn’t make things easier.
Angular encourages bad habits
Angular is opinionated, like most modern JS web frameworks. But it forces an inelegant structure onto our apps.
Angular encourages spaghetti code. To glue your decoupled code together you suddenly need hundreds of lines to adapt, often the same code at multiple locations. For example:
Often you need filters inside the view to make the data in your scope adapt, you need special code in your controller to handle the data in your scope, you need root scope variables in your services to handle changes and actuate changes, etc.
Is that optimal data binding? Are the possibilities of JS really used optimally here?
What if I told you that we could have all the advantages of Angular without giving up its advantages?
React.js to the rescue!
Advancing from 2012's Angular to 2015's React.js
Components instead of nonsense
Often titled the V in MVC, React mimics the structure of web components to bring a traditional and familiar structure to your apps. Like directives in Angular, but we’ll use them for everything.
It ditches controllers and views for components. Code that contains both the view and logic to display data. React’s structure is very easy to grasp.
You’ve got data? Great! Insert it into your components as properties, immutable attributes of your components. Attributes like the src for an image tag.
Internally you’ve got a state, that you can mutate depending on what data you want to reuse in your render routine.
The render routine is called every time your component — well — renders.
That’s how you explain React in a few seconds.
The data binding issue is solved via Flux in React. Flux is an architecture for React, that encourages the unidirectional nature of your components.
Data experiences a unidirectional flow in your React+Flux applications. Components render your data, thus they only accept data, they never mutate it.
Flux implements data stores and a dispatcher. When you’d like to insert new data into your application, you start an action. This action dispatches a data package. The dispatcher itself, then sorts your data into the correct data store.
When a store updates it triggers an event, that notifies your components to update their data and rerender. Updates are finally easy!
There’s always this one directive in Angular that solves many of your problems. It starts with “ng-” and does something magical. When you want to implement your own directive it becomes its own magical attribute or component.
There are hundreds of ways to solve a problem with Angular. Some are an anti-pattern, some are just too complex for a simple problem, some are just stupid and so on. So you are left to try out a few different ways to solve your problem and sometime end up in dead ends.
Your team mates are confronted with similar problems and sometimes they take another way, solve the problem differently. Suddenly code isn’t reusable anymore and the structure of your app isn’t optimal and elegant.
You didn’t follow the KISS principle. Oops!
But it wasn’t your fault at all! Angular doesn’t follow the KISS principle either. In some cases Angular forces an irrational pattern onto you and in other cases it’s just too rich.
React and Flux on the other hand provide a rational pattern, that is easy to follow. React’s philosophy is clearly the KISS principle.
There are less ways to do it. And often your code stays reusable. Hooray! —
Easy to grasp, Easy to adopt
You could learn about React+Flux in one afternoon. Its structure is easy and rational. There is not yet another function, that could make your life easier, as in Angular. Stop using Angular! Minimalism always wins over feature burdens.
Use Flux for your data, React for your views, Browserify to bind everything together? React is much more unopinionated than Angular about your stack.
Start learning React today!
Some links that will help you to start a relationship with React+Flux as soon as possible:
Follow me on Twitter to get all my updates and content: @PhilPlckthun
I’d like to know whether what I think and write made a difference, so please “Recommend” this article to your friends and leave a comment, if you like what you read.