Don’t Settle for Vanilla React
By: The Openshift Ninja
Tags: JavaScript, Reactjs, Design, Web Development, Software Development

Don’t Settle for Vanilla React

Image courtesy of Max Pixel

I’ve been writing React code now for almost two years as my full-time job, and one thing that I’ve learned in those two years is that there are better ways of doing things coming out almost every couple weeks. The worst thing you could possibly do as a React developer (or as any type of developer, really) is to just keep doing things the same way year after year.

When I started writing apps, I used class-based components and they were enormous. Every aspect of the page was encoded in logic in a single big component (each button was a component, but any code for the buttons was included inside the main component somewhere). This made refactoring incredibly difficult.

Fortunately I was working with a really talented engineer who, like me, was always looking for better ways to do things and had a lot of things he could teach me. Within a month or two, I was writing small functional components with hooks and using Redux actions to keep a lot of the business logic out of the components. We got to a point where we were feeling really comfortable with the codebase and could crank out new features fairly quickly.

We weren’t done improving though. As much as I like Redux, it still is complicated to add even just a single action and state variable. We also overused Redux for a lot of things that really didn’t need Redux, such as having simple payload actions that just set global state. While Redux can be used for global state, it is really intended more as a way to have your application respond to events.

I then discovered Recoil, another framework from Facebook that was similar to React Context, but better. The problem with React Context is that it is all managed near the top of your application, and a simple context update can cause a lot of your application to re-render unnecessarily, slowing your application down a lot. When you are building dashboards to manage the largest social network in the world, having slow updates is simply not acceptable. Recoil addresses this in a better way but is really simple to use — if you know how to use the useState hooks, then you know pretty much everything you need to know to use Recoil.

Even then, however, there are still places where you still want more than just simple global state. You have business logic that goes with that global state. That’s why a lot of people turn to Redux, but the setup for Redux is really complicated. I’ve started working with a framework called Overmind that incorporates similar concepts to Redux such as actions, but setting up the actions and associated state is much easier.

I’m not totally giving up on Redux, though. It goes back to the concept of events. If you want a bunch of different state updates to happen based on a single event, then Redux can really shine. Reducers can listen to any event in the stream of events, and so one event can cause a lot of other things to be triggered. If, on the other hand, you concentrate state into groups and events only cause state to be updated in one of those groups, Overmind is a better choice.

There is another thing that Overmind does that I really love, and that is building finite state machines. If you aren’t familiar with those, it is basically the idea that during the lifetime of a user session, the user is in only one of many states at any given time. Events move you from one state to another. For example, if you are shopping on Amazon, you start with an empty cart, then you have items in your cart, then you are checking out to purchase your items, and then your items have been purchased. You can’t be in more than one of those states at any time, and knowing which state you are in simplifies the kinds of things your application has to keep track of. I did a lot of state machine programming when I wrote C code because it is a really effective way of keeping logic simple.

I prefer typed languages, so JavaScript has always bothered me, and I wanted to move to TypeScript. Unfortunately, TypeScript is only half a solution. It suffers from a lot of issues that JavaScript suffers from, and in a lot of ways just ends up creating more work for you without really giving you that much benefit. Recently, however, I have learned about ReasonML, and my world has turned upside down. ReasonML is a typed language that is much easier and is highly regarded by the developers that have moved to it. I’m still learning it, but I finally have a good reason to move away from writing React in JavaScript.

The same goes for writing backend code in Java. I am still a huge advocate of Java, and I’ve built many enterprise applications processing millions of transactions a day using Java. The problem is that Java is a language that hasn’t really improved much since Oracle took over. Yes, the JVM has continued to improve, but the language you write code in has basically stagnated. A lot of programming tasks are just done better in other languages, and trying to just apply the same tool to every job is a bad idea.

I’m a believer that you should use whatever tool is best for the job, which is why I gave up on writing web interfaces in Java a long time ago. Kids these days will never understand the pain it was to write web applications using JSPs with Tiles or JSF. They were a pain to set up, were prone to bugs that were difficult to debug, and really were slow to develop. React, by comparison, is elegant, fast, and easy to learn.

So look at the stack you are currently using, and ask yourself one question: are you sure that every part of it is the best that you can do. I am willing to bet that for most of you, the answer is no. I’m pretty sure the stack I use isn’t the best, and I’m constantly on the lookout for ways to improve it. It does take time to find these better solutions and learn them, but when you find something that saves you hours of frustration and pain, it is usually worth the effort it took to find it.

Take advantage of every learning resource you can. A lot of companies now offer learning resources to their development teams, such as Safari, Pluralsight, Degreed, etc. You should dedicate at least 30 to 60 minutes a week to learning, if not more. Some of us pretty much have no choice but to learn depending on what the job requires, but if you haven’t learned a new language or framework every couple of months, you are falling behind in your career and you could be in danger of becoming obsolete at some point. Yes, there is still a need for COBOL programmers, but every day that need grows smaller.

Learning new skills isn’t just good for your career — it is also a lot of fun. Sometimes I just pick up something to learn just for the sake of it. Once I had a friend who was writing code for a company called ILOG (now a part of IBM) in a language called OPL that was specifically tailored for optimizing mathematical calculations in ways that would have been slower in a general purpose programming language. It wasn’t a skill I could necessarily apply to my day job, but it was fun to try and write things like calculating Fibonacci numbers in new and different ways.

Learning also just makes you a better developer. When you learn new languages and frameworks, you are exposed to the fact that a lot of the things that you thought were the right way to do something are in fact actually really bad. A lot of developers will spend hours writing code to do something when someone has already built a library or a framework that does it for you. The goal of every developer should really be to do the least amount of work possible, and you can’t do that unless you are aware of the better solutions.

The bottom line of this article is that although you may be loving your job writing React applications, but chances are that you are doing more work than you really need to. If you look around and try out some different things, chances are high that you will be able to shave some of the time required to build features and deliver solutions faster. Faster solutions often lead to happier business partners, and happy business partners often leads to promotions or other better opportunities. Don’t settle for vanilla React — keep searching for a better way.