By Scott Miller, Senior Software Engineer, Pulsion Technology

At Pulsion, we’ve recently been discussing standardising what JavaScript front-end framework we should use across all future web development projects.

However with the wealth of choices of JavaScript UI frameworks out there, this is far from a trivial decision. We decided to focus on the 2 largest players in the market – Angular and React. This 3-part blog series considers both frameworks, our investigation and conclusions. In part I we considered Angular – this blog post will take a look at React.

React is the other current big player when talking about JavaScript frameworks. Although on paper it seems newer than Angular (having only been around since 2013, rather than Angular which has been around since 2009), when you factor in that Angular 2+ is essentially entirely different to Angular 1, then you realise that Angular 2+ has only been around since 2016. Which makes React much more of a mature platform. It’s made by Facebook, and has been battle tested by Facebook in their own live environments since 2011.

React code is a bit of a culture shock for someone (such as myself) who’s never seen it before and is more used to an MVC approach (having worked heavily with Angular 1 and ASP.NET MVC in recent times). The reason for this is that React doesn’t separate HTML mark up from JavaScript (unlike Angular), and instead combines HTML and JavaScript together. While proponents of MVC (such as I was) may cry that this isn’t separating concerns adequately, I eventually realised the truth is that there *is* a good separation of concerns in React, it just has a different focus: the separation of concerns being component based. And from that point of view, it works. So all the individual parts of a webpage are broken down into small components, and all the mark up and functionality for each component is grouped together into a single React file.

A big advantage with React is that it is really easy to get going with it, the learning curve is pretty low. Part of the reason for that is that React is just a front-end JavaScript library, rather than a fully-fledged framework the way Angular is: so it’s more lightweight. This does mean that you need to use other complementary components alongside React: for example, a routing component and an implementation of Flux (which is the design pattern used for data flow in React applications). Arguably, this gives more flexibility in deciding what components to use for developing your web application: you aren’t just tied to the components that come with a fully-fledged framework such as Angular.

React has markedly better performance than Angular 2+. Part of this is down to the fact that React is so lightweight, and partly down to the fact that React uses a virtual DOM to minimise the amount of information that it needs to update in the browser with every webpage refresh.

One of the things that disappointed me most when looking into React was the lack of definitive coding standards, the way can be found in Angular (for example, John Papa’s excellent Angular style guides). But then again, React is still a developing framework, with new features and changes being made regularly, so perhaps a definitive set of coding standards for React is still to come.

In part III of this blog series, we’ll briefly discuss the other options available, and then offer our conclusions. Meantime, please feel free to leave a comment, or if you have any questions on this or any other software development topic, then please don’t hesitate to contact us on info@pulsion.co.uk or 0141 352 2280.

Pin It on Pinterest