JSX is not HTML inside JavaScript — it is a compile step

Question 1

Opening a fresh React project and reading App.jsx often produces the same surprise: the file is JavaScript, yet it contains markup that looks identical to HTML. A first glance at a component returning an <h1> invites the question of whether the language runtime somehow learned to parse tags.

Before reading on, decide whether plain JavaScript understands this:

const heading = <h1>Hello World</h1>;

• A) Yes
• B) No

The correct choice is B) No. A stock JavaScript engine has no grammar for <h1>. Drop the same line into a .js file without a transform step and the parser reports a syntax error.

React never ships JSX to the browser. A build step rewrites the markup into ordinary function calls first. Conceptually the pipeline looks like this:

You write JSX
      │
      ▼
Compiler (Babel / Vite)
      │
      ▼
JavaScript
      │
      ▼
Browser

What reaches the browser is JavaScript only. The tags you typed never appear in the network response as JSX.

Think of it like Google Translate

Imagine writing a letter in French for a friend who only reads English. The friend does not suddenly understand French; a translator sits in the middle. JSX works the same way. You author the HTML-like syntax, the compiler (Babel, SWC, or the transform inside Vite) turns it into JavaScript, and only then does the browser execute it.

Then What Exactly is JSX?

Beginners often summarize JSX as “HTML inside JavaScript.” That shortcut is wrong. JSX resembles HTML, but it is not HTML. A tighter definition: JSX is a JavaScript syntax extension that lets you describe UI with an HTML-like surface. The important word is HTML-like—not HTML itself. Attribute names differ (className instead of class), and the surrounding expressions live inside JavaScript’s value system rather than a separate markup language.

Why Was JSX Created?

Without JSX, the same heading:

<h1>Hello React</h1>

would be expressed with nested factory calls:

React.createElement(
  "h1",
  null,
  "Hello React"
);

A full page written that way becomes hard to scan. JSX exists so the structure of the UI stays readable while the compiler emits the React.createElement (or equivalent) calls behind the scenes.

Question 2

What does this render?

const name = "Ananya";

function App() {
  return (
    <h1>Hello {name}</h1>
  );
}

• A) Hello {name}
• B) Hello Ananya
• C) Syntax Error

The answer is B) Hello Ananya. Curly braces tell JSX to pause markup mode and evaluate a JavaScript expression. The value of name is interpolated into the heading, so the UI shows the string, not the brace syntax.

Curly Braces Have One Job

Whenever JSX sees {…}, it evaluates the expression inside and inserts the result. That is the entire contract: run JavaScript, place the value. There is no second mode for statements or side-effect blocks.

Question 3

Which brace contents are legal in JSX?

• A) a variable reference such as {name}
• B) an arithmetic expression such as {10 + 20}
• C) a block-style if written inside the braces
• D) a ternary that chooses between "Adult" and "Minor" from age

A, B, and D work. C does not. JSX only accepts expressions that evaluate to a value. A bare if is a statement and yields nothing to place in the tree; a ternary returns a value, so the age check in D is fine while C is rejected.

Final Thoughts

JSX can feel like magic on day one: it looks as if HTML and JavaScript merged into one language. The mechanics are simpler. JSX is authoring sugar. Before the app runs in the browser, a compiler rewrites it into ordinary JavaScript. Once that pipeline is clear, the markup-in-JS syntax stops being confusing and becomes a readable way to describe UI trees.