This sentiment is an artifact of javascript being used to add functionality to an existing document, which is still a very useful case for javascript, and it seems people are dismissing it, which is a shame.

When you're building an application, something like the atom text editor, or the youtube video player — something interactive and ostensibly not a document — the segregation of markup and javascript is artificial. Yes, it's a good idea to keep your presentation separate from your logic (although religious devotion to this idea is unnecessary, it's just an abstraction that's useful has stood the test of time, not holy law), but your javascript view code is just as much a part of the presentation as the markup.

In response to a sibling comment, you claim "you dont want to mix the 'structure' of your UI with the behaviour". The fact that your views have a "structure" to begin with is again an artifact of the web's original intention of hosting documents rather than applications. The structure of your view is actually an implementation detail (a concept that's formalized by the Shadow DOM standard in the WebComponents proposal), and separating it out from your view code implies otherwise.

I hear this complaint a lot about JSX but what you have to understand is that it is actually way better than using a template language.

If you're also against things like Handlebars, ERB, Smarty, etc then fine... but otherwise this doesn't hold up.

Why? Because all template languages must be compiled to the host language to work. Handlebars ends up as JS functions (and really ugly and messy ones I might add) for example.

This is fine if, for some reason, you're in 2001 and handing off all templating to designers who know nothing about code and just have to put HTML in a template with the right variables... but it's a very very janky practice.

JSX just says "well, why bother when you can do it in the right place in the first place?" Template languages have logic so why not just use JS and correctly encapsulate the logic in a View?

Answer? No good reason to not do that... so it's a net win.

Here's a good answer to your question:

https://www.reddit.com/r/javascript/comments/2uvz0x/whats_so...

Except in reality you're mixing your presentation with your presentation.

The issue is that the pattern for a long time has been even worse, making your logic deal with your presentation directly.

React is a view layer, so a good React component is all presentation and doesn't contain any business logic. The only logic in a React component is presentation logic, which belongs together with your presentation structure and your presentation style, IMO.

I like this answer, however, its still not sufficient. Because you dont want to mix the "structure" of your UI with the behaviour of it. But in very dynamic apps behaviour = structure. So in that case React makes sense.

However, i dove into web components with Polymer, and it seems that this is the "official" direction of components in the future web... It also doesnt try to mix HTML with JavaScript. In fact in the future there will be more langauges than javascript since there will be a bytecode for the browser. Having your app written in React poses a real problem when you want to switch your logic to a different programming language.

So isnt the Web Components solution much better?

It seems that React and Web Components can be combined: https://github.com/Wildhoney/Maple.js

> you dont want to mix the "structure" of your UI with the behaviour of it.

And you don't have to with React. But you can do this kind of mess with any templating langauge - it's not a React issue, it's a bad programming issue.

> Having your app written in React poses a real problem when you want to switch your logic to a different programming language.

It really shouldn't. It's a View layer and the JSX part will be (practically) HTML still so it'll be really easy to port. The rest of the view logic would have to be ported no-matter what you use to decorate it.

So this isn't really an objection.

"future" is the key word here I think. Yes, that's where it is going, but not yet.

I think that kind of thinking is really suitable for the JS world of a few years back. If you're just using vanilla JS + DOM API, it can be pretty messy to include HTML in your JS. However React's setState handles DOM changes and rendering, so it's less of a pain. So in answer to your question of why people don't, I think it's because they're not viewing this as a problem anymore.