3 ms·

> We have PHP, which is superior as a templating language in every possible way It’s been a very long time since I’ve written any PHP, but even when I did writ

> We have PHP, which is superior as a templating language in every possible way It’s been a very long time since I’ve written any PHP, but even when I did write PHP pretty much full time this wouldn’t have been my impression. Tooling aside, JSX is exactly what I would have wished for PHP templating to be (if I had had the foresight to wish it). In fact, if I’m not mistaken, I believe better templating in PHP is the JSX origin story? Don’t get me wrong, if you prefer PHP for templating, I have no quarrel with your preference. My gripe, insofar as I have one, is the preference stated in an objective framing.

tambourine_man 3y ago
Sure, preference is subjective. What is objective is that JSX is very constrained. Both because it lives inside another language (JavaScript) and by design. It must only return a single element, you can’t add arbitrary attributes, its control flow syntax seems (subjectively) bolted on, etc. When you’re coming from a language where you can print anything, it's very frustrating.
- eyelidlessness 3y ago
  Some of this isn’t right or deserves clarification. > It must only return a single element Assuming you mean “return” as in a JSX expression in a return statement (though the same applies to a JSX expression in any valid syntax position), it can be any of: - one Element (which may or may not correspond to any markup element, it can resolve to basically anything depending on implementation) - zero Elements (<></>) - a non-Element child-compatible expression (typically a primitive value in most implementations) - any arbitrary non-Element expression (behavior will vary depending on implementation support) - N Elements (<>…</>) > you can’t add arbitrary attributes This is entirely implementation dependent. Attributes aren’t even part of the syntax (they’re “props”), and many implementations differ on how or even if they correspond to attributes at all. The spec does not constrain arbitrary prop names. > its control flow syntax seems (subjectively) bolted on It’s actually the inverse: control flow is anything that can be used in a JS expression position; JSX is bolted on (extends) the expression syntax. Some implementations and/or libraries also implement control flow as JSX Element expressions (eg Solid’s For, Show, Switch/Match). > When you’re coming from a language where you can print anything, it's very frustrating. The only real limitation syntactically is that everything in a JSX expression must be an expression itself. This isn’t as limiting as it sounds, because functions can be expressions (with anything in their body, and can be invoked as an expression inline at their definition site). It might help to think of JSX as more like an S-expression (as in Lisp). It can express any value (that the language can produce), but it can’t express arbitrary statements.
  - tambourine_man 3y ago
    > Assuming you mean “return” as in a JSX expression in a return statement I do. Right, but the <></> syntax still feels like a hack around a need to have just one node at the top of the three. ----------- >Attributes aren’t even part of the syntax (they’re “props”) What I meant was that this is valid syntax: function hey ({ props }) { return ( <div data-foo={ bar }></div> ); } While this isn't: function hi ({ props }) { return ( <div { bar }></div> ); } There are many situations in HTML where you want a plain string inside the tag, like <input checked> ----------- > control flow is anything that can be used in a JS expression position I explained myself poorly. We can use if/else outside the return statement, of course. It's JS after all. But inside it, which is where the JSX magic happens, you have to resort to things like: { isItTrue ? ( <i>yep</i> ) : ( <b>nope</b> )} ----------- >It might help to think of JSX as more like an S-expression (as in Lisp) That's probably the biggest complement to JSX possible :) I admire Lisp from afar, but could never stand the parentheses.
    - eyelidlessness 3y ago
      > Right, but the <></> syntax still feels like a hack around a need to have just one node at the top of the three. It’s roughly analogous to an array (and in some implementations it literally produces an array). The “hack” isn’t around returning multiple nodes, you can’t produce (and therefore return) an expression of multiple anything without some container. > There are many situations in HTML where you want a plain string inside the tag, like <input checked> Some implementations do accept that (checked prop without any curly braces or prop value assignment), with roughly the same semantics (the prop is assigned a boolean true). React doesn’t accept it IIRC, but React has quite a few rules beyond JSX (as specified, and as used in other implementations). > But inside it, which is where the JSX magic happens, you have to resort to things like: You don’t! You only have to use an expression. This is perfectly valid JSX (assuming whatever is outside the outer curly braces is also valid): {(() => { if (isItTrue) { return <i>yep</i>; } else { return <b>nope</b>; } })()} > That's probably the biggest complement to JSX possible :) I admire Lisp from afar, but could never stand the parentheses. It really is a pretty close analogy, not just a compliment. And in most uses, JSX is almost exactly akin to a Lisp macro (the biggest difference besides delimiters and host language semantics is that the “macro” definition is supplied by some arbitrary tooling external to the host language).

