React’s JSX: The Other Side of the Coin

When React was released, many people took one look at JSX and lost their minds. What are these angle brackets doing in JavaScript?! What about separation of concerns? Has Facebook learned nothing from the community?

Like many, my initial reaction to React’s JSX was skeptical, to say the least. And while I’ve come to love JSX, anytime I introduce it to a new developer, I feel like I’m showing off my ugly baby.

Try to imagine an ugly baby here. My son is clearly adorable.

Try to imagine an ugly baby here. My son is clearly adorable.

Despite the initial drama, I’ve come to realize that JSX isn’t such a radical idea after all. In fact, it’s simply the other side of the coin. It’s a natural evolutionary transition. To appreciate why, a history lesson is in order…

Read more…

Subscribe to Email Updates (No spam. Just new posts.)

5 thoughts on “React’s JSX: The Other Side of the Coin

  1. JSX evolutionary?
    Back to server generated UI? Back to writing UI by code?
    No, thank you. Definitely devolution.

    The whole reasoning behind the JSX is flawed.

    In your article, you gave the example “of iterating over an array in a few popular frameworks” and come up wit conclusion that:
    “We’re effectively putting JavaScript in our HTML”

    First of all, where’s the Javascript in the Knockout example?
    data-bind=”foreach: users”
    That’s an HTML5 custom attribute. It’s made specifically for the purpose of allowing “proprietary information to be exchanged between the HTML and its DOM representation that may be used by scripts” (from Mozilla’s MDN).

    Second, with Knockout framework, who is forcing you to put JavaScript in your HTML?
    You should never do that because you’re breaking the MVVM concept.
    Some say “oh, but in real world there’s no other way sometimes”. No, there is, look to custom bindings in Knockout for example.
    Alternatively, Knockout also offers inline syntax similar to your Ember example, but that should not be abused and be avoided, it’s not the preferred or right way.

    Back to your example, with creating items based on iterating on a list of items in the model: the for-each in Knockout is a smart way to create and add HTML elements to a parent element.
    It’s an interesting pattern and it’s a solution for the today’s lack of web components. Ideally, there should be an items control where you can set an item template and the model’s property of an observable collection of items.

    About another thing you say:
    “Client-side frameworks shouldn’t require you to learn a proprietary syntax for declaring loops and conditionals.”

    Seriously, are you comparing JSX syntax, API, server setup and flow, with, for example, Knockout?
    You must be kidding me.

    But besides all these, the most important thing we should all realize and understand is that the lack of creating and standardization of new and better ways to develop web apps is the culprit.

    Can the majority agree that data binding is (absolutely) necessary?
    Can we agree that we need custom web components?
    Can we agree that we need controls like a flexbox or grid?
    With just the bare HTML and JS and without frameworks we would be coding like in the 90’s.
    Why can’t web adopt and standardize faster ways which in other development technologies exist for more than a decade?

    There are several signs things are apparently starting to move in the right direction: web components, polymer, Microsoft apparently started to adopt standards more with IE10, IE11, Edge, etc.

    JSX is is doomed and will fail while other frameworks like Knockout for example will continue to stay relevant because of the obvious differences in the way they work.

    • “where’s the Javascript in the Knockout example?”

      Right here: data-bind=”foreach: users”

      Yes, data- is an HTML5 standard, but it’s the content inside that matters in this discussion. This line is simply a DSL that ends up running a loop in JS. Knockout’s JS looks for the foreach keyword in the data-bind, then runs JS looping logic on the users array. So it’s merely a thin abstraction layer over JS. Same story with Angular and Ember.

      Regarding “Client-side frameworks shouldn’t require you to learn a proprietary syntax for declaring loops and conditionals.”:

      Consider a simple conditional.

      KO requires this:
      <div data-bind=”if: conditionalHere”>

      In React you simply use JS:
      if (conditional)

      I find the latter preferable because it’s plain JS. I can use all the power of JS instead of a the proprietary DSL that Angular, KO, and Ember offer.

      “JSX is is doomed”

      As fast as JS moves, everything we’re using today is ultimately doomed. 🙂

      That said, I’ve built significant apps in KO, Angular, and React. You can certainly build great apps in each. But I currently find working in React most enjoyable and productive. The excellent error messaging and simple API make it easy to compose complex apps. And I believe the pattern of “HTML” in JS is preferable to “JS” in HTML for the reasons I outlined in the article. I agree that web components are an interesting tech (which is why I published a Pluralsight course on them) and I’m excited to see what the future holds.

  2. Right here: data-bind=”foreach: users”

    No, that’s not Javascript.
    Sure, to make it work there’s some Javascript under the hood as you already described.
    But the point is your allegation was
    “We’re effectively putting JavaScript in our HTML”
    which is not correct.

    We’re not breaking any separation of concerns pattern, things stay nicely decoupled as they should.

    And about your other example:

    that’s a bad example. Yes, (unfortunately) Knockout let’s you do that, but you shouldn’t abuse it, instead use some properties in the view-model and bind to those.

    • Note that I said *effectively*. data-bind, ng-repeat, etc are merely a proxy to JS calls. They’re a DSL that calls JS behind the scenes. In the case of data-bind=”if..” that’s particularly evident.

  3. React is trying to buy everyone into the idea that the typical MVVM simple separation for example is bad and instead mixing and learning (yet another API) from some company is a good thing, just because it’s Facebook.