React.createElement is the underlying API for React to which JSX was created specifically to compile to.
ΦΌ
JSX is designed to be nested function calls that look familiar to us like XML or HTML so our eyes don't burn when look at actual nested function calls
ΦΌ
Some who don't know might complain that in JSX we do instead of HTML's . But again this is how it's done in plain JavaScript. Checkout the MDN docs for yourself π
You are stating the obvious, and presenting it as if you are "correcting" the OP - but the OP knows this and his original point is still valid: JSX is made to look like html, but is actually not. The JSX design decisions are somewhat understandable, but the OP was criticizing the reliance on JSX, not JSX's design decisions, while you're justifying their design decisions. In my opinion, there is no justification for using JSX as a library requirement, when tagged template literals exist.
JSX looks like html but it introduces variations from the standard (className instead of class, style attribute, etc.). And those are really irritating for someone who doesn't want to forget the web standards and commit fully to react. So react is like a jealous partner in that aspect, it tries to push you away from the obvious alternative and make you choose between the two. Only react is a "library", right? It shouldn't try to push you away from web standards.
"there is no justification for using JSX", "react is like a jealous partner". Stop being dramatic. We'll have to agree to disagree. All abstractions of HTML creation deviate from HTML in certain ways. You're complaining that JSX deviated away from standards when the whole point of JSX is to make the DOM and it is using standard DOM API names like htmlFor vs for. Isn't it weird that the "I hate JSX" crowd is so loud about the certain ways that JSX is different from HTML and yet they're using string-based abstractions that do things like <button onclick=${() => state.clicks += 1}> and for whatever reason their control flow decisions which don't resemble HTML are forgivable and are supposed to be easier for newcomers to get over JSX? Show me in the w3c where your library's syntax meets the HTML standard for onclick=${() => {}}
You're right, no point in being dramatic. But you get what I mean when I say that "react is like a jealous partner", right? It makes you learn lots of stuff, while unlearning the standards. And that's how you get a divided community, because unlearning react takes time so managers tend to stick with it and people tend to find justifications for keeping using it. "I know it so I should use it" is really an ok justification, people just gotta be aware of their own reasons.
Isn't it weird that the "I hate JSX" crowd is so loud about the certain ways that JSX is different from HTML and yet they're using string-based abstractions that do things like
The difference between JSX and what "I hate JSX" crowd strives to, is that the only deviations are in added functionality - basically, how values are inserted, instead of a whole lot of other deviations in existing functionality. Let's look at onclick. onclick=${() => {...}} is a deviation from the standard indeed, but there's no way to do this in html, and in my opinion it's the simplest way to respond to events in a clear, inline manner. React does this similarly.
But className, style attribute, camelCase attributes, the extra compilation step, all that doesn't cut it with me, especially when it's combined with a framework that requires it to be usable, with the framework itself having a few questionable design decisions.
I appreciate it, but you're splitting hairs talking about how your way of "expanding what is possible" with HTML by adding functionality is hugely different from what JSX is doing. Also, what you're saying about devs using React is somehow bad because they won't learn standards -- that has nothing really to do with React. When jQuery came out everyone said the same thing, and they were right. People were learning jQuery and not understanding how the underlying DOM works and when they jumped over to Angular they had to learn new stuff -- and that's okay. Then Angular got popular and bootcamps became a thing and the bootcamps were only teaching Angular without really teaching good fundamentals (the standard). Let's not act like React or your tool if it were to become popular are any different. Devs are devs, people are people, if they have a tool available to them that helps gloss over the ugliness of the DOM they're going to use it
Glossing over is fine, and abstractions will always put an extra learning layer and require the dev to know his fundamentals.
Agreed. But inventing new ways to do the same stuff with the same ugliness rating of the underlying tech, that's what I dislike... And that's what JSX has - unnecessary deviations from standards. You can't call className an abstraction... It doesn't abstract anything, It's just a simple patch for a design flaw.
If my tool becomes popular maybe people will complain about it, but it won't be for creating unnecessary deviations from standard html. (Really, check it out, it's pure html plus expressions for reactive values...).
It is hugely different from JSX - it doesn't require a compilations step, it's just legit JS code. There's no new html-like syntax to learn. The actual rerender mechanism is embedded into the template unlike react (it's a render - once template). No VDOM. The diff is huge, really :)
By the way, what did you mean by "control flow decisions which don't resemble HTML"? Html doesn't have control flow decisions. Did you compare the {condition && someConditionalContent} syntax that Yoffee and react use with Vue's v-if tags?
Yea, I'm saying if it aint exactly HTML then I guess we can say it deviates from the "standard" if that's the strict set of rules we're upholding things to. I'm not the one saying that but the JSX hater crowd seems uphold this for JSX and conveniently ignore that they (angular, vue, yours probably) do control flow in various ways that also isn't exactly HTML so to me that's splitting hairs (bike-shedding) over syntax which really doesn't matter
Like, one of the main points that other article made was something to the effect of: "I can't copy JSX into another project as HTML and that rubs me the wrong way...", what, like you can with any of these template lang DLS syntax? The JSX hater crowd is one of the more ridiculous that Ive seen with their arguments and I've been doing this shit for 22 years
Well, the author should have specified that he needs to do much more work copying JSX to another framework than copying code of libraries that use tagged template literals. The author may have accidentally implied that it's actually possible to copy from framework to framework, but to me it didn't seem so and his point was fairly clear.
The hater crowd, me included, sees that some things should be much easier than they are, even if the popular way is not so terrible.
ΦΌ
ΦΌ
You are stating the obvious, and presenting it as if you are "correcting" the OP - but the OP knows this and his original point is still valid: JSX is made to look like html, but is actually not. The JSX design decisions are somewhat understandable, but the OP was criticizing the reliance on JSX, not JSX's design decisions, while you're justifying their design decisions. In my opinion, there is no justification for using JSX as a library requirement, when tagged template literals exist.
JSX looks like html but it introduces variations from the standard (
classNameinstead ofclass, style attribute, etc.). And those are really irritating for someone who doesn't want to forget the web standards and commit fully to react. So react is like a jealous partner in that aspect, it tries to push you away from the obvious alternative and make you choose between the two. Only react is a "library", right? It shouldn't try to push you away from web standards."there is no justification for using JSX", "react is like a jealous partner". Stop being dramatic. We'll have to agree to disagree. All abstractions of HTML creation deviate from HTML in certain ways. You're complaining that JSX deviated away from standards when the whole point of JSX is to make the DOM and it is using standard DOM API names like
htmlForvsfor. Isn't it weird that the "I hate JSX" crowd is so loud about the certain ways that JSX is different from HTML and yet they're using string-based abstractions that do things like<button onclick=${() => state.clicks += 1}>and for whatever reason their control flow decisions which don't resemble HTML are forgivable and are supposed to be easier for newcomers to get over JSX? Show me in the w3c where your library's syntax meets the HTML standard foronclick=${() => {}}You're right, no point in being dramatic. But you get what I mean when I say that "react is like a jealous partner", right? It makes you learn lots of stuff, while unlearning the standards. And that's how you get a divided community, because unlearning react takes time so managers tend to stick with it and people tend to find justifications for keeping using it. "I know it so I should use it" is really an ok justification, people just gotta be aware of their own reasons.
The difference between JSX and what "I hate JSX" crowd strives to, is that the only deviations are in added functionality - basically, how values are inserted, instead of a whole lot of other deviations in existing functionality. Let's look at onclick.
onclick=${() => {...}}is a deviation from the standard indeed, but there's no way to do this in html, and in my opinion it's the simplest way to respond to events in a clear, inline manner. React does this similarly.But
className, style attribute, camelCase attributes, the extra compilation step, all that doesn't cut it with me, especially when it's combined with a framework that requires it to be usable, with the framework itself having a few questionable design decisions.I appreciate it, but you're splitting hairs talking about how your way of "expanding what is possible" with HTML by adding functionality is hugely different from what JSX is doing. Also, what you're saying about devs using React is somehow bad because they won't learn standards -- that has nothing really to do with React. When jQuery came out everyone said the same thing, and they were right. People were learning jQuery and not understanding how the underlying DOM works and when they jumped over to Angular they had to learn new stuff -- and that's okay. Then Angular got popular and bootcamps became a thing and the bootcamps were only teaching Angular without really teaching good fundamentals (the standard). Let's not act like React or your tool if it were to become popular are any different. Devs are devs, people are people, if they have a tool available to them that helps gloss over the ugliness of the DOM they're going to use it
Glossing over is fine, and abstractions will always put an extra learning layer and require the dev to know his fundamentals.
Agreed. But inventing new ways to do the same stuff with the same ugliness rating of the underlying tech, that's what I dislike... And that's what JSX has - unnecessary deviations from standards. You can't call
classNamean abstraction... It doesn't abstract anything, It's just a simple patch for a design flaw.If my tool becomes popular maybe people will complain about it, but it won't be for creating unnecessary deviations from standard html. (Really, check it out, it's pure html plus expressions for reactive values...).
It is hugely different from JSX - it doesn't require a compilations step, it's just legit JS code. There's no new html-like syntax to learn. The actual rerender mechanism is embedded into the template unlike react (it's a render - once template). No VDOM. The diff is huge, really :)
By the way, what did you mean by "control flow decisions which don't resemble HTML"? Html doesn't have control flow decisions. Did you compare the
{condition && someConditionalContent}syntax that Yoffee and react use with Vue'sv-iftags?Yea, I'm saying if it aint exactly HTML then I guess we can say it deviates from the "standard" if that's the strict set of rules we're upholding things to. I'm not the one saying that but the JSX hater crowd seems uphold this for JSX and conveniently ignore that they (angular, vue, yours probably) do control flow in various ways that also isn't exactly HTML so to me that's splitting hairs (bike-shedding) over syntax which really doesn't matter
Like, one of the main points that other article made was something to the effect of: "I can't copy JSX into another project as HTML and that rubs me the wrong way...", what, like you can with any of these template lang DLS syntax? The JSX hater crowd is one of the more ridiculous that Ive seen with their arguments and I've been doing this shit for 22 years
Well, the author should have specified that he needs to do much more work copying JSX to another framework than copying code of libraries that use tagged template literals. The author may have accidentally implied that it's actually possible to copy from framework to framework, but to me it didn't seem so and his point was fairly clear.
The hater crowd, me included, sees that some things should be much easier than they are, even if the popular way is not so terrible.
No worries. I'm sure we each have better things to do today, we can agree to disagree on JSX π