React code is ugly. I’m not talking about any technical trait of the framework; I’m talking straightforward aesthetics, how the code looks on my screen, and the feelings it evokes.

Code aesthetic, in this sense, is not something developers are used to caring about. We have more important worries. Aesthetics are subjective, hard to measure and the benefits of chasing it are unclear. It is not often you’ll see a developer raising their hand and the midst of a Stand-up meeting to tell their peers they’re not pleased with how the code looks on their screen. And I’m not sure someone should, but I’m coming from a different perspective.

My considerations about React’s beauty started when working on a side-project. As most coders with coding as their profession and hobbies, the difference between work and leisure is defined by the amount of pleasure you take. Of course, we aim our careers at making both undistinguishable, and though sometimes they are, when they’re not, you still want at least your “coding for relaxation” hours to be as pleasant as possible.

Naturally, if, for some reason, React is unpleasant to me, and I want to spend time coding for pleasure, the obvious thing to do is not to use React. And I don’t, most of the time. But code, as we know, has a multifaceted perspective: you have code, the artifact, lines full of symbols you input to the computer, but you also have the result of your code, its output, the real-life implication of the ideas you expressed using a programming language. And I care, and I can derive equal or even greater pleasure from seeing my code interact with the real world.

The consequence is that sometimes, although I might find one programming language, or framework, or tool, unpleasant to see or use, it is the one I need to see my code taking the shape of something real in a reasonable time. Maybe this is due to some tooling, the big community creating things around it, or some other technical trait. Regardless of the reason, my coding-as-a-hobby time is scarce, and although I want it to be enjoyable, I also want to make the best of it, which means using things that do not always comply with my aesthetic standards. This is the case with React.

While reflecting on this topic one day, a question arose: Can I write React code that is aesthetically delightful while still keeping my productivity high? I know there are tremendously valuable answers to this question out there in the way of other programming languages and frameworks. All of those will have varying degrees of the same trade-offs, like how hard it is to learn, how much can I still benefit from the React ecosystem, how is the tooling around it, and so on. And all those trade-offs need to be measured differently depending on the project’s objective.

My answers to this question are more often than not something else that not React. But every once in a while, you compare every trade-off; you look at your project from different perspectives; you try to rethink the features you envisioned and the requirements you had; and still, at the end of the day, React will be your answer. With those cases in mind, I reframed the original question to: “how far can I go to make my React code more pleasing to view while still keeping it React code?”

“How far can I go to make my React code more pleasing to view while still keeping it React code?”

To start answering the question, I created a Create React App project with a simple React code as a reference. I wanted it to have at least a bit of real-lifeless but still be simple enough, so it wouldn’t get in the way of testing different things. I chose the official React tutorial code, which you can find here: Tic Tac Toe.