{"id":2776,"date":"2016-05-13T18:46:50","date_gmt":"2016-05-13T18:46:50","guid":{"rendered":"http:\/\/www.ckl.io\/?p=2776"},"modified":"2022-07-01T17:57:26","modified_gmt":"2022-07-01T17:57:26","slug":"dont-blame-the-framework-angularjs-and-reactjs","status":"publish","type":"post","link":"https:\/\/cheesecakelabs.com\/blog\/dont-blame-the-framework-angularjs-and-reactjs\/","title":{"rendered":"Don’t blame the framework: my experience with AngularJS and ReactJS"},"content":{"rendered":"

In the past few years, websites have evolved into complex web applications, and what once was land of simple business informative pages, now is home to Facebook, Slack, Spotify and Netflix, changing the way you communicate, listen to music or watch movies. Front-end development has reached a new level and now requires more attention than it used to.<\/span><\/p>\n

Just as for many front-end developers, our stack used to consist of HTML and jQuery. We would do AJAX requests to our backend, render the new chunk of UI on JavaScript and insert it into the DOM. User actions were tracked by binding events and callbacks to each of the elements. And don’t take me wrong: this is just fine for most applications.<\/span><\/p>\n

However, when an application grows considerably, a couple of issues<\/a> start being more frequent than expected: you forget to update all places where a value is displayed in the UI, no events are bound to the content added by AJAX, just to name some — this list can be very long. These are signs that your code is not maintainable, especially when developing together with a team. Using a front-end framework provides a formal way to write collaborative code that you can read, write and update.<\/span><\/p>\n

<\/p>\n

\"write_code\"<\/p>\n

1. The Dawn of React<\/h2>\n

When our team first felt the necessity of applying a front-end framework, we put some options on the table and it came down to \u2013 guess what? \u2013 Angular<\/a> and React<\/a>.<\/span><\/p>\n

Angular was by far the most mature candidate: it had a big community and you could find third-party modules for most of the common use cases.<\/span><\/p>\n

React was giving the first big steps, its JavaScript-centric code was promising and it was fast. Although still on beta, the “developed by Facebook” label backed it up.<\/span><\/p>\n

We decided to give it a shot and start using React.<\/span><\/p>\n

In the beginning, it was really satisfying to do everything using JavaScript: display a chunk of HTML or not, render lists by iterating over an actual array. It was also good to change a variable value and see it propagating to all parts of code via props<\/a> (one of React components attributes), to break everything down to reusable components<\/a> and to really stop and think<\/a> before getting our hands dirty with code. It gave us the consistency we needed to develop maintainable code as a team.<\/span><\/p>\n

\"teamwork_1\"<\/p>\n

2. React + Flux = \u2665<\/h2>\n

But down the road, not everything is unicorns and rainbows. The first big challenge we faced — and the one that really put us to think if using React was worth it — was a callbacks maze.<\/span><\/p>\n

Because of its one-way-data-flow nature, a child component needs to receive a callback to trigger a state change<\/a> on the parent component. It doesn’t seem a big deal until you realize that your child component that is way down the cascade, now needs to update the state of the root component. You have to go over all files and pass the “this.props.updateCallback” down the stream line.<\/span><\/p>\n

Despite this, we liked React and kept working with it. An effort that paid off: we met Flux<\/a>, an architecture to enforce and formalize the unidirectional flow of data. It consists of four main elements<\/a>:<\/span><\/p>\n