

But still, it would’ve been nice if they took a more ES6 ish approach. Of course, JSX was created so that you don’t have to use React’s virtual DOM API, which can get very verbose with a method call for each DOM element. React being one of the communities that push ES6 most aggressively, I would’ve liked to see them implement views largely based around ES6 string interpolation. In that last aspect, it’s sort of like Jade, which you can also mix with JavaScript, but I’ll admit that mixing JavaScript and JSX is way cleaner than mixing JavaScript with Jade. We rarely see hybrids like JSX, a language that’s more or less aligned with XHTML but which also comes with some gross limitations in what you’re able to do with it, alongside “cool” features like being able to mix it with JavaScript code. Web-oriented template engines typically consist of an entirely new language – Jade, Dust.js, etc – or a few extensions on top of HTML – Mustache, Hogan, Nunjucks, etc. 1961 Buick "Flamingo" with rotating front seat JSX is the new XHTML I’ve really enjoyed the ES6 and Babel experience, although I’ve noticed that there’s a learning curve where you start to decide whether using an ES6 feature is better than its ES5 equivalent or not, something we’ll explore towards the end of the article.

Then there’s JSX, definitely the weirdest aspect of React – we’ll look into it as well. React is pretty neat, but I find that they made some very unusual choices when it comes to their API design.

I’ve spent a few days working with JSX and React and I have mixed feelings about them.
