I wouldnt call it a "gotcha". Using vanilla javascript you'd be using className as well:

    document.body.className = 'class1 class2'

JSX chose to align names to the DOM spec [0]. Same for htmlFor and friends.

[0] https://dom.spec.whatwg.org/#ref-for-dom-element-classname%E...

It's a gotcha because it looks wrong. The surface syntax looks like a tag, which prompts the thought "class". You've got to have additional information to know that's not what's needed.

> JSX chose to align names to the DOM spec [0]. Same for htmlFor and friends.

And the DOM spec changed these names because "class" and "for" are reserved words in Java (and if you look closely, you'll notice that the main target language for the DOM spec was Java). If you're writing a template language, you don't need to be bound by reserved words in another language, and matching the original attribute name is more intuitive than matching the underlying DOM implementation.

(But I can understand why JSX did that: since it maps directly to DOM calls, using the same name as DOM avoids the need for a table mapping from the attribute name to the DOM name. That is, implementation convenience was more important than usability.)

JS has proposals to add those. Unfortunately, the spec team is busier with garbage like private class variables.

The className thing is transitory. `class` was reserved in all non-string contexts previously, but in modern JS, you can add it bare in places like object literal keys. Preact allows you to use `class`, but react is more conservative.

Seems like a weird place to apply conservatism. That is, right after inventing entirely new tokens and grammar. But the keyword semantics SHALL NOT be modified.

Historically, you couldn't use ANY of them as object literal keys without risking problems. I believe it was an oversight.

JS has reserved a really long list of keywords that have been around for a long time.. I've seen this occasionally trip up new JS programmers because the words are special without having any use.

abstract, arguments, await, boolean, break, byte, case, catch, char, class, const, continue, debugger, default, delete, do, double, else, enum, eval, export, extends, false, final, finally, float, for, function, goto, if , implements, import, in, instanceof, int, interface, let, long, native, new, null, package, private, protected, public, return, short, static, super, switch, synchronized, this, throw, throws, transient, true, try, typeof, var, void, volatile, while, with, yield

Well, right, but this is JSX, not JS. The rest of JSX is also illegal in JS.

I understand the rationale behind using the native constructs of JavaScript as much as possible, but this is where I feel Solid.js made a reasonable compromise to pragmatism. There are JSX constructs for conditions and looping, making certain things easier or clearer to express.