A brief review of the React.js framework, for those wondering whether to use it or not

At the moment, I’m developing a website from scratch for artists to upload commission portfolios and a bunch of other things, and as part of that, I looked into React.js as something to potentially help simplify building the front end. I thought it’d be a good idea to write a bit about what I learned, having done the tutorial and set it up to work correctly in a production environment.

You can find React here.

What exactly does React do?

An example from the React tutorial, of how rendering something in React looks.

As you can see, it allows you to directly write HTML in your React functions — which of course both looks very nice and is not valid JavaScript, but we’ll come to that a little later. There’s a very distinct list of pros and cons to React imo, but there’s one important claim on the React website I’d like to contest:

From React’s “getting started” section.

I think this is rather misleading. Technically, you *can* use very little React in your project and it’s not difficult to use it for testing, but the overhead necessary to make it work in production is almost inevitably not going to be worth it unless your project is complex. React is much more suited to heavy-duty, complex UI projects than any form of simple website, and I will explain why below.

Why is React mainly suited to heavy-duty projects?

1: Prerequisites

As you saw in the example class above, React is generally used with a syntax that is not valid JavaScript, allowing it to neatly use HTML within code. This is because most React developers use the optional JSX syntax which enables this functionality, and has to be compiled via Babel, a separate script which compiles the JSX-including React code into valid JavaScript.

If you’re just starting out, the React website points out that simply using a <script src> at the top of your page including the Babel preprocessor is fine. However, this is very slow in production, for reasons experienced developers should understand. Imagine every time you wanted to run an application on your computer, you had to compile it every time first; that would be awfully slow and inefficient. It makes a lot more sense to compile it once and then run it as many times as you want.

This means that in production, React.js needs several things to function properly:

  • Node.js and npx installed
  • Babel installed
  • NPX configured to watch your React source code directories, so it can preprocess/compile all React-including files into valid JavaScript

That isn’t always the easy process it sounds like, especially if you’re e.g. working with a pre-configured tech stack, and is a lot of extra effort if you’re only building something of a relatively simple nature.

2: Lack of benefit to non-complex UIs

With its functionality of being able to neatly render complex HTML elements, subclass them and so forth, React is a very helpful tool if you are building a complex UI with a great deal of features. For many simpler websites however, where subclassing UI components and the like isn’t necessary, React offers little that echoing content in PHP doesn’t achieve on its own.

It’s probably worth pointing out here that Node.js and React are both known to have better performance than PHP does. For large projects, this is another reason why they can be considered good choices, but for anything less than a complex UI or a site with immensely heavy traffic the difference is going to be negligible.

Conclusion

However, I wouldn’t bother with it if you have anything less than a complex UI to implement. It adds too much overhead and complexity to be worth it unless you will make extensive use of its features.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store