71–80 of 86 posts
People like to hate everything related to JS these days. But when I see libs like these I'm just very grateful for the person(s) who invented JSX [1]. And evenly for MSFT implementing it into TS as a first-class citizen. It's just so much more readable. Scala is the only other language I know of which has some kind of XML/HTML syntax support (scala.xml). (But it looks like it got removed. [2]) [1] https://reactjs.org…
People like to hate everything related to JS these days. But when I see libs like these I'm just very grateful for the person(s) who invented JSX [1]. And evenly for MSFT implementing it into TS as a first-class citizen. It's just so much more readable. Scala is the only other language I know of which has some kind of XML/HTML syntax support (scala.xml). (But it looks like it got removed. [2]) [1] https://reactjs.org…
I was there when E4X was introduced, about 20 years ago. It lasted about 5 whole years before people started to think it was old and crufty. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...
Had E4X been more widely released, I might have used it, as might many others. In retrospect, though, it's probably good that it didn't catch on, as it introduced a lot of extra syntax and operators, like a.@b, a.@*, a.*, a.b::c, a..b, a.(@b==x) and had semantics that affected large parts of the JS Runtime (how the delete operator works, how calling works, what += means, and so on).
People like to hate everything related to JS these days. But when I see libs like these I'm just very grateful for the person(s) who invented JSX [1]. And evenly for MSFT implementing it into TS as a first-class citizen. It's just so much more readable. Scala is the only other language I know of which has some kind of XML/HTML syntax support (scala.xml). (But it looks like it got removed. [2]) [1] https://reactjs.org…
\Hello, world!\
\
\Hello, {place}!\
\
\
Earlier quoted context omitted.
I don't think JSX is very readable. If you squint it may look like HTML, but when you try to actually read it, it's all off. Different attributes, bizarre templating, blurred line between rendering and code. The latter in practice is always a complex mix of view/state/ callbacks with react.
You're confusing JSX and the React target for JSX; only the latter has the problems you mention. This is a very common confusion because most people approach JSX via React, and as such never really grasp that JSX is a separate, independent thing. If you're interested in learning it standalone, I'd highly recommend working with either the Typescript `jsxFactory` compiler option, or the `@babel/plugin-transform-react-j…
People like to hate everything related to JS these days. But when I see libs like these I'm just very grateful for the person(s) who invented JSX [1]. And evenly for MSFT implementing it into TS as a first-class citizen. It's just so much more readable. Scala is the only other language I know of which has some kind of XML/HTML syntax support (scala.xml). (But it looks like it got removed. [2]) [1] https://reactjs.org…
JSX has some questionable design limitations in it, though. Like, these work as expected: \ Hello, world!\ \ \ Hello, {place}!\ \ But this doesn't: \ And as other commenters note, it's designed around React internals, meaning you get rules around capitalisation that wouldn't otherwise exist. And so on.
Earlier quoted context omitted.
You're confusing JSX and the React target for JSX; only the latter has the problems you mention. This is a very common confusion because most people approach JSX via React, and as such never really grasp that JSX is a separate, independent thing. If you're interested in learning it standalone, I'd highly recommend working with either the Typescript `jsxFactory` compiler option, or the `@babel/plugin-transform-react-j…
No, I am not confusing them. My comment is about JSX' awkward attribute (re-)names, only expressions in brackets but full function calls in loops (map). It's horrible.
The attribute renaming is a React feature. JSX doesn't rename attributes. See here for example https://codepen.io/lucideer/pen/jOZvwVz?editors=0010
> only expressions in brackets but full function calls in loops (map)
Not sure what you mean here. Function calls are expressions - they work bare in brackets & also as method args (like the arg passed to the map method on an array prototype, which is called while "loop"-ing that array). This is all Javascript functionality, not really specific to JSX in any way?
Earlier quoted context omitted.
No, I am not confusing them. My comment is about JSX' awkward attribute (re-)names, only expressions in brackets but full function calls in loops (map). It's horrible.
> JSX' awkward attribute (re-)names The attribute renaming is a React feature. JSX doesn't rename attributes. See here for example https://codepen.io/lucideer/pen/jOZvwVz?editors=0010 > only expressions in brackets but full function calls in loops (map) Not sure what you mean here. Function calls are expressions - they work bare in brackets & also as method args (like the arg passed to the map method on an array prot…
The problem with "only expressions in brackets" is that then you can write code in the template, but it's massively different to regular code. Worst of both worlds: code in templates and weird subset of code.
Earlier quoted context omitted.
> JSX' awkward attribute (re-)names The attribute renaming is a React feature. JSX doesn't rename attributes. See here for example https://codepen.io/lucideer/pen/jOZvwVz?editors=0010 > only expressions in brackets but full function calls in loops (map) Not sure what you mean here. Function calls are expressions - they work bare in brackets & also as method args (like the arg passed to the map method on an array prot…
I stand corrected about JSX attribute renaming! However I still see it being applied in practice for 99% of JSX use cases. The problem with "only expressions in brackets" is that then you can write code in the template, but it's massively different to regular code. Worst of both worlds: code in templates and weird subset of code.
If this is undesirable as a feature, then yes, JSX is not an appropriate choice. JSX is the furthest thing from logic-less templating. But that's a deliberate design decision.
> it's massively different to regular code
It's not. It's just regular code - there are no differences.
> weird subset of code
It's not weird. It's any JS expression. All JSX brackets are values, and JS statements don't have return values, so embedding a JS statement within a JSX value would serve no purpose. What would it do?
All statements in JS can be expressed as expressions directly (ternary/array methods) or indirectly (nested within a function expression), so there's no loss of functionality - it's not even really a subset in that sense.
Earlier quoted context omitted.
I was there when E4X was introduced, about 20 years ago. It lasted about 5 whole years before people started to think it was old and crufty. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...
E4X couldn't really be used - it was never available enough (just one major browser) and there was no polyfill or to-JS compiler (those things weren't common at that time). Had E4X been more widely released, I might have used it, as might many others. In retrospect, though, it's probably good that it didn't catch on, as it introduced a lot of extra syntax and operators, like a.@b, a.@*, a.*, a.b::c, a..b, a.(@b==x) a…