Andy Ray's Blog

TL;DR React was open sourced in 2013. Three years later, my blog posts still receive many false arguments about JSX. Let's get on the same page.

"JSX Violates Separation Of Concerns"

React is mainly the view layer. React is only the view layer. We're only in one concern. React only knows how to render markup. It doesn't know where your data came from, how it's stored, or how to manipulate it. What concerns are being violated?

"JSX Violates Separation Of Technologies!"

We used to separate HTML from Javascript because if Javascript wasn't available, vanilla HTML could still render. That's not relevant to Angular nor React applications.

JSX isn't HTML. It's a DSL (domain specific language) over Javascript. It's Javascript all the way down. There's no HTML here, and React allows server side rendering. We still get HTML loading even if users' Javascript is disabled.

"Separation of technologies" isn't a computer science principle. Any template library you choose compiles to Javascript anyway.

"Use XYZ Library To Get Real Templates For React"

If you want to use something like react-templates because your team prefers it, more power to you. Just make sure you understand what problems you're actually solving.

What do Angular templates, JSX, Handlebars, react-templates, etc, have in common? They all compile to Javascript, and they're all templates.

What's the logic difference between the following view code snippets?

<div rt-if="this.state.resultCode === 200">
    Success!
</div>

  {{#if this.state.resultCode === 200}}
    <div>Success!</div>
  {{/if}}

{ this.state.resultCode === 200 ?
    <div>Success!</div> :
    null }

Nothing. It's the same thing. In the first one, it's ambiguous if an empty <div> will render. But the logic is the same.

They all contain syntax that diverge from vanilla HTML. It's only personal preference. It's like commenting on an open source project to convert tabs to spaces.

I personally prefer my code be lintable, with syntax highlighting, and not have to write it in strings. I want to write with the flexibility and familiarity of vanilla Javascript. I want to be able to set a breakpoint in my raw template code and inspect the stack. These come for free with JSX.

React has such high adoption in part because it stays close to vanilla Javascript. The API is thin and there's not much to learn. Keeping view code in vanilla Javascript is a win.

"Our Designers Can Write Templates, But Not JSX"

If you see a permanent slowdown from designer productivity loss, you might have a valid reason to consider a non-JSX solution. Make sure you understand what you're giving up and why.

The more I work on Front End™ teams, the more I understand the importance of close, overlapping relationships between designers and developers. When developers ignore CSS, CSS becomes a nightmare and the application becomes brittle. Not because designers are bad at writing CSS, but because styles are viewed as "someone else's problem."

If your designers write CSS, they're probably comfortable writing minor logic inside { curly braces }, like any other template language. If they aren't comfortable, is pairing with a developer to write some code a bad thing?

Is JSX really harder to understand for a designer than <div rt-scope="users[userId] as user; user.profile as profile;">?

Again, this is just preference. I personally don't see any benefit that other templates have over JSX, and after working with JSX for a few years, I really enjoy it.

Use The Right Tool For The Job

If you want to diverge from JSX, make sure you understand why. Make sure you know the trade-offs. Don't use non-arguments based in misunderstanding and personal preference.

I leave you with a lovely tweet:

"When a developer complains about having to learn something new, I assume they don't understand the underlying premise of their job."
@gnomeontherun

That's It!

If this helped clarify the landscape around JSX and React, consider following me on Twitter.

If you're diving into the Front End ecosystem, perhaps Webpack: When To Use And Why will be helpful.