Those names have nothing to do with JSX or React, they're the actual properties you're setting. JS properties don't map 1:1 to HTML attributes: while for example the "src" attribute is controlled using the "src" property, the "for" attribute is controlled using the "htmlFor" property, and the "class" attribute with the "className" property. All React is doing is setting the properties you tell it to.

(The reason for the name change is that old versions of JS couldn't use keywords - like "for" and "class" - as property names.)

I agree. Those examples have nothing to do with learning a new template syntax, it's simply the API of React.Component.

Granted, there is still some syntax you need to learn for JSX, but it's very little. If you already know HTML's syntax, the only new things I can think of are the curly braces for using JS expressions as prop values (you also need to know what a JS expression is, lest you try to use an if statement), and spread attributes.

I think you misunderstand. The names are unrelated to React as well, they are native. Defined by the same standards bodies that define JavaScript itself, implemented by the browsers themselves. On a blank HTML page that includes neither React nor anything else, the line `document.body.className = "foo";` sets the body's class to "foo". (And `document.body.class = "foo";` does not.)

All JSX is doing is transforming `<div className="foo">` into `[create div element]; div.className = "foo";`. If you wrote `<div class="foo">`, JSX would faithfully transform it into `[create div element]; div.class = "foo";` - which doesn't work.

Whilst you're correct, that's where the names are from, it's also not totally accurate to suggest it has nothing to do with React.

React defines `React.createElement`, `<div class="foo"/>` transforms to `React.createElement("div", { "class": "foo" })`, so React could convert that under the hood to set className correctly.

Preact does something similar to allow this. However it now seems it is now too late for React for too little benefit. And there's a downside [1]:

> The JSX transform used to do that, but we don't recommend it because it's confusing if you ever try to pass class= or for= as a prop to your own components – you wouldn't expect to access them with a different name.

[1] https://github.com/facebook/react/issues/4433#issuecomment-1...

Good point. I didn't realize that the native DOM properties are also called "className" and "htmlFor". My point still applies though, that this isn't a JSX syntax issue, your point is that it's also not even a JSX-specific semantics issue.

not quite, the list of reserved keywords was made up by the committee that designed the first version of ecmascript in 10 days (or however the exact story goes).

many years later, the workarounds like class -> className were designed by whatever party exerted most control over the JS DOM API (which is not really part of "Javascript itself") at the time, and who also brought you inconsistent camelcasing such as "onclick" ...

it's neither quite "native", nor is "defined by the same standards bodies" much of a sign of good design or worthy of copying.

feels more like if someone were to build, say, a modern high perf numerical library that includes necessary workarounds tributed to the eax/ax/ah/al peculiarities of x86 assembly.

ah so you only need to memorise the list of js "reserved" keywords and it's intuitive as a banana :)

mistakes were made. then copied, repeated and finally, standardised :)

Actually those idiosyncracies are React, not JSX. Using JSX with Mithril I've had no trouble using reserved words as attribute names. Dynamically inserted html in Mithril/JSX is just {m.trust(str)}

Edit: I should also mention that Mithril comes with routing built in, as well as XHR utility and streams. I'm finding streams super useful for sophisticated state management.

> To be fair, JSX has its own idiosyncracies too for templating, such as className, htmlFor,

those are the Javascript attribute names.

> and the obnoxious attribute name for dynamically inserted html.

Depends on your taste, but this is a plus for me, personally.

> It is not immune to the criticism that it requires learning.

It's takes maybe 10 minutes if you're already a little bit familiar with XML and know Javascript.

You're right, but it's one of those things that you can basically treat it as html until you can't - and the points at which you can't are quite specific and other than className - are rarely used. Also the dynamically inserted html param being obnoxious is by design - they don't want you to dynamically insert html, and that's a good thing. Honestly you shouldn't ever be using that param.