Well, now.<p>Firstly: context switching is an inevitable inconvenience, but in JSX you&#x27;re context-switching <i>line by line</i> between two radically different syntaxes.<p>Secondly: switching into <i>what</i>? It&#x27;s not HTML (Angular templates, for instance, are not going to win any beauty contests, but they are technically valid HTML). XML? No, not that either. So ... something that looks kinda like HTML&#x2F;XML,  but which isn&#x27;t really. It&#x27;s perfectly legitimate to sacrifice aesthetic elegance for the sake of adhering to well-understood standards. But if you&#x27;re <i>not</i> going to adhere to that, then why pick something that is merely similarly ugly? I don&#x27;t get it.<p>Thirdly: templating&#x2F;view layers always face a trade-off - either they are embedded within the host language, or they use an external DSL which is parsed&#x2F;compiled by the host language. The trade-off is: better change of &#x27;correctness&#x27; and cleaner interop with the rest of the language if it&#x27;s an internal DSL; on the other hand, with eternal DSLs, at least the possibility that non-engineers will be able to work on things. With JSX, you end up grafting an &#x27;internal&#x27; DSL simply by adding a whole pile of syntax to the core language. You don&#x27;t have the advantages of the separate template language, and you lose <i>some</i> of the advantages of the other by requiring a whole pile of extra tools. JSX is an attempt <i>not</i> to choose, in a situation where compromise is basically impossible. Hence its extreme awkwardness - just like E4X before it.<p>React has done some good things: it&#x27;s put performance on everyone&#x27;s agenda in a big way (Hallelujah!), and it has acted as a testbed for interesting front-end architectures. JSX, however, I feel is a serious mistake. I actually <i>enjoy</i> writing React code through Reagent or similar, but in native JS and especially JSX, it just <i>feels</i> awful. I just don&#x27;t want that in my editor window.