JSX Is Not What Most React Developers Think It Is

You’ve written hundreds of components by now. But do you know what JSX actually is?

I used to think it was just “HTML inside JavaScript.” I was wrong on both counts.

Once you understand what JSX becomes, a lot of React suddenly stops feeling magical. className starts making sense. The single-parent rule makes sense. Even those curly braces you keep typing start to feel obvious.

Let’s strip it down.

A familiar line of code

const greeting = <h1 className="title">Hello</h1>;

At a glance, this looks like HTML sitting inside JavaScript. That is the first illusion.

So what does the browser do with this?

Here is the surprise: the browser never sees this line in this form.

JSX is not something the browser understands directly. Before your app runs, something else steps in and transforms it into plain JavaScript.

That “something else” is Babel.

What Babel does

Babel is a transpiler that runs as part of your build tool, like Vite.

It takes JSX and turns it into normal JavaScript that the browser can execute.

So this:

// What you wrote
const greeting = <h1 className="title">Hello</h1>;

Becomes this:

// What Babel turns it into
const greeting = React.createElement("h1", { className: "title" }, "Hello");

That is the real trick.

JSX is just syntactic sugar — a more readable way to call React.createElement.

That is why JSX feels so natural. You are not teaching the browser a new language. You are using a nicer way to describe JavaScript function calls.

And once you see that, React gets a lot less mysterious.

One step deeper

Here is the next surprise: React.createElement does not return HTML either.

It returns a plain JavaScript object.

Something like this:

{
  type: "h1",
  props: {
    className: "title",
    children: "Hello"
  }
}

That is it.

JSX becomes a function call, which becomes a plain JavaScript object. No HTML anywhere.

React is building a description of the UI, not the UI itself.

Then ReactDOM comes in and reads those objects. Its job is to translate them into real DOM operations in the browser. That is the part that actually creates, updates, and removes elements on the page.

So JSX is not the final output. It is just the most convenient way to describe what you want the UI to look like.

Why this matters

This is where things start making practical sense.

First, className instead of class makes sense. JSX is JavaScript, and the object key is className, not class. React uses the JavaScript version because class is a reserved word in JavaScript.

Second, the single parent rule makes sense.

A component is just a function, and a function can only return one thing. So when you write JSX, React needs one top-level return value. That is why you wrap sibling elements in a fragment or a parent element.

Third, curly braces start to feel natural.

Inside JSX, {} lets you embed JavaScript expressions. Not full statements, just expressions. That is why this works:

const name = "Dilshan";
const greeting = <h1>Hello, {name}</h1>;

You are not writing a template language. You are mixing JavaScript values into a JavaScript-based description of the UI.

And this one matters too: <Component /> is different from <div />.

A lowercase tag like <div /> tells React, “this is a built-in DOM element.”

A capitalized tag like <Component /> tells React, “this is a component function or class.” That one small capital letter changes how React treats it.

The big idea

So next time you write JSX, remember this: the browser never sees JSX. It sees the JavaScript objects React produces from it.

That is the real mental model shift.

JSX is not magic. It is just a cleaner way to describe UI in JavaScript.

What was the most surprising thing you learned about React after using it for a while?