Check out a free preview of the full Complete Introduction to React (feat. Redux and React Router) course:
The "What is JSX?" Lesson is part of the full, Complete Introduction to React (feat. Redux and React Router) course featured in this preview video. Here's what you'd learn in this lesson:

On the surface, JSX looks like HTML markup in JavaScript. However, under the hood, JSX is allowing developers to use HTML syntax to compose JavaScript components. Since JSX is not valid JavaScript it still needs to be compiled with Babel. Brian spends a few minutes refactoring the MyTitle component to use JSX.

Get Unlimited Access Now

Transcript from the "What is JSX?" Lesson

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Brian Holt: Now we're going to go convert our app to be JSX instead of just raw JavaScript. Because now, it's being run through Babel. Babel understands JSX and it can output it.
>> Brian Holt: So, let's talk about a little bit what JSX is. First of all JSX is a big reason why React did not catch on for over a year after I got open source.

[00:00:33] It was a good 18 months before I picked it up and I I tried it once and I was like this is gross. I'm not touching it and I left it and came back later. It's like, okay I just had to throw a bit of caution to the wind.

[00:00:46] So JSX basically allows you to write HTML in your JavaScript, like that's the the gist of what JSX is. And a lot of people look at that and say, why in the hell would I ever want to write HTML in JavaScript, right. I'm in JavaScript. I want it to be JavaScript.

[00:01:00] I want my HTML to be HTML. Furthermore, people point is, we just got away like five or six years ago of writing JavaScript in our HTML. Why would you want to flip that on its head and write HTML in our JavaScript. All valid complaints and if you're feeling that way you are certainly not the only person.

[00:01:17] In fact, I would almost guarantee that every person felt that way when they saw JSX for the first time.
>> Brian Holt: The reason why it's really great is, because if you look at what we code we've written here in my title. What is this doing? This is really just mimicking what our Ishmael eventually is going to look like, right.

[00:01:37] We're doing the same sort of nest in the same sort of indentation. We're ultimately just mimicking what the way it looks. So if we're just mimicking it, wouldn't make sense to maybe just do it in the first place, right. Instead of having mimic in it, we can literally just write the HTML that we're looking for.

[00:01:55] So, that's why I find it very valuable. I'm actually writing the HTML that I intend to see on the page.
>> Brian Holt: The other thing is, that React kind of eschews the idea of a traditional model view controller, right. And Model View control works amazing on a server, right.

[00:02:17] Like for all of you that have written, Django or rails or any one of those mvc's. It's a really great idea on the server to separate these concerns from into models, used controllers. That's a good separation of concerns for the server and someone said, well if it's good for the server it must be good for the client.

[00:02:34] And so, we brought that in, like with Backbone and earlier Angular and earlier Amber, right. Like we've been writing these model view controllers, as well in the client and to me, it's a really leaky abstraction. Like what what works for interacting with databases is not necessarily good for user interfaces.

[00:02:51] User interfaces are an entirely different beast in my opinion. So what React has had to do instead of trying to separate, arbitrarily in my opinion. These different concerns into a model, a view and a controller. What they decided to do is, they tried to separate it into individual components.

[00:03:07] And they take all the concerns, that entire model view controller and they just mash it into together very small components. So when you're looking at a component, you see all of the concerns in one place now. And in my opinion, that makes a lot of sense, because these components are now entirely self-contained.

[00:03:23] And if you have a bug in a component, there's only one place it can be. It's not in the model. It's not in the view. It's not the controller. It's definitely inside of this one component and so, I think that's really powerful. So, if I go to a web page and I see there's something wrong with my navigation bar, right?

[00:03:39] Like the sign out button is broken or something like that, I know precisely what's broken about it, right. Like I know it's broken somewhere in this component and that ability to just visually debug a page. Super, super powerful, right? You now have limited, from the hundreds of thousands of lines of code that you have.

[00:03:56] You know it's in this block of code somewhere, it just has to be, right.
>> Brian Holt: I don't know if anyone's here is coming from an Angular background. That's what I came from and if you have a bug in Angular, it can be in the template. It can be in the directive.

[00:04:11] It can be in the directive that transcluding in the other directive. It can can be in the controller or it can be in one of the many services you're bringing in, right. Just by looking at a component, say there's a bug on that with this particular component. You still don't necessarily know what's happening or where it is.

[00:04:29] Now, that's not entirely true. You can still have external bugs in React, but if you write your React really well, typically those just don't happen. So all that to say, that I believe one, that JSX is a good thing and I believe that React uses it really well.

[00:04:50]
>> Brian Holt: Any questions about that so far? Like kind of the ideology behind JSX or React? Okay, so I almost guarantee anyone that toughs through and writes a bit of JSX. And gets through writing like a little app that way, almost no one goes back. [LAUGH] So if you just give it a shot then, then it'll be good.

[00:05:18] Much more so, I understand a lot people don't like standard. That they're going to do standard today and then say, Brian's an idiot, I'm no longer going to do it. I'm totally cool with that, but most people don't say JSX is a bad idea. But that is to say, you can always go back and write it this way.

[00:05:33] And there are some smart people that I know that have elected to do it this way. I just choose not to. Okay, so let's open my title.js and let's go ahead and rename it to my title.jsx.
>> Brian Holt: The reason that we do this, it's not going to really change anything.

