A Case For JSX

3 min readApr 30, 2015

“ It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.”
— Alan Perlis

First Impressions

The most common reaction most people have when they see JSX for the first time is that the React developers must have gone crazy.

What? Are they suddenly having delusions that old-school PHP mixed inline with HTML is sound architecture? Remember that particular bowl of spaghetti?

<table>
<tr>
<? $q = mysql_query(
          "SELECT * FROM foo WHERE bar = $sql_inject_me");
while ($row=mysql_fetch_assoc($q)) { ?>
  <td><?=$row['name']?></td>
  <!-- and so on ... -->
<? } ?>
</tr>
</table>

Brrr.

But this comparison is dead wrong. Also kind of ironic considering that it’s
common practice to use PHP directly as a template engine, restricting oneself to simple view logic only. And there is nothing wrong with that.

But no, React developers haven’t gone crazy, on the contrary. Let me try to to explain why JSX is better than traditional templates but at the same time also no big deal, nothing new and not that crazy.

JSX is Syntax

First of all, to get all misconceptions out of the way, JSX is syntax. We’re not dealing with strings here. When we’re writing JSX we’re really just writing regular JavaScript code that’s constructing regular JavaScript data structures. The notation is just syntactic sugar, nothing more. JSX has no semantics. It’s a mechanical translation from

<div id=”foobar”>foo</div>

React.createElement(‘div’, {id: ‘foobar’}, “foo”)

and there is nothing more to it. So what JSX really gives us is just a more convenient syntax. And that is pretty cool but what’s even cooler is that now we’re just dealing with regular plain old JavaScript data structures.

Data is King

Working with HTML this way is nothing new. Functional programmers, especially Lispers, have always done this.

Here’s a short Clojure example using hiccup:

[:p.info.muted “Hello”
 [:strong “World”]
 [:small “yo what’s up”]]

If you squint a little it almost looks like JSON even. So it should be pretty obvious that we’re just dealing with nested lists here. Very simple data structures.

Why is this important? It is important because data truly is king. Unfortunately as programmers we usually care much more about our programming languages and how to structure our programs than we do about our data and how to lay it out and convey it.

However, data is the ultimate interface. Rich Hickey talks about this from the perspective of entire systems in The Language of the System and Gary Bernhardt explores it in the small in Boundaries, both of which I’d highly recommend to watch at least twice.

An Arbitrary Dichotomy

Most people would probably be horrified to see a template engine being used to produce JSON or XML. But when it comes to HTML it’s the complete opposite. Why is that? There is no fundamental difference between those outputs. They are all just serialization formats. And XML and HTML are actually almost the same.

You may argue that HTML is different in what in conveys. But what the data conveys is orthogonal to how it is serialized. Would you use a template engine to generate XML just because it describes a user interface? Of course not. This would be horrible. You would use an XML library of course and if it’s a good one it will work on pure data.

To quote the MochiKit Docs, an “ancient” JavaScript library that takes this approach to some degree, which it based on Nevow’s Stan:

If you have never used an API like this for creating DOM elements, you’ve been wasting your damn time. Get with it!

tl;dr

Using a crippled DSL to serialize a data structure is a fools errand.
You can have the best of both worlds if done right
Data Reigns Supreme
JSX is just neat syntax sugar

If you have questions or comments I’d love to discuss them with you on Twitter.