When React was first introduced, one of the features that caught most people’s attention (and drew the most criticism) was JSX. If you’re learning React, or have ever seen any code examples, you probably did a double-take at the syntax. What is this strange amalgamation of HTML and JavaScript? Is this even real code?

Let’s take a look at what JSX actually is, how it works, and why the heck we’d want to be mixing HTML and JS in the first place!

What is JSX?

Defined by the React Docs as an “extension to JavaScript” or “syntax sugar for callingReact.createElement(component, props, ...children))

”, JSX is what makes writing your React Components easy.

JSX is considered a domain-specific language (DSL), which can look very similar to a template language, such as Mustache, Thymeleaf, Razor, Twig, or others.

It doesn’t render out to HTML directly, but instead renders to React Classes that are consumed by the Virtual DOM. Eventually, through the mysterious magic of the Virtual DOM, it will make its way to the page and be rendered out to HTML.

How Does it Work?

JSX is basically still just JavaScript with some extra functionality. With JSX, you can write code that looks very similar to HTML or XML, but you have the power of seamlessly mixing JavaScript methods and variables into your code. JSX is interpreted by a transpiler, such as Babel, and rendered to JavaScript code that the UI Framework (React, in this case) can understand.

Don’t like JSX? That’s cool. It’s technically not required, and the React Docs actually include a section on using “React Without JSX”. Let me warn you right now, though, it’s not pretty. Don’t believe me? Take a look.


class SitePoint extends Component {

    render() {

        return (

           <div>My name is <span>{this.props.myName}</span></div>




React Sans JSX:

class SitePoint extends Component {
render() {
return React.createElement(
“My name is”,
Sure, looking at those small example pieces of code on that page you might be thinking, “Oh, that’s not so bad, I could do that.” But could you imagine writing an entire application like that?

The example is just two simple nested HTML elements, nothing fancy. Basically, just a nested

Hello World.

Trying to write your React application without JSX would be extremely time consuming and, if you’re like most of us other developers out here working as characters in DevLand™, it will very likely quickly turn into a convoluted spaghetti code mess. Yuck!

Using frameworks and libraries and things like that are meant to make our lives easier, not harder. I’m sure we’ve all seen the overuse and abuse of libraries or frameworks in our careers, but using JSX with your React is definitely not one of those cases.

What About Separation of Concerns?

Now, for those of us who learned to not mix our HTML with our JS — how bad it was, and how if we did, our applications would be haunted by the Bug Gods of the Apocalypse — mixing your HTML inside of your JavaScript probably seems like all kinds of wrong. After all, you have to maintain a Separation of Concerns at all costs! The world depends on it!

I know, I was there, I was you.

But, as weird as it may seem, it’s really not that bad, and your concerns are still separated. As someone who’s been working with React for long enough to be very comfortable with it, using small pieces of HTML/XML inside your JavaScript codebase is really kinda … magical. It takes the management of HTML out of the equation, and leaves you with nice, solid code. Just code. It helps to ease the pain of trying to use a markup language — which was designed for building word documents — for building applications, and brings it back to the control of the application’s code.

Another issue of not separating out your JavaScript from your HTML: what if your JS fails to download or run, and the user is only left with HTML/CSS to render? If you’re building your application the React way, then your HTML (and maybe even your CSS if you’re using WebPack), is bundled in with your JavaScript itself. So the user really only has one small HTML file to download, then a large JavaScript payload that contains everything else.

Worrying about search engines and SEO is unfortunately still a legitimate concern. We all know that the major search engines now render JavaScript, but initial rendering with JavaScript can still be slower, which could have an effect on your overall ranking. To mitigate this, it’s possible to do an initial render of your React on the server before sending it to the client. This will not only allow search engines to pull your site quicker, but also provide your users with a quicker First Meaningful Paint.

Doing this can become complicated quickly, but at the time of this writing, SitePoint itself actually uses this method. Brad Denver did a fantastic write-up of how it was done here: “Universal Rendering: How We Rebuilt SitePoint”.

Rendering server-side is still only going to help with failed loads (which are uncommon) or slow load times (much more common). It won’t help with users who completely disable JavaScript. Sorry, but a React app is still a JavaScript-based application. You can do a lot behind the scenes, but once you start mixing in app functionality and state management (e.g. Flux, Redux, or MobX), your time investment vs potential payoff starts going negative.

Not Just for React

JSX with React is pretty great stuff. But what if you’re using another framework or library, but still want to use it? Well, you’re in luck — because JSX technically isn’t tied to React. It’s still just DSL or “syntax sugar”, remember? Vue.js actually supports JSX out of the box, and there have been attempts to use it with other frameworks such as Angular 2 and Ember.

I hope this JSX quick introduction helped to give you a better understanding of just what JSX is, how it can help you, and how it can be used to create your applications. Now get back out there and make some cool stuff!

Source: sitepoint.com