[00:06:03] If you remember in our web pack thick, we set it up to look for JS files, so this would work either way. The reason why I put the X on there is, to let future Brian and other developers touching this code. Know that this file must be transpired or it is not going to work.

[00:06:22] This is not valid JavaScript and anything that I put .js on, I myself expect to be strictly valid JavaScript. And JSX is not valid JavaScript. It's valid JSX, which has a path to become valid JavaScript through Babble.
>> Brian Holt: Okay, so here in render, instead of doing this right here, we're going to say div instead of that okay.

[00:06:59] And instead of H1 here going to say H1
>> Brian Holt: Let's actually put this on two lines, becayse I think that'll be a bit clearer.
>> Brian Holt: And we're actually going to move this into here.
>> Brian Holt: This actually is not going to be an object.
>> Brian Holt: Okay, someone here said it feels dirty and understandably so, right.

[00:07:44] But it's pretty magical. I think it's pretty cool. Okay, so we have to do a couple other things here. So first of all, if we'd say this.props.title, like this. It's literally going to put the string on there this.props.title which is not what we want, right? That's not the intention here, so you need to surround it with curly braces.

[00:08:04] Now, why are we putting in curly braces here? The reason we're putting curly braces here is if you said the inside of my curly braces I'm going to give you a JavaScript expression. I want you to evaluate that JavaScript expression and put whatever that returns into here. So for example, if I have like, you don't have to do this.

[00:08:26] I'm just giving an example. Const stupid FN or something like that equals function. Return stupid FN or something like that right there. So this is actually like a real function and so, if you're I can actually say stupid FN and call the function. So, anything that you can do with a JavaScript script expression can be put into there.

[00:08:53] Or, we can even do this this dot props title like to uppercase right? That works too. Anything that you could put on the right side of a new assignment like var x equals blank. You can put in the here and that's okay. Okay, so now we've learned that these these curly braces mean expression or a word also applies to attributes here.

[00:09:20] So we actually have to surround this one, as well with another set of curly braces and it's kind of weird. Let me explain why that is the outside of a curly. A set of curly braces means JavaScript expression, right? The inner set of curly braces means like literally just like a normal JavaScript object, right?

[00:09:40] So if this feels better to you, you can actually copy paste this and say, style and then here, say const style = that. Does that splitting apart feel better for you? I don't know, explain better what's going on there. Some people get weirded out by seeing two sets of curly braces and they think it's a mustache or something like that and it's not.

[00:10:01] It's totally different. It's literally an object inside of this expression.
>> Brian Holt: Okay, any questions about that? You can get rid of this too.
>> Speaker 2: Can you do ask name instead of sending down the style from props to just hardcode like a.
>> Brian Holt: Can you do like CSS class names?

[00:10:33]
>> Speaker 2: Yeah.
>> Brian Holt: Yeah, absolutely. And we'll do a lot of that here in a little bit.
>> Speaker 3: You put a semicolon there.
>> Brian Holt: Did I? It's going to yell at me. So, it is force of habit. I'm still getting used to this. The other thing is, don't try and run standard right now.

[00:10:50] It's going to barf on you. [LAUGH] Actually, it should be okay. It should be okay, but it's going to view it's not going to lead to your react yet and we have to configure that later.
>> Speaker 4: Why don't you put quotes around the style attribute?
>> Brian Holt: Like inside of here or?

[00:11:15]
>> Speaker 4: Outside of the braces.
>> Brian Holt: So, if you wanted to literally put in the style, right. You could actually do that and that's actually, it might not work for style but by putting the curly braces to supplant the quotes right. So if you're putting in curly braces, you don't need the quotes and that's just the way it is.

[00:11:41] I don't know there's a good reason for it. Well the reason for it is, once you're inside quotes, this doesn't work. Because it's actually going to put literally the curly braces in there, right. So once it's a string, it says okay, I'm not going to evaluate anything about this.

[00:12:03]
>> Brian Holt: Okay, so any questions about MyTitle, what we did to it? Okay.
>> Speaker 3: Asking why are you using constant instead of R?
>> Brian Holt: I did mean to explain this, that's a good idea. We're in ES six wonderful play land now, right. So all these can actually be are constant now.

[00:12:32] The reason why use const and this is up for debate. So, this is a Brian Holt opinion. This is not necessarily you must do this. I use const everywhere and then, I don't use var at all, anymore, period. And the reason why I use const and not necessarily let is, because I default to const.

[00:12:54] Because I'm letting my future self and other devs know that I don't plan on changing this right now or ever, right? And then,the moment that I do need something that I need to be able to change, I'll say, let x, right. And that's letting, again future self/other people know, that I have X and I plan on X is going to mutate sometime down the line.

[00:13:17] It's just footnotes for whoever comes after me. That make sense?
>> Brian Holt: Okay, cool. I really like something that Kyle Simpson says, that code is more for future developers than it is for a computer. You're just annotating what you're doing by the way that you write code. And so, any future hints that you can give to yourself, like hey, I'm doing this and I plan to do this.

[00:13:46] And I'm setting these limitations on myself is usually helpful. And it's funny that I quote Kyle to promote that idea, because I know Kyle doesn't really like const. [LAUGH] I'm using his own logic against him, though, you probably should listen to him, because he's ten times smarter than I am.

[00:14:05]
>> Brian Holt: Actually, empirically speaking, I believe he's literally ten times smarter than I am.