Thinking in React Part 1: Some love for JSX

Each framework makes it easy to solve certain problems, while others remain outside its reach. React is no exception. React works best when we understand the problems that it is designed to solve. This means figuring out the boundaries and limitations of the framework and designing our solution in such a way that it causes minimum cognitive dissonance. In this series I will explain how I interpret the features of React framework and will try to make React intuitive for everyone. In doing so, this series will stay away from discussing the merits and demerits of React over other front-end frameworks.

The first thing that puts off developers especially those coming from other frameworks is JSX. Now, JSX or JavaScript + XML is React’s preferred way of defining UI elements. Mixing HTML and JavaScript together set off a lot of alarm bells for developers. They have religiously practiced separation of concerns, believing that presentation and rendering logic should stay apart.

There are many seasoned developers who are not convinced about JSX. For them, I would say that consider JSX to be a Domain Specific Language (DSL) build on top of JavaScript. JSX is not about putting HTML inside JavaScript and violating separation of concerns. It is an abstraction to make it easier to conceptualize User Interface as being made up of several independent co-existing pieces that work in tandem. The goal of JSX DSL is to break down UI into small reusable pieces that can be used to compose large complex interactions. Ultimately, the point I am trying to make is that JSX makes it easier to talk about modern reactive UI.

Let’s settle this argument once and for all. Every statement in React evaluates to JavaScript. The XML-like syntax simply transpiles to JavaScript function call. Every bit of React code that we write is added to the tail of a empty HTML tag inside the body element. Hence, the entire React DOM tree lives inside an initially empty container. Think of this process as a more elegant way of creating child nodes with document.createElement function and attaching them to parent nodes with appendChild function.

There are two categories of JSX elements — native HTML tags and user created React components. Native HTML tags are named with lowercase letters whereas names of React components start with a uppercase letter. This distinction is made to facilitate React’s internal processing of native HTML tags. React maintains a whitelist of all valid HTML tags and checks the validity of JSX element being native HTML tag if its name is in lowercase. Otherwise it treats the JSX as a React component.

A React component is syntactic sugar for React.createElement function. This function takes one mandatory argument, the type of React element to create — either HTML tag name or React component type. Additionally, it can two optional arguments — the props object and child components. This should dispel a doubt inside developers mind that we are merging HTML and JavaScript. We are simply writing JavaScript code that creates HTML nodes and attaches them at appropriate place.

In order to prove that JSX is a blessing for front-end developers, here’s an exercise. Create a three level deep HTML structure with three different methods:

1. Vanilla JavaScript — using createElement, createTextNode and appendChild methods
2. React without JSX — using repeated calls to React.createElement method
3. React with JSX

To develop 1st and 2nd solutions, you would need to first create a mock-up of how the final HTML will look like. Then you need to map each element to appropriate JavaScript function call. This involves holding two mental models in the head simultaneously. I need not tell you how costly it is for the brain to constantly switch between two tasks. Hence, from a pure efficiency standpoint it makes sense to start using JSX.

JSX is a great visual aid. With JSX, we can tell React exactly how we want our content to look like. The declarative syntax hides senseless complexity. There is no need to get tangled up in unnecessary details that distract developers from their true goals.

After reading this article, I hope you will come to like JSX a little better. However, in case I have failed in my attempt, I would appreciate constructive feedback. In the second article in this series, I will talk about Stateless Functional Components and how they can play a crucial role in building complex User Interfaces.

Originally published at blog.adityadixit.me.

Thinking in React Part 1: Some love for JSX was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.