[zdragnar]

Think of JSX as a macro, rather than "regular" templating, which is typically string substitution.

For static sites, this means that you get functions and objects the entire way through the render pipeline right up until there is a full tree built and the final output is rendered.

You still get all the separation powers of contexts, the component based reusability, etc, and it is all regular JavaScript / typescript except for the JSX macro itself and React's APIs (which are just JavaScript). Conversely, with templating engines like handlebars / erb / et al you need to learn the specific DSL of the template engine- custom loops and controls, imports for partials, and your custom helpers are limited to what they can do. Even Vue's render function has special markup for control (v-if, v-else).

[ricardobeat]

Some day we have to stop repeating this nonsense. JSX requires much more learning than simple templating, there is no inherent benefit. Even a simple conditional is more complex than your average template.

[zdragnar]

How so? Any expression is valid within JSX- ternaries, function calls, binary and unary operators are all valid. If you know JavaScript, you already know all of the control mechanisms that are valid.

[cercatrova]

The thing is, if you know JS, then a conditional is JSX is the same as in JS. Contrast that with every new templating language under the sun which might have its own way of doing conditionals and loops and control flow. That to me is much more annoying.

[chrismorgan]

This is a dubious claim, since JSX is limited to expressions. If you ask people for “a conditional in JS”, they’ll very probably go for `if (…) { … } else { … }` first, not `… ? … : …` (if you can even rewrite it as a ternary). Same deal with loops: you’re limited to expressions, so you can’t use the normal way of writing a loop (and this regularly leads to mild contortions as you deal with iterables of diverse types). Therefore I’d tend to (qualifiedly) describe JSX as doing its own thing too.

[zdragnar]

Plenty of people are taught that ternary operators are evil and should never be used.

Plenty of people were also taught that proper architecture involved an AbstractGetterVisitorFactoryFactory.

That doesn't make either of those things true.

As a side note, if you find yourself wanting a loop but using `map` isn't sufficient, you should probably be preparing the values ahead of time and still using map. It'll be more efficient, and the code easier to read.

[9dev]

But you’re aware JSX is just plain old PHP files, code intermingled with HTML? It’s the exact same thing, and it breeds the exact same bad behaviour.

[zdragnar]

Separation of concerns is different from separation of languages.

PHP intermingled with HTML was bad because developers would do things like run database queries and other operations that caused side effects directly in the markup. Every templating system still has logic in it, and almost every templating system as a way to create custom helpers which are written in the host language.

Since API calls and calls to react's `setState` are asynchronous, and the rendering pipeline is synchronous, it is still obvious that you can't put code that makes an AJAX call in your html markup.

[9dev]

JSX doesn't separate languages, you're mixing HTML with TypeScript. You can absolutely do database queries in your template. What is keeping you from doing `fetch('https://side-effect.ts').then(() => doSomethingHorrible())` in your template? Or invoking an `alert()`?

[zdragnar]

You can do those things, but you're not going to capture the effect that you want. Renders happen frequently, and the render process will complete before your `fetch` resolves. As for alert, the alert will pop up immediately before the render is applied to the DOM- and will likely pop up many times more than you thought it would, assuming you're popping it up based on some state variable.

In short, you can do those things maliciously, but if you do them naively it is immediately obvious when you run the code that it's not correct.

Compare that to the original analogy to mixing raw PHP and HTML templates. Since the rendering process is blocking, you can easily stuff form handling, remote API calls, and database calls in amongst your markup, and can make it "work" even if it's not clean.

Even Laravel's blade components let you write custom components and helpers in PHP which can do all of those things from the template- you just don't see the actual SQL mixed with the HTML in the same file. The problem is still there, just now it is harder to see.