Don’t blame the framework: my experience with AngularJS and ReactJS
- It was also good to change a variable value and see it propagating to all parts of code via props (one of React components attributes), to break everything down to reusable components and to really stop and think before getting our hands dirty with code.
- In our team, there was an engineer dedicated to write HTML and CSS, and Angular enabled us to work together really seamlessly: he would worry about the HTML and a few extra tags, while I’d handle the logic.
- Most things that I complained about in the beginning were either because I was forcing the React way of doing things to Angular code or because I wasn’t experienced enough.
- Angular, on the other hand, focuses on the design simplicity of two-way data binding — what you change on the controller scope will (I’d say auto-magically) show up in the UI.
- However, the same way that with two-way data binding it’s simpler to develop, it’s also easier to create unexpected bugs when changing parts of code in the long run — especially that colleague’s code that hasn’t been touched in the past few months.
Here are the key impacts in the long run of choosing between AngularJS and ReactJS, from a seasoned developer’s perspective.
@arunkkumar2207j: Don’t blame the framework: my experience with AngularJS and ReactJS | Cheesecake Labs
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.
However, when an application grows considerably, a couple of issues 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.
1. The Dawn of React
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 – guess what? – Angular and React.
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.
We decided to give it a shot and start using React.
2. React + Flux = ♥
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.
Because of its one-way-data-flow nature, a child component needs to receive a callback to trigger a state change 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.
Despite this, we liked React and kept working with it. An effort that paid off: we met Flux, an architecture to enforce and formalize the unidirectional flow of data. It consists of four main elements:
With Flux, there’s no need to keep the state on a root component and pass update callbacks to its children. React components get data from the store directly and change the state by calling actions: it’s simple, elegant and prevents you from becoming insane. Flux adds a predictable behavior and some standards to the highly non-opinionated React code.
3. A wild Angular appears…
…It uses HTML-centric code and it’s NOT super effective.
Recently, I started working on an Angular project. A big part of it was already implemented, so there was no going back, I had to do it. As a loyal React developer, I complained about Angular. I literally cursed it — even if those were the first Angular lines of code I was professionally writing. After all, that’s the way it works: if you love React, you hate Angular.
And I can’t lie to myself, in the beginning I was not enjoying to work on Angular code. Embedding all those framework-specific attributes (or better, directives) to HTML didn’t feel right. I was struggling to get simple things done, like changing the URL without reloading the controller or do basic templating.
The struggle continued when I had problems in my forms because of ngIf directive creating a new child scope for it. Or when I wanted to remove blank fields from a JSON being sent to the server and it removed that data from the UI as well — oh I see, two-way data binding. Or when I wanted to use ngShow and ngHide to display an HTML block and hide another and, for that hundredth of a second, both are displayed simultaneously. I understand many of these issues were my fault –what I want to point out is that Angular is not predictable, it’s full of these surprises.
But of course, a lot of things were easier to do with Angular. The built-in HTTP requests module is really good, as well as the promises support. Another thing that I can’t complain at all: the built-in form controllers! Input fields have default routines for formatting, parsing and validating fields, as well as a good plugin to display error messages.
By using Angular it’s also easier to work with a design team. In our team, there was an engineer dedicated to write HTML and CSS, and Angular enabled us to work together really seamlessly: he would worry about the HTML and a few extra tags, while I’d handle the logic. If we were using React, it’d be at least more challenging for him to write components, since he’d have to learn the basics of JSX (or I’d have to copy and paste his work myself).
Remember the URL-replacing and templating issue that I mentioned before? Nevermind, found out that people normally use a different routing library (ui-router) that does a better work than the standard one (ngRoute). In the end, Angular was not as bad as I expected. Most things that I complained about in the beginning were either because I was forcing the React way of doing things to Angular code or because I wasn’t experienced enough.
4. Bottom line: AngularJS and ReactJS
Angular, on the other hand, focuses on the design simplicity of two-way data binding — what you change on the controller scope will (I’d say auto-magically) show up in the UI. Its opinionated nature saves setup time, by laying some patterns on how to organize the code and making it unnecessary to choose core modules from hundreds of options. However, the same way that with two-way data binding it’s simpler to develop, it’s also easier to create unexpected bugs when changing parts of code in the long run — especially that colleague’s code that hasn’t been touched in the past few months.
And then, what would I choose to build an app from scratch?
For the long term, I, personally, would choose React, using Redux architecture, Axios for promise-ready HTTP requests and react-router. But it also depends on the team experience: if there’s a dedicated person for writing HTML and CSS, I would go with Angular for sure. Both of them have pros and cons and what still counts the most for a maintainable project is the developers’ commitment to write good and organized code.
That’s a good point Seven Lee. If you don’t mind having big controllers (and big scopes) Angular does an excellent job, but data communication is indeed harder when you want to spread your logic into smaller components. I have to admit that Flux is an elegant solution and React contributors did a quite good job solving the performance issues right in the core, so you can pass as much data as you want to and thru a central state holder and never worry about the app starting a new render cycle. I’ve never tried to use a Flux approach with Angular, but I’m afraid it becomes a monster pretty fast.
For our team I reckon Angular would be a better fit for many of the reasons above, but as you say – ..’what still counts the most for a maintainable project is the developers’ commitment to write good and organized code.’ If I had to choose which one out of the two is going to win out overall in the end it has to be Angular based in the traction it already has. Similar to how Bootstrap is nowadays. For me the main benefit of using these frameworks in a team is that you are all sticking to the same conventions.
With Angular it’s certainly faster to develop in the short term, the whole store -> view -> action flow with React+Flux adds a bit of verbosity to the code. But that’s exactly where it benefits, since, as you say, the whole team is committed to the same conventions. Whereas Angular is more tolerant with workarounds and the load of doing the right thing lays more on the developer. But I think you are right, Angular still have more third-party modules available, since React really just gained a lot of popularity a year ago. It’s always a pros/cons battle.
I’m about to completely rewrite a solo project and for this I started learning Angular2. Everything seemed promising. I loved the idea of replacing all of my olf jQuery with two-way data binding (now optional in Angular2), but after a few weeks of my own little Angular boot camp I found material-ui.com (I have zero affiliation). Material-ui provides a set of material design based React components that would work perfectly for my project. I wasn’t able to find any material design Angular2 components that were as good, so now – simply so I can use these components – I’m learning React. I share this because it’s just one specific example of how choosing a framework with a large, established community can sometimes save you tons of time and effort. React is quite a bit more popular at the moment, and this unbiased developer is already liking it much much more than Angular2.
Thanks for sharing your experience Matt. I haven’t had the chance to try Angular 2 yet, just what I read on the internet, and don’t know about the support of Angular 1.x modules. Angular has a huge community, I’d say bigger than React’s for sure, but react is catching up and Material-UI project is really good quality. I’m glad that you’re open to use another framework if it fits your needs better. A framework (or library) community takes a lot of responsibility for its success, it really makes a difference if you find people motivated to help and share modules they’ve spent their time building.