tambourine_man 3y ago

Sure, preference is subjective. What is objective is that JSX is very constrained. Both because it lives inside another language (JavaScript) and by design. It must only return a single element, you can’t add arbitrary attributes, its control flow syntax seems (subjectively) bolted on, etc. When you’re coming from a language where you can print anything, it's very frustrating.

eyelidlessness 3y ago
Some of this isn’t right or deserves clarification. > It must only return a single element Assuming you mean “return” as in a JSX expression in a return statement (though the same applies to a JSX expression in any valid syntax position), it can be any of: - one Element (which may or may not correspond to any markup element, it can resolve to basically anything depending on implementation) - zero Elements (<></>) - a non-Element child-compatible expression (typically a primitive value in most implementations) - any arbitrary non-Element expression (behavior will vary depending on implementation support) - N Elements (<>…</>) > you can’t add arbitrary attributes This is entirely implementation dependent. Attributes aren’t even part of the syntax (they’re “props”), and many implementations differ on how or even if they correspond to attributes at all. The spec does not constrain arbitrary prop names. > its control flow syntax seems (subjectively) bolted on It’s actually the inverse: control flow is anything that can be used in a JS expression position; JSX is bolted on (extends) the expression syntax. Some implementations and/or libraries also implement control flow as JSX Element expressions (eg Solid’s For, Show, Switch/Match). > When you’re coming from a language where you can print anything, it's very frustrating. The only real limitation syntactically is that everything in a JSX expression must be an expression itself. This isn’t as limiting as it sounds, because functions can be expressions (with anything in their body, and can be invoked as an expression inline at their definition site). It might help to think of JSX as more like an S-expression (as in Lisp). It can express any value (that the language can produce), but it can’t express arbitrary statements.
- tambourine_man 3y ago
  > Assuming you mean “return” as in a JSX expression in a return statement I do. Right, but the <></> syntax still feels like a hack around a need to have just one node at the top of the three. ----------- >Attributes aren’t even part of the syntax (they’re “props”) What I meant was that this is valid syntax: function hey ({ props }) { return ( <div data-foo={ bar }></div> ); } While this isn't: function hi ({ props }) { return ( <div { bar }></div> ); } There are many situations in HTML where you want a plain string inside the tag, like <input checked> ----------- > control flow is anything that can be used in a JS expression position I explained myself poorly. We can use if/else outside the return statement, of course. It's JS after all. But inside it, which is where the JSX magic happens, you have to resort to things like: { isItTrue ? ( <i>yep</i> ) : ( <b>nope</b> )} ----------- >It might help to think of JSX as more like an S-expression (as in Lisp) That's probably the biggest complement to JSX possible :) I admire Lisp from afar, but could never stand the parentheses.
  - eyelidlessness 3y ago
    > Right, but the <></> syntax still feels like a hack around a need to have just one node at the top of the three. It’s roughly analogous to an array (and in some implementations it literally produces an array). The “hack” isn’t around returning multiple nodes, you can’t produce (and therefore return) an expression of multiple anything without some container. > There are many situations in HTML where you want a plain string inside the tag, like <input checked> Some implementations do accept that (checked prop without any curly braces or prop value assignment), with roughly the same semantics (the prop is assigned a boolean true). React doesn’t accept it IIRC, but React has quite a few rules beyond JSX (as specified, and as used in other implementations). > But inside it, which is where the JSX magic happens, you have to resort to things like: You don’t! You only have to use an expression. This is perfectly valid JSX (assuming whatever is outside the outer curly braces is also valid): {(() => { if (isItTrue) { return <i>yep</i>; } else { return <b>nope</b>; } })()} > That's probably the biggest complement to JSX possible :) I admire Lisp from afar, but could never stand the parentheses. It really is a pretty close analogy, not just a compliment. And in most uses, JSX is almost exactly akin to a Lisp macro (the biggest difference besides delimiters and host language semantics is that the “macro” definition is supplied by some arbitrary tooling external to the host language).