The gruff official answer is
JSX is JS, not HTML.
Of course the React core team answered this question on Quora.
Translation:
Class to this.props[‘class’] so that you can use these class names very easily. Babel can do it. But we stick with classnames for a few reasons:
First we use the attributes of the HTML DOM object as much as possible (like el.classname), as opposed to setting the tag attributes. A tag attribute is always a string, whereas an object attribute is an arbitrary data type, so it is an elastic extension. One example is the classList property, which is actually a better fit for the data model than className. React doesn’t support classList right now, but plans to do so in the future. Using className is more like an HTML property and makes more sense.
Another reason is for the future, where React might use object deconstruction to assign attributes. React-future shows an example. Even in more modern browsers, this does not apply to classes and does not appear as attribute names in tags.
Third, we think the main advantage of JSX is that it makes code easier to read by matching closed tags, rather than replacing HTML or XML. Although it is very easy to paste/copy HTML code, the difference is that (fully closed tags) make it a little bit weaker, so we have programs to convert HTML to JSX. Finally, in order to fully convert HTML to the ideal React code, there will be a lot of work going into converting tags into components, but turning classes into classnames is only a small part of the work.
The original:
We certainly could have done it the other way around. I argued for that for a while. There are transforms that convert this.props.class to this.props[‘class’] and so using the names class and for would be nearly seamless. Babel includes one. We’re sticking with className and htmlFor for a couple of reasons:
First, we tend to look at HTML properties (like el.className = …) when possible, as opposed to attributes (like el.setAttribute(‘class’, …) ). Attributes are always string-typed, while properties can have any JavaScript object value, which gives more flexibility in some circumstances. One example is the .classList property, which arguably is a better fit for the data model than .className is. React doesn’t support classList right now, but it certainly could. Given that React’s className behaves like the HTML property of the same name, it makes sense to keep that name.
Another reason is more forward-thinking. In the future, idiomatic React may use object destructuring to pick apart this.props. The react-future repo shows one example of how this could work. Even in modern browsers, this wouldn’t work with class and for which are keywords and can’t appear as standalone identifiers even though they can appear as property names.
Third, our thinking is that JSX’s primary advantage is the symmetry of matching closing tags which make code easier to read, not the direct resemblance to HTML or XML. It’s convenient to copy/paste HTML directly, but other minor differences (in self-closing tags, for example) make this a losing battle and we have a HTML to JSX converter to help you anyway. Finally, to translate HTML to idiomatic React code, a fair amount of work is usually involved in breaking up the markup into components that make sense, so changing class to className is only a small part of that anyway.
More discussion can be found at groups.google.com/forum/#! Top…