It's cool, you don't have to use JSX, you can just use the React.DOM functions. Or build a backend for whatever your preferred template system is, as long as the backend ends up creating nodes of React.DOM objects. Or you go with Om[0] and use EDN[1], Enlive-style[2] or hiccup-style[3] tempting.

Now if you want to physically separate the view logic and the corresponding markup generation, that's more debatable: they're extremely strongly coupled (and in fairly small chunks ideally) so you often can't trivially change one without the other, and thus keeping them together makes logical sense. See Pete Hunt's presentation which lumpypua linked, it tries to make that point fairly nicely.

[0] https://github.com/swannodette/om

[1] https://github.com/edn-format/edn

[2] https://github.com/ckirkendall/kioo

[3] https://github.com/r0man/sablono

Separation of concerns is a good goal, and your reaction is popular with people first seeing React (including me, several months ago!).

But consider that usually JS to control a view is inextricably linked to the underlying HTML and you need to modify both whenever making any change regardless -- since that's the case, you might as well combine all of the code and markup for the view in one place. Work to separate concerns, not programming languages.

Yes, yes you do. Pete Hunt's talk introducing React makes a really persuasive argument that in large frontend applications, having something markup-esque along with your JS is the best way to reduce component coupling and increase cohesion.

http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...

JSX isn't markup - it's XML which translates to Reacts internal representation which looks something like:

<div className='foo'>bar</div> -->

React.DOM.div({ className: 'foo', children: 'bar' })

You don't have to use it - it's a convenience provided for designers (and arguably developers who have realised that templating provides a false separation of concerns). Om notably (https://github.com/swannodette/om) ignores it.