If you’ve worked with React for a while, you have had this experience. Someone new sees JSX and says “I hate it.” You may have even thought the same thing while learning about the library. The reaction is visceral. Something deep inside thinks it’s wrong.
We have been trained to separate our concerns. The view should have a template. The model should handle the logic. The controller should tie them together. Heck, we even keep the style separate from the structure of the view! You know… for that one time a client asked you to create themes for a site.
So JSX assaults long held beliefs of ours. Does that mean it’s wrong?
I don’t think so.
Practicality Beats Purity
Experience teaches that practicality beats purity again and again. I didn’t want to believe it. Enough time out in the world shows you that’s just how things work.
Algol family languages beat out Lisps. Java and C# rule the enterprise. Angular triumphed over Backbone and Ember. In all these cases, the winner isn’t the purest. It is the one who gets the job done in a way most people can learn to do with ease.
React’s JSX carries on this fine tradition. XML within JavaScript makes writing components easier. It does so by using our experience working with HTML and transferring that skill to a new framework.
I would go even further and say you should also add your styles to the component itself. By doing this, handling changes becomes even easier. @vjeux’s gave a great talk on the benefits of Facebook’s approach. If you want to look into it further, the Radium and React Style libraries can help you write styles in JS.
Changes to templates and styles do affect the view logic in many frameworks. Remove a form field and the controller may still try to run validation on it. Add a new wrapper div and it might break a jQuery selector. How many times have I changed a template and broken the logic behind it? You don’t want to know. Separating those responsibilities into different files often just makes it more challenging to manage.
Can Designers Use It?
One of the common complaints is having designers work with React. Many believe separate templates and styles are good for designers. It allows them to go in and change them without touching the JavaScript at all. JSX changes that.
A couple points here:
One, I have worked across several companies now and the designers have fallen into one of two camps. The first group doesn’t touch HTML and CSS. These designers hand over images and it is the developer’s job to match it. The second group is so broadly talented that they also work with JavaScript. If your designers fall into either of these camps, JSX is not an issue.
Two, if your designers are capable with CSS and HTML, then JSX is a better choice than the JavaScript API. Many feel JSX was invented to make it easy for this type of designer to contribute to React projects. There is still a learning curve, but one where they can build on their existing skills.
Another common argument is JSX trips people up because it is similar to but yet not HTML. Attributes like `htmlFor` and `className` bother many newcomers. Unlike all the other valid attributes in HTML, these two are special. Not wanting to conflict with JavaScript keywords, they use different names here. A minor annoyance for sure.
Add to it that JSX is really an XML dialect of HTML, too. Valid HTML allows self-closing tags, JSX does not. Many devs, including myself, have been writing HTML as XML for a while now so it has become second nature. There are those who this could be surprising to, though.
Certainly this can irk you. It can give rise to silly errors at times. But definitely not enough to swear off using it.
And Now for Some Code
Here is actual code from a project I’m prototyping. Forgive me for any sloppiness here. Notice it reads like how most HTML would.
Here is the same code using plain JavaScript.
Being concise isn’t the most important thing when writing code. But this is a 30% increase in characters to express the same thing.
What is critical though is the `render` function is less readable. Boilerplate code obscures important things. Here it is difficult to find the types of elements and where they begin and end.
Further, the example shows that React itself puts the structure of the view within the JavaScript file. There is no getting around that (Well there is, but it’s probably not a good idea). You only have the choice to make it more or less readable.
Use It Until You Don’t Hate It
Maybe writing easier to read code doesn’t make you want to start writing XML in your JavaScript. Things about it bother you. It’s not HTML. There are those tiny quirks. Writing the template in the JavaScript file feels dirty. Maybe you have a workflow where designers are touching templates.
Most developers want to hate JSX the first time they see it. I did.
My only advice: give it a fair shake. Then keep using it even after that fair shake.
It’s like a selfie stick. At first you thought it was the most stupid thing you had ever seen. Now you just find it useful. Maybe you even start to enjoy it.
Once you don’t hate it, then you can join the rest of us in trying to convince new people it’s really good. Welcome to the cult.
