Last updated at Mon, 06 Nov 2017 18:57:01 GMT

If you’re a JavaScript developer, and know a little bit about the current state of JS development, then you’re probably well aware that there seems to be a new JS framework popping up every day. It’s easy to feel overwhelmed with so many choices and that can make it difficult to actually choose the right tool for the job. This raises a question though, why do we have to settle on one tool?

In recent years there’s been one topic of debate that’s drawn a lot of attention: React vs Angular. Which one you should use, why you shouldn’t use one over the other, and why the other is evil and an abomination to Javascript. So back to our question, why settle on one, and not use both?

Personally I like both, I think they both have great benefits so why can’t I use both in the same application? There seems to be a misconception that React is a full framework that competes with Angular. However it is actually a UI library, and “just the V in MVC”. When you realize this, then it’s easier to think about how a front end framework (Angular) could make use of the benefits of some library (React) to provide an overall more efficient experience for the user. The main driver for combining the two is the ability to write reusable components which can be plugged into an application that leverages a sturdy framework.

Here at Logentries we use Angular as our MVC framework and are very happy with it. Angular allows for easy creation of services and directives which can build complicated applications. As stated above, React is not a full framework but it is more the V in MVC, with a sprinkle of C. In other words, it is the view, or in Angular terms it is a template, but it has the ability for the developer to add in controller logic to the components. However this is not actually needed to be a functional component.

While Angular has some obvious pros, the longer I use it the more I get irritated by the way it tackles templates. When it comes down to it my grievance with Angular is actually part of one of its strengths; too many watchers and too much 2 way binding. Angular gets unwieldy in how it causes you to structure your templates. You can end up writing a jumble of HTML which is overly complicated and difficult to read. Additionally, it leads to a knock on the effect of spaghetti CSS.

In small, well thought out places it can be great for fast binding and has good responsiveness. But if misused you can experience performance issues when binding too many elements in your HTML and your application will be become laggy and a nightmare to use. This is mainly due to the two-way binding that you are able to use out of the box, but it is also overused and abused in Angular applications. This becomes a big problem once you begin to loop using ng-repeat.

Here’s where React can shine and help out Angular. You can let it take care of all the templating. React uses an efficient diffing algorithm on the virtual DOM which allows it to only change the parts of the application that need to be updated. No more need to re calculate and render everything for small changes. Respectively, Angular evaluates all the watchers at each digest cycle and this can become an intensive process.

To get away from theory and provide a better overview, let’s create a very simple application to demonstrate some of what I mentioned above. We’ll go with a good old “Hello World”. This is just to show how easy it is to pass data from your Angular $scope, to your new React component. Nothing life changing but here we go:

The above example doesn’t have any JSX in it to keep it as simple as possible. All you need is React, React-DOM and Angular. It may not be very noticeable to see much difference between the two but if you run nested ng-repeats (burn it with fire) against the same structure in React you would see massive difference. Let’s look at a more complicated version.

While in Angular it would be something like this:

When you run the above separate apps you will see notice that the initial loading of the React version is noticeably faster at re-rendering content. Angular removes the whole tbody element, while React is just changing what is needed. Granted nested ng-repeats are a normally a terrible idea when performance is a concern, but it just shows that the greater number of nodes to re evaluate the slower it will become, while Reacts render will not suffer as badly. I’m not saying one is nothing without the other but I believe they compliment each other nicely.

You should play around with these together and see if you can improve your application.

Ready to start collect logs from your Angular + React applications? Create a free Logentries account in less than a minute.